APC Owns Project Context. MCP Owns Tool Connectivity.

A lot of AI tooling discussions collapse two different problems into one.

The first problem is project meaning: which agent roles exist here, which rules matter, which memory is durable, and which MCP servers this repository expects. That is the APC side.

The second problem is external capability: how an AI app talks to a filesystem server, a GitHub server, a database, or any other tool through a standard protocol. That is the MCP side.

These layers work together, but they should not be confused.

APC answers: what should an agent know about this repository?

APC is the portable context layer. It lives in the repository as AGENTS.md plus .apc/. Its job is not to run anything. Its job is to make project truth inspectable, reviewable, and clone-safe.

Typical APC content includes:

• agent definitions
• project rules
• curated memory
• skills
• metadata
• MCP hint files such as .apc/mcps.json

That last item matters. A repo can say, "this project expects a filesystem MCP" or "this project uses a GitHub MCP." But APC still does not become an MCP server. It only records project-owned expectations.

That boundary is why APC can travel with the repo. If you switch editors, machines, or model vendors, the project contract still means the same thing.

MCP answers: how does the runtime reach tools outside the model?

MCP solves a different problem. It defines how an AI host, client, and server talk to each other. It covers transports, tool discovery, schemas, and tool calls.

If APC says a project expects a filesystem server, MCP defines how that server exposes tools/list, how a client calls one of those tools, and what JSON shape the request uses.

So MCP is not "project context with tools added." It is the tool connectivity layer itself.

That distinction prevents a common mistake: treating .apc/mcps.json like a place to dump real credentials, live sessions, or runtime state. It should only hold safe project hints such as names, commands, URLs, non-secret args, or environment variable names when useful.

Where APX fits

APX is the daily-use runtime layer between those two concerns.

APX reads APC from the repository, then handles the operational work APC deliberately avoids: daemon lifecycle, agent execution, message logs, sessions, runtime-local memory, and MCP registration and resolution.

That is why APX can merge MCP servers from three scopes:

• shared in .apc/mcps.json
• runtime in ~/.apx/projects/<id>/mcps.json
• global in ~/.apx/mcps.json

And it can do that without turning APC into a secret store. The repo can commit the safe, shared expectation. The runtime can keep tokens and machine-local endpoints outside version control.

In practice, the split looks like this:

• APC says this repo uses certain agents, rules, and MCP expectations.
• MCP defines how those external servers expose tools.
• APX reads APC, resolves the MCP registrations, and gives agents a usable local runtime.

That division is small, but it matters a lot.

Practical example

Imagine a repo that needs filesystem access and optional GitHub access.

The project can commit a shared .apc/mcps.json entry for the filesystem server, because that is safe and team-wide.

A developer who also wants GitHub automation should not commit a token into APC. Instead, APX can store that server in runtime scope under ~/.apx/projects/<id>/mcps.json.

Now the same repository stays portable, but each machine can still have richer tool access locally.

That is the right tradeoff:

• APC keeps project meaning portable.
• MCP keeps tool communication standard.
• APX keeps runtime behavior local and practical.

The short rule

Use APC to describe the repository.

Use MCP to connect tools to the runtime.

Use APX when you want one local runtime that reads APC, resolves MCP cleanly, and makes both useful in real work.