MCP 2026-07-28: what changes when connecting AI agents to your information system

Published on 28 July 2026, the MCP 2026-07-28 specification is the most fundamental revision of the Model Context Protocol since its creation: a stateless protocol, multi round-trip requests, routing headers, hardened authorisation. Here is what changes in practice when connecting AI agents to your ERP, CRM or ticketing system, with a typical architecture, the security rules and a migration checklist.

MCP in 2026: the quick recap

The Model Context Protocol standardises the way an AI application (the host: IDE, assistant, agent) connects to servers that expose tools, resources and prompts. You write an MCP server for your CRM, and any compatible client can use it.

• 25 November 2024: Anthropic releases MCP as open source.
• 9 December 2025: MCP is entrusted to the Agentic AI Foundation, a fund of the Linux Foundation co-founded by Anthropic, Block and OpenAI. The protocol no longer belongs to a single vendor.
• 28 July 2026: publication of the 2026-07-28 specification. According to the official announcement, the Tier 1 SDKs are approaching half a billion downloads a month.

The 7 changes in the MCP 2026-07-28 specification

1. A stateless core

This is the major change (SEP-2575 and SEP-2567). The initialize handshake and the Mcp-Session-Id header disappear. Each request carries its protocol version and the client’s capabilities in _meta. A new server/discover method, mandatory on the server side, lets the client know in advance which versions and capabilities are supported.

Consequence: a request can land on any instance behind a load balancer. If a tool needs state between two calls (a basket, a transaction), the server creates an explicit identifier (a “handle”) that the model passes back as an argument.

2. Multi Round-Trip Requests

Previously, a server that needed information mid-call itself sent a request to the client over an open stream. Now (SEP-2322), it replies with an intermediate result, and the client replays the original request with the answers:

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirmation": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Créer l'avoir de 1 240 € pour le client C-0042 ?",
          "requestedSchema": {
            "type": "object",
            "properties": { "confirme": { "type": "boolean" } },
            "required": ["confirme"]
          }
        }
      }
    },
    "requestState": "eyJhdm9pciI6IkMtMDA0MiJ9"
  }
}

The client asks the user the question, then sends the same tools/call again (new id) with inputResponses and requestState. For an information system, this is excellent news: human confirmation of a sensitive action becomes a standard mechanism of the protocol.

3. Routing by headers

On the Streamable HTTP transport, each POST carries Mcp-Method and, for tools/call, resources/read and prompts/get, Mcp-Name (the name of the tool or prompt, or the resource URI) (SEP-2243). A tool parameter can be copied into an Mcp-Param-{name} header via x-mcp-header, never for sensitive data. The server must reject any request whose headers do not match the body (HeaderMismatch, code -32020): a gateway that routes on the header cannot be fooled by a different body.

4. Cacheable list results

Responses to tools/list, prompts/list, resources/list, resources/read and resources/templates/list now include ttlMs (freshness in milliseconds) and cacheScope (public or private) (SEP-2549), and tools should be returned in a deterministic order, which also improves models’ prompt caching. If the list of tools depends on the caller’s rights, it is private.

5. Hardened authorisation

• RFC 9207 (SEP-2468): authorisation servers should return the iss parameter, and the client must validate it before exchanging the code. This blocks authorisation server confusion attacks (“mix-up”), which PKCE alone does not prevent.
• application_type mandatory during dynamic registration (SEP-837), for desktop and CLI applications.
• Issuer-bound credentials (SEP-2352): never reused with another authorisation server.
• Dynamic Client Registration deprecated in favour of Client ID Metadata Documents (CIMD), while remaining available for compatibility.

6. An extensions framework

Client and server capabilities gain an extensions field. Long-running tasks leave the core for the io.modelcontextprotocol/tasks extension (polling via tasks/get, new tasks/update method, SEP-2663). According to the official announcement, the framework also covers MCP Apps and Enterprise Managed Authorization. Change notifications go through a single subscriptions/listen stream, to which the client subscribes by notification type.

7. Deprecations and SDKs

Roots, Sampling and Logging are deprecated (SEP-2577) but remain functional for at least twelve months: pass directories as tool parameters, call the model API directly, log via stderr or OpenTelemetry. The HTTP+SSE transport is deprecated and resumption of SSE streams (Last-Event-ID) is removed: an interrupted stream means the request must be restarted.

The four Tier 1 SDKs (TypeScript, Python, Go, C#) implemented the revision as soon as it was published, Rust in beta. The official SDK table now classes Rust as Tier 1 (100% pass rate on the required conformance tests), Java and Ruby as Tier 2, and PHP, Kotlin and Swift as Tier 3. For a PHP stack, this needs a decision: a Tier 3 SDK, or an MCP server in TypeScript or Go in front of your Symfony or Laravel application.

Connecting agents to your information system: the typical architecture

This is the architecture we recommend for exposing an information system to autonomous agents:

• Agent host (IDE, internal assistant, ticket agent): model, authorised tools, user confirmations.
• MCP gateway: single entry point, OAuth, filtering by Mcp-Method / Mcp-Name, rate limiting, audit log.
• MCP servers by domain: ERP, CRM, ticketing, documentation.
• Identity provider: minimum-scope tokens, issued for each MCP server.
• Business systems, through their APIs or a read replica, never with direct write access to the production database.

One MCP server per business domain

Splitting by domain limits the impact of a compromised server, simplifies OAuth scopes and makes the audit readable. Avoid the catch-all server: the model also chooses less well among too many tools.

Example: exposing a Postgres database read-only

The barrier must be in the database, not in the prompt. On a replica:

CREATE ROLE mcp_lecture LOGIN;  -- mot de passe injecté depuis le coffre-fort
ALTER ROLE mcp_lecture SET default_transaction_read_only = on;
ALTER ROLE mcp_lecture SET statement_timeout = '5s';
GRANT CONNECT ON DATABASE crm TO mcp_lecture;
GRANT USAGE ON SCHEMA reporting TO mcp_lecture;
GRANT SELECT ON ALL TABLES IN SCHEMA reporting TO mcp_lecture;

default_transaction_read_only can be changed by the session: it is a second barrier. The real protection is the rights limited to SELECT on a schema of views that mask sensitive columns.

Security: the non-negotiable rules

Read-only by default and an allowlist

In our iones lab experiment EXP-01, a team of 8 developers used 5 MCP servers for 8 weeks: Redmine read-only, Postgres read-only, Playwright, project documentation and Git. An MCP server with write access to Redmine was dropped after 2 tickets were modified by mistake. Since then, our rule is simple: read-only by default, write access only on an explicit allowlist.

An example of a policy applied by the gateway (illustrative format, to be adapted to your tool):

serveurs:
  crm:
    outils_autorises: [client_rechercher, historique_contacts, note_creer]
    confirmation_humaine: [note_creer]      # via MRTR / confirmation de l'hôte
  ticketing:
    outils_autorises: [ticket_lire, tickets_similaires]
  base_reporting:
    outils_autorises: [requete_lecture]
par_defaut: refuser                         # tout outil non listé est bloqué
epinglage_descriptions: sha256              # alerte si une description d'outil change

The specification goes in this direction: for tools, there should always be a human in the loop able to deny a call, and tool annotations (such as readOnlyHint or destructiveHint) must be considered untrusted unless they come from trusted servers.

OAuth: what the specification requires

The MCP security best practices are explicit:

• No “token passthrough”: an MCP server only accepts tokens issued for it and never relays the client’s tokens to a downstream API.
• Minimum scopes: read first, elevation on demand, never * or admin from the outset.
• Random state handles, bound server-side to the authenticated user: possessing a handle does not amount to authentication.
• Local servers: exact command displayed before execution, sandbox, listening on localhost only.

Prompt injection and tool poisoning

An agent reads content it does not control: tickets, emails, web pages. An instruction hidden in a ticket can try to hijack the agent: this is prompt injection, still number one (LLM01) in the OWASP Top 10 2026 for LLM applications. A variant specific to MCP is tool poisoning, described by Invariant Labs on 1 April 2025: malicious instructions are hidden in a tool’s description, invisible to the user but read by the model.

Countermeasures:

• only servers whose code or publisher you control;
• pinning of tool descriptions (fingerprint), with an alert on change;
• content returned by a tool treated as data, never as an instruction;
• separation of flows: an agent that reads external emails does not write to the ERP;
• blocking any unlisted action at the gateway.

In our EXP-06 experiment on autonomous agents, the action allowlist and the blocking of any command touching production intercepted 7 risky actions, including 2 deletions of test data. These guardrails transpose directly to MCP tools.

Cloud-native deployment: what statelessness simplifies

Before 2026-07-28, an HTTP MCP server with sessions required session affinity or shared storage. Now:

• Horizontal scaling: identical replicas behind a round-robin load balancer, with standard Kubernetes autoscaling.
• Zero-downtime deployments: no session to migrate; an interrupted stream is simply restarted.
• Header-based network policies, for example limiting tool calls more strictly than list reads:

map $http_mcp_method $mcp_cle_outils {
    default       "";
    "tools/call"  $binary_remote_addr;
}
limit_req_zone $mcp_cle_outils zone=mcp_outils:10m rate=5r/s;

server {
    location /mcp {
        limit_req zone=mcp_outils burst=10;
        proxy_buffering off;   # flux SSE
        proxy_pass http://serveurs_mcp;
    }
}

• Observability: propagation of the OpenTelemetry trace context (traceparent) in _meta, from the agent to the business system.

This is the work we do on the infrastructure, DevOps and web security side: containers, Kubernetes (AWS, OVHcloud), Grafana monitoring, secrets.

Migrating from 2025-11-25: the checklist

• [ ] Inventory servers, clients, SDKs and versions; update the SDKs (breaking changes)
• [ ] Remove any dependency on Mcp-Session-Id and replace implicit state with user-bound handles
• [ ] Replace server-initiated requests with the MRTR pattern
• [ ] Add ttlMs and cacheScope to lists; order tools deterministically
• [ ] Validate iss, bind credentials to the issuer, plan for CIMD
• [ ] Route and filter on Mcp-Method / Mcp-Name in the gateway
• [ ] Replace Logging with OpenTelemetry and Sampling with a direct call to the model
• [ ] Test compatibility with older clients, review the allowlist and OAuth scopes

Frequently asked questions

MCP 2026-07-28: the right time to industrialise your agent connectors

The 2026-07-28 specification makes MCP an infrastructure protocol: stateless, routable, cacheable, with authorisation aligned with OAuth best practice. The scope, read-only access, the allowlist and monitoring remain your responsibility.

Do you want to connect agents to your ERP, CRM or ticketing system without opening a breach? We design and deploy MCP servers and autonomous agents with their guardrails, directly or on a white-label basis for agencies. Contact us: reply within 48 to 72 hours, under NDA.