[Discussion] Design inline MCP dependency format vs MCP Registry alignment

[danielmeppiel]

Context

PR #123 (fixing #121 — transitive MCP propagation) introduces an inline dict format for MCP dependencies in apm.yml:

dependencies:
  mcp:
    - io.github.github/github-mcp-server          # Registry string (existing)
    - name: my-knowledge-base                      # Inline config (new)
      type: http
      url: https://my-kb.example.com/

While the transitive propagation fix for registry strings is straightforward, the inline dict format is a schema design decision that needs deliberate discussion before shipping, especially given the evolution of the MCP standard.

Questions to Resolve

1. Do we need an inline format at all?

The MCP Registry spec now supports subregistries — enterprise/private registries that implement the same API. Private servers that can't be in the public registry could live in an organization's subregistry instead of being hardcoded inline in apm.yml.

Counter-argument: Subregistries add operational overhead. A lightweight inline format has clear DX value for quick prototyping, private servers, and self-hosted setups.

2. Schema alignment with MCP Registry server.json

The proposed inline format ({name, type, url, headers}) diverges from the MCP Registry's server.json schema, which uses:

• Namespaced identifiers: io.github.user/server-name
• packages[] with registryType, identifier, transport
• Transport types: stdio, sse, streamable-http (not just sse/http)
• environmentVariables[] for env var declarations

Should APM's inline format align more closely with server.json, or is a simpler format acceptable for the inline use case?

3. Security considerations

Inline deps from transitive packages mean a dependency you didn't directly choose can inject arbitrary URLs into your MCP config. This raises:

• URL scheme validation: Should we restrict to https:// and http:// only? (reject file://, data:, etc.)
• Trust model: Should transitive inline MCP deps require explicit opt-in from the consumer project? (e.g., an allow-list or confirmation prompt)

4. Runtime adapter integration

The current PR writes inline configs directly to .vscode/mcp.json and ~/.copilot/mcp-config.json, bypassing the existing ClientFactory / adapter pattern. The adapters already have update_config() methods that could handle this. Should inline deps flow through the adapter layer to keep configuration knowledge centralized?

Proposal

Split the work:

1. Bug fix (PR feat: support transitive MCP dependency propagation #123 scope reduction): Transitive propagation for registry string MCP deps only — this is uncontroversial and fixes the reported issue.
2. Feature (this issue): Design and implement inline MCP dep support as a separate effort with explicit schema decisions.

References

• Issue [BUG] MCP dependencies from transitive packages are not propagated to the consumer project #121 — Original bug report
• PR feat: support transitive MCP dependency propagation #123 — Current implementation (includes both fixes)
• MCP Registry spec
• MCP Registry API
• MCP Registry subregistries