ANCC and MCP

MCP standardizes access. ANCC makes that access safe.

What MCP does

MCP (Model Context Protocol) is a transport protocol. It answers: how does an agent call a tool? JSON-RPC over stdio or HTTP. Tool registration, method invocation, structured responses. It connects agents to tools the same way HTTP connects browsers to servers.

MCP does this well. It standardizes the wire format so agents don't need tool-specific adapters.

What MCP does not do

MCP trusts that the tool on the other end is well-built. It has no mechanism to verify that trust.

What this looks like when it breaks

An agent connects to an MCP tool that exposes a deploy method. The tool originally only deployed services. Over time, it absorbed health checks, rollback logic, alerting, and configuration changes. No scope boundaries were enforced. No contract declared what it should not do.

The agent calls deploy expecting a simple rollout. The tool modifies configuration and triggers a restart loop. MCP worked exactly as designed. The system still failed. The failure was not transport. The failure was lack of constraints.

What ANCC does

ANCC is a behavioral contract. It answers: how must a tool be built so agents can operate it safely? SKILL.md declarations, scope boundaries, handoff contracts, doctor readiness, deterministic output, temporal contracts, provenance. It defines the quality of the thing being delivered — not the delivery mechanism.

The relationship

MCP (transport)

ANCC (contract)

MCP without ANCC: agents can call tools, but have no guarantee those tools are bounded, composable, or safe to modify. The transport works perfectly while delivering a tool that bloats into a god-object.

ANCC without MCP: tools are well-built and well-governed, but the agent needs its own adapter to invoke them. The contract is solid but the delivery is custom.

Together: MCP delivers ANCC-compliant tools. The transport is standard. The tool quality is guaranteed. The agent calls a tool through MCP and knows — before invocation — what it does, what it doesn't do, whether it's healthy, and where to hand off.

A concrete example

An agent discovers a tool via MCP. MCP tells it: this tool has a scan method that accepts a target parameter and returns JSON.

That's enough to call it. It's not enough to use it safely.

ANCC tells the agent: this tool scans for security findings. It does NOT remediate, store findings, or replace monitoring. If findings are critical, hand off to an enforcement tool. The tool reports readiness via doctor. Output includes provenance classification. Version 1.4.0 added bloat detection — check the changelog before assuming the old behavior.

MCP answered "can I call this?" ANCC answered "should I call this, what will happen, and what do I do next?"

Where each layer sits

agent needs to act
  → ANCC: determine if the tool is safe to use — what does it do? is it healthy? what are the boundaries?
  → MCP: call the tool — JSON-RPC, structured request/response
  → ANCC: validate output — does it match the contract? where does it hand off?
  → agent acts on structured, validated, bounded result

Why this matters

The MCP ecosystem is growing fast. Hundreds of MCP servers exist. The transport problem is being solved. As MCP servers grow and agents begin modifying tools, lack of structural constraints will cause silent drift and tool bloat. But transport quality does not guarantee tool quality. A perfectly delivered tool that absorbs every adjacent feature, has no scope boundaries, and silently changes behavior between versions is still a liability — it's just a well-connected liability.

ANCC is the quality layer that MCP assumes exists but doesn't enforce. When someone asks "how do I make sure my MCP tools don't degrade over time?" — the answer is conventions, validation, and governance. That's ANCC.

For MCP server authors

If you build MCP servers, ANCC adds:

The transport is MCP. The quality contract is ANCC. Both are needed.