MCP and enterprise tool integration
Understand APIs, backend MCP and WebMCP in one guide: where each fits, how tool contracts evolve, and which identity, permission and context boundaries the application must enforce.
A support assistant should read a ticket, find the relevant account policy and prepare a status change. The ticket service already has an API. Adding MCP can make its capabilities available to compatible AI applications, but it does not create a new authority to read every ticket or change every account. The integration succeeds when its convenience preserves the service’s existing boundaries.
Start with the service API#
An API defines operations, inputs, responses and authentication for a service. MCP defines a common protocol through which compatible AI hosts and servers exchange tools and context. A server can wrap an ordinary API, but the API remains responsible for the actual business operation. MCP is neither a model nor a database, and connecting a server does not make its contents trustworthy.
| Integration lane | Typical path | Where business authorization belongs |
|---|---|---|
| Ordinary application | Application → service API | Service operation and record checks |
| Backend MCP | AI host/client → MCP server → service API | MCP boundary plus authoritative service checks |
| Experimental WebMCP | Browser agent → page tool → service API | Web session/origin boundary plus service checks |
Separate capabilities from their descriptions#
The MCP specification exposes tools for callable operations, resources for contextual data and prompts for reusable interaction templates. A tool can have an input schema, an output schema and structured content. Those structures help a client understand an interface; they do not prove that a returned value is true. A resource can contain hostile instructions just as a web page can.
Tool annotations are hints, not an enforcement layer. In particular, a read-only hint cannot prevent a malicious or incorrectly implemented server from writing data. Trust decisions depend on the server, credentials and actual implementation. Review both the advertised contract and the downstream permissions before making a capability available to an assistant.
- Earlier deployed revisions
Expect compatibility differences
Older MCP deployments may implement session and initialization behavior described by their pinned specifications. Do not combine old transport examples with new request metadata without checking the client and server versions.
Source ↗ - 28 July 2026 revision
Requests become self-contained
This revision removes protocol sessions and the initialize/initialized handshake. Version and capability information travel with requests, and server discovery advertises supported versions. Long-running operations use an optional tasks extension.
Source ↗ - 9 September 2026 draft
WebMCP remains a browser proposal
The current draft exposes page tools through Document modelContext. It is a draft community report, not a stable universal browser capability. This guide deliberately avoids a copy-and-paste browser API example that could imply tested compatibility.
Source ↗
Authenticate the caller, then authorize the record#
For HTTP transport, the current MCP authorization specification describes protected resource servers and OAuth-based authorization. Transport authentication answers which client or user presented a valid credential. Business authorization still asks whether that identity may read ticket T-42 or perform its proposed transition. A model-supplied user ID must never override the authenticated identity.
Use tokens intended for the correct resource audience and minimum scopes. Do not forward an arbitrary upstream token to a downstream API as if it were universally valid. The MCP security guidance identifies token passthrough and confused-deputy risks; its session examples belong to the older dated revision, while audience validation remains a relevant boundary. Keep secrets out of model-visible descriptions, prompts and routine logs.
Local stdio servers have a different execution and credential model from remote HTTP servers. Installing one can grant a local process access to files, environment variables or network destinations. Treat the executable and its update mechanism as software dependencies. A convenient local connection is not equivalent to a safely sandboxed integration.
Build a useful read-only path first#
For the illustrative support service, start with search_tickets and get_ticket_evidence. The first returns a bounded list of authorized IDs and summaries; the second returns selected evidence for a chosen ticket. Neither accepts an unrestricted SQL fragment or an arbitrary filesystem path. Separate a prepare_status_change operation from a later commit operation so that investigation does not silently acquire write authority.
A status proposal should contain the exact ticket, expected record version, requested state, justification and required reviewer. The commit service independently checks allowed transitions and current permission. A human approval attaches to that precise proposal, with an expiry. If the ticket changes in the meantime, require the proposal to be refreshed instead of applying an old decision to new facts.
Write contracts for business tasks#
| Contract element | Example design | Failure prevented |
|---|---|---|
| Bounded input | Ticket identifier; enum for allowed evidence type; capped page size | Unbounded queries and ambiguous intent |
| Identity | Derived from verified runtime credentials | Caller impersonation through model arguments |
| Evidence output | Record ID, version, observed time, selected fields | Untraceable or stale answers |
| Structured failure | Access denied, not found, stale version, retryable failure | Model guessing whether an action succeeded |
| Write receipt | Operation ID, committed version and outcome | Confusing a proposed change with a completed change |
Reject unexpected parameters rather than ignoring a hidden recipient or account override. Constrain strings, arrays and nested structures. Anthropic’s tool-design article supports task-oriented tools and meaningful output; the contract above is an original application design. Evaluate whether the model chooses the correct tool and supplies correct arguments, not merely whether JSON parsing succeeds.
Keep discovery useful and bounded#
A host does not benefit from placing every enterprise operation into every model request. Organize capabilities by task and permission scope, and provide concise descriptions that distinguish similar operations. Discovery and lazy-loading behavior depend on the actual client and protocol version. Do not assume that a protocol feature automatically creates an optimal model context.
Budget tool descriptions and results alongside the user request and evidence. Avoid replacing clear contracts with cryptic abbreviations solely to save tokens. If a tool is omitted because it is irrelevant or unauthorized, keep that distinction in application state without exposing sensitive capabilities to users who should not know they exist.
Make truncation visible#
Set maximum records, bytes and elapsed time per request. Return an explicit next-page token and a truncated indicator when more permitted results exist. Stable pagination should not duplicate or silently omit records when data changes; use a documented snapshot or cursor strategy where the service supports it. A summary of the first ten tickets must not be presented as a complete account history.
Large attachments should be retrieved through an authorized detail path, not embedded automatically in every response. Normalize errors into a small documented set, but retain a correlation ID for investigation. Limit retries and respect throttling. An inaccessible record should not leak its title, customer name or hidden existence through a detailed error message.
Check again when the action runs#
Permissions can change between discovery, planning, approval and execution. Revalidate the authenticated identity, object scope and operation at the last responsible boundary. For writes, check the record version and the approval digest as well. Revocation tests should occur mid-run while caches are warm, not only before a fresh login.
The service should enforce idempotency for retryable writes and return the original operation receipt when the same valid request is repeated. A timeout does not prove failure; the server may have completed the change. Reconcile an ambiguous result before another attempt. MCP supplies an integration vocabulary, while business duplicate prevention remains part of the application contract.
A page tool inherits a browser setting#
WebMCP describes tools exposed by a live web page through declarative forms or imperative JavaScript. The browser setting introduces origin, session and visible-page concerns that differ from a backend connector. A page may already be signed in as a powerful user, so a browser tool can become consequential even when no new credential is requested.
Treat preview interfaces as experiments#
Chrome’s February 2026 announcement describes an early preview program. The September draft is explicit about its non-standard status. Before adopting it, verify the actual browser build, agent support, feature settings and fallback behavior. Do not infer a stable cross-browser support matrix from a blog announcement. Keep ordinary UI and API paths usable if the experimental capability is unavailable.
Make intent and session scope visible#
A tool description can be poisoned, an output can carry instructions and an apparently harmless form can contain extra parameters. Confirm the exact action, destination and affected data through a trusted interface when the operation warrants approval. Validate on the backend even if the page displayed a confirmation. Same-origin execution and a signed-in session do not by themselves prove that the user intended this particular action.
Choose by the boundary you need#
Use an ordinary API when one controlled application needs a known service. Add backend MCP when compatible AI hosts need reusable discovery and tool contracts across services. Consider WebMCP only for a tested browser interaction where its maturity and session risks are acceptable. These choices can coexist around the same secured backend; none should bypass its authorization.