Skip to content

Plan MCP dependencies

MCP (Model Context Protocol) is the only way an EAP agent reaches external systems. If an MCP server isn't listed under mcp: in your project's Registry YAML, it is unreachable from inside the runtime — regardless of what your agent prompt says.

This page is the step between authoring skills and writing the Registry YAML: decide which MCP servers your project actually needs, and at what access level.

Principles

  • list only what you need — request the minimum set of MCP servers your skills actually call
  • read first, gated for writes — prefer read-only MCPs; route any state-changing operation through an approval gate
  • scope per project — MCP authorization is per project, not per team; another project under the same team does not inherit yours
  • no direct internet — agents cannot reach arbitrary URLs; if you need a new external system, propose it as a new MCP server first

Discover Available MCPs

The current set of governed MCP servers and their permission groups is documented in the MCP catalog. Start there.

If a system you need isn't in the catalog:

  • check whether an existing MCP already exposes a comparable capability
  • if not, work with the EAP platform team to add a new MCP server — do not attempt direct integration from your agent

Inventory Your Dependencies

For each skill in your project, write down:

Question Why it matters
Which MCP servers does this skill call? drives the mcp: map in your Registry YAML
Read-only or state-changing? state-changing calls must run behind an approval gate
Required vs optional? optional MCPs should degrade gracefully when missing
Who owns each MCP server? reviewers will ask; you also need an escalation path at runtime

Consolidate per-skill inventories into one project-level table — this is what you'll paste into your PR description for review.

Access Levels

EAP enforces tool access via allow / deny / ask controls. Common patterns:

  • read MCP — allow by default for the skills that depend on it; safe to call without prompting
  • gated MCP (state-changing) — ask for explicit per-call approval, or deny until policy allows

Declare the intended access level inside each skill's MCP dependencies block; the platform team will check it against what the MCP server actually exposes.

The Registry YAML's mcp: block is a single project-level definition — it has no per-environment overrides. If you need staging to behave differently from production (e.g., to gate writes), encode that in the skill / agent logic that runs on the staging branch, not in the Registry.

Credentials

You never put secrets in your agent repo or the Registry YAML. Credentials live in Keeper Vault and are injected by Kubed at runtime. The Registry YAML references the environment variable names, not the values:

auth:
  type: client_credentials
  token_url: https://idbroker.webex.com/idb/oauth2/v1/access_token
  client_id_env: AIOPS_MCP_CLIENT_ID
  client_secret_env: AIOPS_MCP_CLIENT_SEC
  scope: openid

If your MCP server needs a new credential, file that with the platform team — don't hard-code or commit.

Common Mistakes

  • requesting broad MCP access "just in case" — reviewers will reject it
  • listing MCPs in your agent prose without declaring them in any SKILL.md or Registry YAML
  • depending on a system that has no MCP server yet, and trying to reach it directly — this will not work
  • putting secrets or tokens in the Registry YAML or agent repo

Next