FAQs

The Lightcast MCP Server is a hosted Model Context Protocol (MCP) platform that allows customers to connect AI agents and LLMs directly to trusted labor market intelligence through a controlled tool layer instead of raw APIs. It enables secure, AI-friendly access to labor market data while enforcing enterprise guardrails, non-PII protections, and standardized analytical workflows.

Traditional APIs are difficult for AI agents to use safely and consistently. The MCP Server abstracts backend complexity and exposes standardized analytical tools that are easier for AI systems to reason with, while also enforcing security, observability, rate limits, and data governance.

No. The MCP Server is not an orchestration framework or autonomous agent platform. It is a controlled tool surface that AI agents connect to in order to safely access Lightcast labor market intelligence.

The current MCP scope focuses on the following selected US labor market datasets:

Job Posting data (labor demand)
Professional Profile data (labor supply)

These datasets are exposed through standardized analytical tools.

A dataset represents the logical data universe that an MCP tool operates on. Examples include:

Job_postings
Profiles
Core LMI

Datasets define the type of records that are queried, independent of the underlying backend APIs or storage systems.

The Job Posting dataset represents labor demand — what employers are hiring for.
The Profile dataset represents labor supply — the workforce and professional talent available in the market.

Together, these datasets support demand-versus-supply workforce analysis.

The MCP Server exposes the following standardized analytical tools:

List
Extract
Classify
Count
Top
Distribution
Estimate
Time Series
Glossary
Tool Info

These tools represent analytical intents rather than raw API endpoints.

MCP tools are designed around user intent instead of backend APIs. For example, a user asks:

“How many software engineering job postings exist in New York?”

The agent uses the count tool rather than manually constructing API calls.

This simplifies AI integration and improves consistency.

The count tool calculates how many records match a specific query or filter set. It is commonly used for:

Hiring demand analysis
Talent availability analysis
Volume estimation
Market sizing

The distribution tool provides percentile breakdowns of specifics metrics relevance to each data set such as :

Total posting
Salary
Posting duration
Posting intensity
Total Profile
Earnings

The similar tool identifies related entities using Lightcast taxonomies. This can include:

Similar occupations
Similar skills
Similar companies

It helps agents expand searches and explore adjacent labor market opportunities.

Dimensions are schema-defined analytical attributes used for filtering, grouping, segmentation, or ranking data. Examples include:

occupation_soc
industry_naics
location_us_area
Skill

A taxonomy is a controlled classification system used to normalize values within dimensions. Examples include:

SOC occupations
NAICS industries
O*NET occupations
Skills taxonomies

Taxonomies ensure consistent AI-safe reasoning across datasets and tools.

MCP uses a structured filter model based on the following filter types:

Include
Exclude

Each filter clause contains the following properties:

dimension
operator
value

Example:

{
  "filter": {
    "include": [
      {
        "dimension": "industry_naics",
        "op": "OR",
        "value": ["5415"]
      }
    ]
  }
}

Current supported operators include:

Different operators apply to different dimension types.

Yes, through the exclude filter block. MCP intentionally avoids explicit NOT operators. Instead, exclusion is handled structurally through filter semantics.

No. The MCP Server explicitly excludes PII and only exposes aggregated, normalized, or statistical labor market information.

Yes. The initial platform rollout enforces strict US-only filtering. This restriction is enforced centrally and cannot be overridden by clients.

Global data will be delivered before launch in October 2026.

The MCP Server uses a dedicated OAuth 2.0 authentication layer that is fully separate from existing API credentials. All clients must authenticate before accessing tools or resources.

No. MCP authentication is independent from legacy API authentication systems. Only MCP-issued OAuth tokens are accepted.

The MCP platform is designed specifically for AI-safe interactions through:

Stable tool contracts
Controlled schemas
Structured outputs
Validation rules
Rate limiting
Observability
Guardrails

Yes. The hosted MCP Server includes a caching layer designed to:

Reduce repeated API calls
Improve latency
Lower infrastructure costs
Support iterative AI workflows

The cache is index-aware to ensure stale analytical results are never served after dataset updates.

Cached results are tied to dataset or index revision markers. If the underlying data index changes, cached results are invalidated or bypassed automatically.

MCP returns structured machine-readable errors with:

Error type
Error category
Human-readable message
Retry guidance

Example categories include:

Validation
Authorization
Execution
Policy
System

MCP provides:

Stable AI-friendly contracts
Intent-based tooling
Safer execution patterns
Better observability
Structured outputs
Reduced hallucination risk
Consistent taxonomy normalization
Enterprise guardrails

This makes it significantly easier for customers to build reliable agentic AI systems on top of labor market intelligence.

The Lightcast AI platform is designed around a governance-first architecture where AI systems operate within controlled execution boundaries. Sensitive information is protected through:

Permission-aware retrieval
Runtime governance
Scoped execution
Contextual filtering
Masking and redaction
Auditability systems
Tenant isolation
Governance remains authoritative over AI execution at all times.

No. Lightcast explicitly states that customer-specific data is not used to train third-party foundation models. External LLM providers operate only as governed reasoning components within the platform architecture.

The platform is intentionally designed to minimize unnecessary exposure of Personally Identifiable Information (PII). Before external model interaction occurs, Lightcast may apply:

PII detection
Masking
Redaction
Anonymization
Tokenization
Contextual filtering

Only the minimum required context is exposed when necessary.

Sensitive data categories may include:

Names
Email addresses
Phone numbers
Employee identifiers
Authentication credentials
Compensation data
HR information
Tenant-scoped contextual information

These categories are governed through centralized enforcement policies and scoped access models.

The platform enforces strict tenant and contextual isolation across:

Retrieval systems
Memory systems
Orchestration frameworks
Personalization systems
Execution contexts

This architecture is specifically designed to prevent cross-tenant contextual leakage or unauthorized access to organizational data.

Yes. The platform supports governed contextual memory capabilities including:

Workflow continuity
Conversational continuity
Interaction history
Personalization
Resumable workflows

However, all memory persistence is centrally governed, scoped, auditable, and Lifecycle-managed.

No. Agents do not independently control memory persistence. Memory eligibility and persistence are governed through centralized platform controls and lifecycle governance policies.

No. The platform supports governed retention lifecycle management, including:

Contextual expiration
Deletion workflows
Memory reset operations
Retention enforcement
Right-to-be-forgotten processes

Retention policies are centrally enforced through governance systems.

Lightcast follows a governance-first Responsible AI philosophy based on:

Accountability
Transparency
Operational safety
Human oversight
Privacy-conscious design
Deterministic governance
Controlled adaptability

AI systems may reason and adapt, but governance authority always remains human-directed and platform-enforced.

No. The platform explicitly rejects unrestricted autonomous AI systems. AI capabilities operate only within governed orchestration frameworks, runtime constraints, and permission-aware execution environments.

No. Tool invocation and system interactions are permission-scoped, governance-controlled, runtime-validated, observable, and auditable. Agents cannot bypass governance controls or independently authorize actions.

The platform includes layered runtime guardrails and validation systems that may evaluate:

Malicious prompts
Prompt injection attempts
Unsafe instructions
Unauthorized requests
Workflow boundary violations

Governance validation occurs before orchestration and execution proceed.

The platform combines:

Deterministic governance
Retrieval grounding
Permission-aware retrieval
Runtime validation
Structured outputs
Orchestration constraints
Selective semantic evaluation

This layered governance approach reduces hallucination risk while maintaining operational scalability.

Yes. The governance layer maintains runtime authority to:

Interrupt execution
Terminate workflows
Deny tool usage
Restrict retrieval
Block unauthorized actions

Governance enforcement remains continuously active throughout execution.

Yes. The platform follows an observability-by-design philosophy where:

Orchestration decisions
Tool usage
Retrieval operations
Runtime governance actions
Workflow transitions
Memory interactions

…remain traceable and auditable throughout the execution lifecycle.

The platform may capture:

Execution traces
Orchestration logs
Provider invocation events
Governance enforcement events
Retrieval interactions
Runtime interruptions
Validation outcomes
Operational telemetry

This supports governance review, debugging, incident response, and operational accountability.

The platform supports governed personalization to improve workflow continuity and usability, but explicitly avoids:

Unrestricted behavioral profiling
Uncontrolled surveillance systems
Unauthorized psychological inference
Uncontrolled sensitive-category inference

Personalization operates within governed privacy boundaries and lifecycle controls.

Lightcast aligns with enterprise governance and security practices including:

ISO 27001:2022
GDPR
CCPA
TX-RAMP

…alongside broader operational security and governance programs.

Yes. The platform incorporates layered authorization systems including:

RBAC
Scoped permissions
Tenant-aware authorization
Contextual access validation
Least-privilege operational models

Authorization enforcement remains continuously active throughout execution.

Human oversight is foundational across the entire AI lifecycle, including:

Deployment approvals
Governance policy management
Security review
Compliance oversight
Operational escalation
Lifecycle governance

The platform explicitly rejects uncontrolled autonomous self-modifying AI systems.

The platform focuses on operational traceability and governance-aware auditability rather than claiming perfect deterministic explainability of probabilistic AI reasoning. Execution behavior remains observable, reviewable, and operationally attributable.

Lightcast positions AI as governed operational intelligence operating within deterministic governance boundaries — not as unrestricted autonomous intelligence. The platform emphasizes:

Governed adaptability
Operational transparency
Enterprise accountability
Privacy-conscious AI
Human oversight
Controlled intelligence