MCP Scope Matrix

Use this matrix when planning an MCP client, requesting an API key, or reviewing whether an integration has the right access level.

Prerequisites

Before requesting a key or approving scopes, confirm:

• workflow owner and reviewer are named;
• tenant and operating boundary are clear;
• source systems and data quality status are known;
• endpoint family has been selected;
• first run can be read-only;
• key owner, rotation policy, and revocation path are documented.

Source data inputs

Scope planning should include the data package the client will use:

Input	Review question
Asset or equipment identity	Which tenant object will the tool read or act on?
Source records	Which connectors, datasets, documents, work records, scenes, or module records are required?
Quality notes	Are stale values, missing fields, rejected rows, or incomplete history visible?
Compute assumptions	Who accepts simulation, forecasting, optimization, or analysis assumptions?
Action approval	Who approves a draft work order, inspection task, or operating record?

Access planning flow

Scope model

Each API key resolves to a tenant and scope set. Tenant context comes from the issued key. A tool call is allowed only when the key has the scope required by that tool.

Endpoint	Scope	Allows	Typical reviewer
/mcp/base/	base.read	Read shared asset context, documents, data quality, pending tasks, and knowledge records.	Implementation owner or operations lead.
/mcp/base/	base.compute.run	Run approved simulation, optimization, forecasting, spatial analysis, and reporting tasks.	Engineering or analytics owner.
/mcp/base/	base.action.write	Draft controlled records such as work orders after approval.	Operations owner.
/mcp/pdm/	pdm.read	Read predictive maintenance health, anomaly, and component intelligence outputs.	Reliability or maintenance engineer.
/mcp/trafficops/	trafficops.read	Read traffic, checkpoint, lane, roster, and surge information when enabled.	Operations supervisor.
/mcp/telcoops/	telcoops.read	Read network health, incident, and capacity analysis when enabled.	Network operations owner.
/mcp/semiops/	semiops.read	Read cleanroom, particle, pressure, utility, SMT, and facility environment signals when enabled.	Facility or process operations owner.
/mcp/aviation/	aviation.analysis.read	Read aviation reliability analysis outputs when enabled.	Reliability engineering owner.

Physical AI workflows use current base and module endpoints with scenes, simulation-ready asset packages, DFS-prepared operating data, and simulation services.

Access packages

Package	Scopes	Use
Read-only facility review	base.read	Asset status, documents, alarms, inspections, and source freshness checks.
Facility analysis	base.read, base.compute.run	Read context and run approved summaries, comparisons, or scenario analysis.
Facility action drafting	base.read, base.action.write	Read evidence and draft work orders or inspection tasks after review.
Predictive maintenance review	pdm.read	Equipment health, anomaly context, and maintenance planning.
Predictive maintenance with actions	pdm.read, base.read, base.action.write	Combine health output with asset records and draft follow-up actions after engineer review.
Physical AI preparation	base.read, base.compute.run	Read scene and asset context, run approved simulation preparation or analysis, and record assumptions.
Module operating review	One module read scope	Use the module endpoint for a focused operating domain. Add base.read for documents and shared asset context.

Least-privilege workflow

1. Start with read scope.
2. Confirm the client can list only the expected tools.
3. Add compute scope when the workflow has an owner for assumptions and output review.
4. Add write scope only when draft records, approval state, and audit records are defined.
5. Review scopes when the workflow boundary, client runtime, or operating owner changes.

Multi-endpoint clients

Use separate MCP server entries for each endpoint. Name each entry by endpoint and purpose so reviewers can see which slice the client is using.

{
  "mcpServers": {
    "factverse-base": {
      "url": "https://your-factverse-host/mcp/base/",
      "headers": {
        "X-API-Key": "fvk_base_key"
      }
    },
    "factverse-pdm": {
      "url": "https://your-factverse-host/mcp/pdm/",
      "headers": {
        "X-API-Key": "fvk_pdm_key"
      }
    }
  }
}

A single key may hold multiple scopes when the customer's access policy allows it. Separate keys can make review and revocation clearer for high-risk workflows.

Review checklist

• The endpoint set matches the workflow boundary.
• The key has the minimum scope set.
• Runtime tool discovery matches the approved access package.
• Compute scopes have a named engineering or analytics reviewer.
• Write scopes have a named operations reviewer.
• Key owner, rotation rule, and revocation path are documented.
• The workflow records evidence and review state for accepted outputs.

Failure handling

Problem	Response
Client sees too many tools	Reduce scopes, split keys, or separate endpoint entries.
Client cannot see an expected tool	Check endpoint URL, scope, module enablement, and runtime discovery.
Compute scope was granted without reviewer	Move back to read-only or name the engineering owner before testing compute.
Write scope was granted without approval path	Revoke or rotate the key and reissue only after draft-action review is defined.
Workflow boundary changes	Re-review endpoint set, scope package, key owner, and run-record requirements.