Based on the current stable MCP specification
Model Context Protocol can give AI applications a consistent way to discover and call capabilities across business systems. The protocol is an interoperability layer, not an operating model. Organisations still need to decide which actions exist, who may invoke them, when approval is required and how every consequential result is evidenced and recovered.
Protocol fact
Model Context Protocol is an open protocol for exchanging context and capabilities between AI applications and external systems. It defines participant roles and self-contained request and response messages, including how clients can discover and invoke tools, read resources and use prompts. The specification defines the interface between participants; it does not certify the safety, correctness or business suitability of the capabilities behind that interface.
Protocol statements on this page use the stable 2026-07-28 specification as their baseline. TechOne positions are explicitly identified as design and operating recommendations.
Protocol boundary
Illustrative architecture
A gateway, registry and connector are useful architectural terms, but they are not interchangeable MCP primitives. Naming the role correctly prevents one component from becoming an invisible trust shortcut.
Identity and policyPrincipal, tenant, scopes, business permission and approval.
Operational evidenceTrace, policy decision, tool version, result class and downstream confirmation.
TechOne reference model. A gateway is optional; source-system authorisation and business rules remain authoritative.
Why this changes integration architecture
The 2026-07-28 core does not depend on protocol-level session state between requests. Where continuity is required, state is represented explicitly through mechanisms such as task identifiers or at the application layer, which makes ownership and recovery decisions more visible.
The specification adds a formal extensions framework, allowing capabilities to evolve without placing every feature in the core protocol. Enterprises therefore need an extension acceptance and versioning policy.
Tasks are an optional draft extension for operations that continue beyond a single request. Where supported, they improve interoperability but do not decide timeout, cancellation, compensation or accountable ownership.
The current baseline strengthens issuer validation and client registration guidance, while enterprise-managed authorisation offers a path for centrally governed access. Business entitlements and action-level policy still sit outside the protocol.
As protocol support becomes commonplace, the durable enterprise value is the quality of the capability catalogue: precise contracts, appropriate permissions, reliable refusal, operational evidence and controlled change.
Architecture before implementation
SDK selection is downstream of these decisions. If they are left implicit, the first connector quietly becomes the identity model, policy model and operating model for everything that follows.
Use it where multiple AI clients need discoverable, reusable capabilities. A stable one-to-one workflow may be clearer and easier to assure as a direct API or conventional integration.
Choose server and gateway boundaries by system ownership, data sensitivity and failure domain. Avoid one universal server that collapses unrelated privileges into a single credential and control plane.
Decide whether an operation uses delegated user identity, a workload identity or a controlled service account. Preserve the initiator, authoriser and executing identity as separate evidence where they differ.
Define which records, fields and context may enter the model, leave the source system or appear in a result. Apply tenant isolation, purpose limitation, redaction, retention and residency rules before exposing the capability.
Prefer named business operations with typed parameters, explicit preconditions and bounded outputs over generic query, script or record-update access.
Classify read, reversible write, consequential write and destructive operations. Apply stronger validation, approval and isolation as the consequence increases.
Define validation failures, policy refusals, timeouts, duplicate handling, partial completion, downstream confirmation and rollback or compensation before production release.
Assign owners for the tool, source system and control policy. Specify monitoring, evidence retention, version compatibility, deprecation and incident response.
Control profiles, not sector slogans
Sector readiness is expressed through identity, approval, evidence, resilience and data-handling controls. Regulations and internal policy still require a separate assessment.
High-integrity transactional controls
Use distinct tools for retrieval, draft preparation, posting and payment. Validate accounting periods, entities, amounts and duplicate keys; preserve segregation of duties; require approval for consequential postings; and confirm the committed state from the source system.
Reversible operations with strict production boundaries
Keep telemetry read-only and separate from configuration changes. Bind tools to environments and approved resources, enforce maintenance windows, capture pre-change state and provide tested rollback. Destructive actions require an independent approval path.
Identity, privacy and outbound consequence controls
Restrict contact and message data by purpose, record the source evidence, preserve sender identity and distinguish draft creation from sending. Approval should cover the exact recipient, channel and content, with rate limits and a recorded CRM outcome.
Provenance and human accountability controls
Retain links to authoritative sources, expose uncertainty and exceptions, apply document-level access and retention policy, and separate generation from formal issue. A named reviewer remains accountable for regulated or legally significant output.
Environment and change-management controls
Separate repository reading, branch changes, CI execution and deployment. Keep secrets outside model context, constrain work to approved repositories and environments, require code review for material changes and retain deployment evidence with a recovery path.
Technical field guides
Enterprise architecture
Enterprise architecture
Enterprise architecture
Evidence boundary
Because MCP evolves quickly, every technical page states the protocol revision it was checked against. Roadmap items are not presented as current guarantees.
Direct answers
No. MCP provides protocol mechanisms that can support a secure design, including structured capabilities and an authorisation framework. Security still depends on deployment boundaries, identity, credentials, source-system permissions, validation, approval and operations.
No. An MCP server usually sits above APIs, databases or platform services and presents selected capabilities to an AI client. Conventional APIs, events and workflow engines remain appropriate where discovery by AI clients is not the requirement.
No. OAuth can establish and constrain access to a protected resource. It does not decide whether a specific invoice, deployment, message or record change is permitted under business policy. That decision must be enforced at the capability and source-system layers.
Not on their own. The MCP project describes annotations as hints supplied by a server, not a security boundary. Clients may use them to improve handling, but enforcement must rely on trusted policy and the behaviour of the underlying operation.
Approval is appropriate when a wrong action would create material financial, legal, operational, privacy or external-communication consequences and automated controls cannot reduce that consequence sufficiently. Approval should show the exact action and parameters, not a generic permission prompt.
Usually not. Boundaries should follow ownership, sensitivity and failure impact. A smaller set of purpose-built capabilities is easier to permission, test, monitor and retire than a generic interface with broad source-system access.
It may be unnecessary for a stable one-to-one integration, a tightly deterministic workflow or a use case where no AI client needs capability discovery. Protocol adoption should follow an operating requirement, not precede one.
AI Adoption selects valuable priorities, decision owners and working rules. AI Enablement prepares identity, data, platforms and controls. AI Agents use governed capabilities to perform work. MCP can be one interface between those agents and enterprise systems; it is not a substitute for any of the three disciplines.