The Model Context Protocol, or MCP, provides a common language for connecting a model-based application to tools and sources of context. A client can discover capabilities, call a tool, or embed an interface without developing a connector specific to each pair of applications.
This standardization speeds up integration. It does not turn a server into a trusted component. The company must always decide who can use it, what data they see, what actions they perform, and how it is monitored.
The official specification
2026-07-28introduced a stateless core and several major evolutions; the SDKs and deprecations must be checked before implementation.
What MCP standardizes
MCP describes the exchanges between a client application and a server that exposes capabilities. Depending on the version and extensions, these may include tools, resources, interfaces, or long tasks.
The protocol provides:
- structured discovery;
- input and output diagrams;
- transport;
- request cycle;
- authorization mechanisms;
- compatibility conventions;
- SDK in several languages.
It does not define the business rules, the level of confidence, the data classification, or the user's actual rights in the target system.
What the 2026-07-28 revision changes
The specification published on July 28, 2026 adopts a stateless protocol core. The handshake and the session managed at the protocol level are removed, in order to facilitate routing, scaling, and classic HTTP infrastructure. The application can maintain state, but it no longer has to rely on an implicit MCP session.
The revision also strengthens authorization, formalizes the framework for extensions, introduces or stabilizes mechanisms such as multi-step requests, MCP Apps, and the Tasks extension for long-running jobs. Some legacy capabilities are deprecated. The team must read the changelog and test its clients and servers with the appropriate SDKs.
Distinguish between protocol and enterprise architecture
An enterprise architecture generally adds:
- registry of approved servers;
- gateway or proxy;
- identity and delegation;
- tool policy;
- network filtering;
- secrets;
- observability;
- sandbox ;
- approvals;
- versioning and withdrawal process.
The client should not be able to freely connect to any server discovered on the Internet from a sensitive environment.
Design identity and authorization
Access must reflect the user and the context. A server must not receive a general token granting more rights than the person. Scopes are limited to the necessary capabilities and resources.
The principles include:
- explicit consent;
- token audience;
- short duration;
- client/server separation;
- rotation;
- protection against abusive redirects;
- revocation;
- authorization log.
Business rights are always re-checked by the target service. An MCP tool is not a way to bypass the usual APIs.
Expose safe tools
The tools are small, named according to the trade, and validated by a strict schema. They do not provide access to a shell or arbitrary query. They return structured results and limit the data.
For an action:
- identity;
- scope;
- validation;
- idempotence;
- preview;
- approval;
- verification;
- audit;
- compensation.
The description of the tool helps the model, but the independent policy determines whether it can be called.
Treat resources and interfaces as unreliable data
A server can expose content containing malicious instructions. The client must separate data and instructions and apply the same protections as for the web or email.
MCP Apps or server-rendered interfaces are isolated, subject to a content policy, and deprived of implicit access to secrets. Their origin and capabilities must be visible to the user.
Manage long tasks
Agentic tasks can last beyond a single request. Task extension provides a model, but the application still has to manage:
- identity and authorization during the period;
- state;
- cancellation;
- resumption;
- deadline;
- budget;
- notification;
- result;
- idempotence.
A task must not retain indefinite power. Permissions can expire or require new approval before a sensitive step.
Stateless does not mean without state
The stateless core simplifies the infrastructure, but applications retain conversations, tasks, approvals, and results. This state must be explicit, stored in a governed system, and associated with an identity.
Header-based routing and cached lists require a privacy and invalidation policy. Metadata must not reveal forbidden capabilities.
Managing a server catalog
Each server is a provider of software, data, and actions. The registry must include:
- owner;
- origin;
- version ;
- abilities;
- data;
- rights;
- environments;
- dependencies;
- support;
- risks;
- approval status;
- review date.
MCP Architecture 2026-07-28 with stateless core, authorization, tools, Apps and Tasks extension.
Qualify a third-party server
The team examines code or origin, update policy, vulnerabilities, data collection, and destinations. A server can change its tools; the client must detect the difference and request new approval when the risk changes.
The pilot is carried out in an isolated environment, with synthetic data and limited tokens. Error and withdrawal behaviors are tested.
Gateway and proxy
An enterprise gateway can centralize authentication, allowlist, limits, logs, and routing. It reduces dispersion but becomes a critical component. It must preserve the user's identity and avoid becoming a super-account.
It can block certain tools, transform scopes, apply a destinations policy, and provide metrics. The logs minimize sensitive parameters.
Observability
Each call is correlated with the application, the user, the server, the tool, the version, and the result. The metrics track latency, errors, volume, costs, refusals, approvals, and destinations.
An increase in calls, a new tool, or an unusual destination triggers an alert. The cut-off capacity allows a server to be suspended without deploying all clients.
Migration to 2026-07-28
The migration must begin with an inventory of clients, servers, SDKs, and features used. The changelog identifies deprecated items and changes in transport or authorization.
The approach includes:
- compatibility tests in a separate environment;
- SDK update;
- removal of dependencies on the protocol session;
- adaptation of the authorization;
- validation of the diagrams;
- extension tests;
- gradual deployment;
- observation;
- removal of the old path.
Clients and servers may require a period of versioned coexistence.
Safety tests
Tester:
- unapproved server;
- tool change;
- scope too broad;
- token intended for another server;
- injected content;
- generic tool;
- malformed response;
- endless task;
- cancellation;
- external destination;
- loss of connection;
- revocation.
The scenarios are becoming a regression suite.
MCP as an integration contract
MCP reduces the cost of connectors and promotes an open ecosystem. Its adoption in companies requires the same discipline as APIs: catalog, version, security, observability, and accountability.
Partitech can develop MCP servers and clients, design the gateway, qualify the tools, and support the migration to the 2026-07-28 specification. The protocol then becomes a controlled component of the agent platform, not an open door to all tools.
Let's talk about your project
Design a secure and governed MCP catalog with Partitech. Contact Partitech.