MCP vs. CRM context layer: what each one does

MCP and CRM context layers get conflated constantly, usually by people who have just wired up an MCP server and are wondering why their agent still gives wrong answers.

Short version: MCP is a connection standard. A context layer is an interpretation and governance layer. MCP defines how an AI application discovers and calls capabilities on an external system. Your context layer defines what the data coming back actually means, which fields are trustworthy, and what the agent is permitted to touch. You want both. Neither does the other's job.

This is the standalone treatment. The CRM AI context layer guide covers the layer itself in depth.

What MCP actually defines

The Model Context Protocol is an open standard for connecting AI applications to external systems. Worth being precise about what that covers, because the scope is narrower than people assume.

An MCP host is the AI application. It creates one MCP client per MCP server, each holding a dedicated connection. The protocol has two layers: a data layer built on JSON-RPC 2.0 that defines discovery and the core primitives, and a transport layer that handles the communication channel, currently stdio for local processes and Streamable HTTP for remote ones.

Servers expose three primitives:

Clients can expose primitives back, currently elicitation, which lets a server ask the user for more input or confirm an action. (Sampling and logging were client primitives too; both are deprecated as of protocol version 2026-07-28.)

The spec draws its own boundary, and it's the clearest statement of the split you'll find. MCP "focuses solely on the protocol for context exchange — it does not dictate how AI applications use LLMs or manage the provided context."

Managing the provided context is the whole job of a context layer.

Three jobs, and MCP does one of them

Getting a CRM answer right takes three separate things. People notice the first, build the second badly, and skip the third.

MCP is genuinely good at the first column. It gives you discovery, a typed schema per tool, notifications when the tool list changes, and a transport story that works locally and remotely. That's real infrastructure and worth adopting.

It has nothing to say about the second and third columns, and it doesn't claim to.

What this looks like when it goes wrong

Wire an MCP server against a raw Salesforce org and you get an agent that can reach every object and understands none of them.

Ask it how many opportunities you created last quarter. It uses the calendar quarter, because nothing told it your fiscal year starts in February. It counts the CPQ system artifacts as real pipeline, because nothing told it to exclude them. It groups by a multi-select picklist and returns a distribution that looks plausible and is arithmetically meaningless.

Every one of those is a correct MCP interaction. The protocol did its job perfectly. The tool was discovered, called with a valid schema, and returned real rows. The answer is still wrong, and the failure is silent, which is the expensive kind.

A faster connection to data you haven't explained is a faster route to a confident wrong answer.

Where the two actually meet

At the tool boundary, and this is the part worth getting right.

If your CRM access runs through an MCP server, that server is your enforcement point. The object whitelist, the field allowlist, and the read-only constraint all belong in its handler, checked in code before the query runs.

The temptation is to write those constraints into the tool's description field instead. Don't. A description is read by the model, and anything the model reads is a suggestion. It holds most of the time, and the times it doesn't are invisible: the agent can't reach Contract, so it answers from Opportunity and nobody sees an error.

server.registerTool(
  {
    name: "query_crm",
    description:
      "Query allowed CRM objects. Business rules and field meanings are " +
      "returned with the result — apply them before answering.",
    inputSchema: querySchema,
  },
  async ({ object, fields, filters }, { userId }) => {
    // Interpretation: loaded and returned to the model.
    const guidance = await loadGuidance({ object, fields });
 
    // Enforcement: checked here, not described in the prompt. An off-allowlist
    // object or field throws before any query runs.
    assertAllowed(object, fields, guidance.policy);
 
    // The query runs as the asking user, so CRM sharing and field-level
    // security still apply underneath the allowlist.
    const rows = await crm.query({ object, fields, filters, asUser: userId });
 
    return { guidance: guidance.payload, rows };
  },
);

Two things about that handler. loadGuidance runs before the query and its output travels back with the rows, so the model gets the rules and the data together rather than being expected to remember rules from three turns ago. And assertAllowed throws. It doesn't warn, log, or return a note. Anything that must never happen has to be the kind of thing that can't happen.

MCP gives you a clean, standard place to put that boundary. It doesn't decide where the boundary goes, or what's on either side of it.

What about permissions?

MCP's transport layer handles authentication, and the spec recommends OAuth for obtaining tokens. That gets you an identity on the connection.

It says nothing about whether that identity should see the renewal-risk field on this particular account. That's a per-field, per-row question your CRM's own permission model answers, and it has two consequences worth knowing.

Run the connector as the asking user and the same question returns different answers for different people, correctly, with the model unaware it's seeing a partial org. And when field-level security hides a field, the platform doesn't error. It returns null, which is indistinguishable from a genuine blank. The permissions section of the main guide goes into both.

What to build first

If you have neither: build the context layer first. A handful of rules against a plain API client beats a perfectly-wired MCP server with no rules behind it, because the rules are what change the answer.

If you already have MCP: you have the access layer and the right place to put the boundary. What you're missing is the rules and the assertAllowed call. Start with the six rules you can write today without research (fiscal calendar, currency, reporting exclusions, attribution, your deprecation convention, and the allowed object list), then grow the rest from answers you logged and traced.

• How to build an AI context layer for your CRM — the concept and the full build
• Salesforce implementation — guidance as a custom object, enforcement in Apex
• HubSpot implementation — custom properties and an Enterprise custom object
• Portable implementation — rules in git, outside any one CRM