MCP Gives Agents Handles. It Does Not Give Them Judgment.

A valid MCP tool call can still be a bad business action. That is the distinction most agent demos skip. MCP can tell an agent how to reach a system. It can expose tools, resources, prompts, and connector boundaries in a common shape. It can make integrations cleaner and less bespoke. That is valuable. But the protocol does not know whether the action makes sense inside your company. It does not know that the CRM field is stale because yesterday’s call changed the account state. It does not know that the support owner in Linear is different from the commercial owner in HubSpot. It does not know that the customer-facing email needs legal approval because the account is under DPA review. MCP gives agents handles. A company map gives those handles meaning.

What MCP standardizes

Anthropic introduced the Model Context Protocol as an open standard for connecting AI assistants to the systems where data lives: content repositories, business tools, developer environments, databases, and internal apps. At the simplest level, MCP helps separate the agent client from the external systems it needs. A server can expose capabilities. A client can discover and call them. Teams no longer need a bespoke connector path for every model-app pairing. That solves a real infrastructure problem. A serious agent stack needs addressability:

• what systems can the agent see?
• what resources can it read?
• what tools can it call?
• what arguments does each tool require?
• what result comes back?
• what auth path controls the connection?

Without a protocol layer, every integration becomes custom glue. But addressability is only the first half of the work. The agent also needs action validity.

Tool validity is not business validity

Consider a CRM tool exposed through MCP:

tool: crm.update_opportunity
arguments:
  opportunity_id: string
  stage: string
  next_step: string
  close_date: date

A model can call that tool correctly. The MCP server can validate the arguments. The auth layer can confirm the agent is allowed to invoke the server. The audit log can show the request happened. The CRM can accept the write. Everything can be technically valid and still be wrong. Maybe the opportunity stage in CRM is stale. Maybe the latest call changed the blocker from “budget” to “security review.” Maybe the customer asked for a migration plan, but the promised date is internal-only. Maybe the right next step belongs to customer success, not the account executive. Maybe the agent should draft an internal note, not update the customer-facing next step. The tool schema does not know that. It knows the shape of the call. It does not know the shape of the work. That is where production agents usually break. They do not fail because the connector cannot run. They fail because the connector is running without enough company context around it.

The missing layer is action context

For an agent to act safely, it needs more than a tool list. It needs a runtime answer to these questions:

• What business object is this action about?
• What is currently true about that object?
• Which evidence supports that state?
• Which source wins if the CRM, call transcript, Slack thread, and doc disagree?
• What preconditions must be true before this tool is called?
• Is this a read, draft, internal write, external write, or irreversible action?
• Who approves it?
• Where does the trace go?
• If the human corrects it, what durable state should change?

That is not MCP’s job. That is the company-context layer around MCP. The production architecture should not be “agent directly reasons from tool outputs and writes back wherever it can.” That is how demos become operational vandalism with nice formatting. The better shape is:

flowchart TD
  Agent[Agent runtime]
  MCP[MCP servers]
  Evidence[Evidence + connector metadata]
  Map[Company map]
  Policy[Action registry + permission rules]
  Approval[Human approval]
  Trace[Writeback trace]

  MCP --> Evidence
  Evidence --> Map
  Map --> Policy
  Agent --> Map
  Agent --> Policy
  Policy --> MCP
  Policy --> Approval
  MCP --> Trace
  Approval --> Trace
  Trace --> Map

The agent reads through the map, not just through the connector. It proposes an action against a typed object and state. The action registry decides whether the tool call is allowed, draft-only, approval-gated, or blocked. The writeback leaves a trace. A correction updates the map for the next run. Now MCP is infrastructure under an operating model.

The MCP roadmap is already moving this way

The MCP roadmap is a useful tell. The priorities are no longer only “connect more things.” They include agent communication, governance maturation, enterprise readiness, audit trails and observability, enterprise-managed auth, gateway and proxy patterns, configuration portability, retry semantics, expiry policies, conformance tests, and reference implementations. That is what happens when a protocol hits production. People stop asking only whether the tool can be called and start asking:

• who requested this?
• which server did what?
• how does auth propagate through a gateway?
• how do we log this for compliance?
• what happens when a task fails or expires?
• how do we know clients and servers implement the spec correctly?

Those are real problems. MCP should solve many of them. But even perfect protocol governance does not answer whether a CRM field should change. An audit trail can prove that the agent called crm.update_opportunity. It cannot prove that the source priority was right. Enterprise auth can prove that the agent had permission to invoke a tool. It cannot prove that the action was valid in the current workflow state. Protocol correctness and business correctness are different layers.

What the company map adds

A company map gives the agent the business object model MCP does not own. For a GTM workflow, the map might define:

• Account;
• Opportunity;
• Contact;
• Meeting;
• Commitment;
• Security Review;
• Product Limit;
• Owner;
• Approved Next Action.

More importantly, it defines the relationships:

• meetings create commitments;
• commitments attach to accounts and owners;
• product limits constrain what can be promised;
• security review changes what sales may send;
• approved next actions determine safe writeback.

This is where a company ontology becomes practical. The ontology is not a prettier wiki. It is the object and action model the agent uses before it touches a tool. MCP can expose send_email. The map decides whether this email is allowed, what source evidence it must cite, which owner should review it, and whether the correction should update the account, the policy, or the agent memory.

How to build around MCP

If you are giving agents MCP access, do not start by wiring every connector in the company. Start with one operating loop. Example: security-review follow-up for expansion accounts. Map the loop before you expand the tools:

1. Define the objects: account, opportunity, security review, owner, blocker, approved next action.
2. Bind the sources: CRM for commercial state, call transcript for latest customer ask, Linear for product/security status, Slack for internal owner context, docs for policy.
3. Decide source priority: a newer call can supersede CRM stage, but security policy beats Slack optimism.
4. Define action types: read, draft, internal write, external write, irreversible write.
5. Attach MCP tools to action types instead of exposing them as free-floating powers.
6. Add preconditions: no external email unless security owner approves the claim.
7. Record traces: source evidence, object, state, action, approver, writeback target.
8. Route corrections: when a human says “wrong owner,” update the object state, not just the chat.

That gives the agent a place to stand. It can still use MCP. It can query the CRM, fetch the doc, create the task, update the field, or draft the email. But it acts through context, not around it.

The useful mental model

Think in layers. MCP answers: what can the agent reach, read, or call? Auth and gateways answer: is this caller allowed through this connection path? Tool schemas answer: what arguments make the call syntactically valid? The company map answers: what business object is this, what is true right now, and what action is valid from here? The action registry answers: which side effects are allowed, blocked, or approval-gated? The trace answers: what happened, why, and how do we recover if it was wrong? If you skip the middle layers, MCP can make your agent faster at touching systems it does not understand. That is not production readiness. That is a larger blast radius.

Where this meets Ortelian’s thesis

Most teams give agents access to the territory. That is getting easier. MCP is part of why. The harder question is what map the agent uses when it acts. That map needs objects, relationships, state, evidence, permissions, action rules, traces, and correction loops. It needs to turn messy company inputs into a runtime view the agent can actually use. That is why Access is not a map is still the core idea. Protocols can connect the agent to systems. They do not make the company legible by themselves. MCP gives agents handles. The map gives those handles meaning. Related Ortelian notes:

• Access is not a map
• What is an ontology?
• Why agents do not onboard like people