DocumentationConceptsAPC vs MCP

APC vs MCP

APC and MCP are complementary, not competing.

MCP is an open protocol for connecting AI applications to external systems such as files, databases, tools, services, and workflows. The official MCP documentation describes MCP with a host/client/server architecture, JSON-RPC messages, capability negotiation, and primitives such as tools, resources, and prompts.

APC does not redefine that protocol. APC gives a repository a portable place to say which project context and MCP expectations matter.

Different layers

LayerAPCMCP
Primary concernProject-owned contextExternal tool connectivity
Typical contentsagents, skills, rules, metadata, curated project memory, MCP hintstools, resources, prompts, transports, schemas, requests
Where it livesrepository filesystemMCP servers and MCP client integrations
Main question”What should an agent know about this project?""What external capabilities can this AI app call?”

APC

APC standardizes durable project context inside the repository.

Typical APC concerns:

  • persistent agent identity
  • project-local instructions
  • role definitions
  • curated project memory files
  • project-level MCP hints

MCP

MCP standardizes connections between AI systems and external tools or services.

Typical MCP concerns:

  • host, client, and server roles
  • stdio and Streamable HTTP transports
  • JSON-RPC lifecycle and capability negotiation
  • tools, resources, and prompts
  • request and response schemas
  • tool discovery through tools/list
  • tool execution through tools/call

Working together

A project using APC may include .apc/mcps.json to declare project-owned MCP expectations. That does not replace MCP. It gives compatible tools a local place to discover which MCP servers matter to the project.

For example:

project-root/
└── .apc/
    └── mcps.json      ← project says "this filesystem MCP matters here"

An MCP host or helper runtime still performs the real MCP work:

AI application / runtime
└── MCP client
    └── MCP server     ← exposes tools/resources/prompts over MCP

Boundary rule

.apc/mcps.json should be treated as a project-owned hint file, not as an MCP server and not as a secret store.

Good .apc/mcps.json content:

  • server names
  • commands or URLs needed by the project
  • non-secret arguments
  • environment variable names, when useful

Bad .apc/mcps.json content:

  • API keys
  • bearer tokens
  • personal account IDs
  • runtime session IDs
  • provider conversation URLs

Practical summary

  • Use APC to describe the project.
  • Use MCP to reach tools outside the model.
  • Use APX or another runtime if you want one local daemon to read APC, merge MCP configs, and dispatch agents across tools.

References

One Context, One NameProject Context