TBW / AGENTIC AI / INTEGRATIONS

MCP and API Integration

Connect AI agents to enterprise tools and data through governed interfaces, explicit scopes and auditable authorization.

Discuss Your Project

Governed Interfaces to Enterprise Systems

MCP and conventional APIs expose capabilities to an AI client; neither interface grants permission by itself. Design the integration around the real actor, target resource, approved action and audit trail.

What MCP Is—and Is Not

Model Context Protocol (MCP) standardizes how compatible AI clients discover and invoke tools or access resources. It includes an optional authorization framework for protected HTTP servers, but using MCP does not by itself establish identity, grant permission to execute a tool, provide a complete security boundary or approve an action. The server and downstream services must enforce their own policies regardless of what the model requests.

MCP Versus Direct API

Direct API

Suitable for one known system with a stable integration contract and little need for cross-client tool discovery.

MCP

Useful when reusable tool discovery across multiple compatible AI clients and standardized schemas simplify operations.

Neither is universally superior. Evaluate support, maintenance, authorization path and the number of consumers before deciding.

Designing a Reliable Tool Server

Define narrow tool granularity and unambiguous names/descriptions. Validate typed parameter schemas at the boundary and again downstream. Specify idempotency for writes, structured error behavior, timeouts, version compatibility and rate limits. A convenient tool name must not disguise multiple consequential API operations.

Authorization and Token Handling

MCP authorization is optional at the protocol level. For protected HTTP MCP servers, follow the current OAuth-based authorization specification: discover the authorization server through protected-resource metadata; use PKCE for authorization-code flows; request only appropriate scopes; include the MCP server as the resource in authorization and token requests; and validate the token, its issuer and its intended audience at the MCP server. The HTTP authorization flow is not the prescription for local stdio servers, which normally receive credentials from their environment. Never pass an MCP client token through to a downstream API: use a separate credential issued for that API, with delegated access where appropriate. Prefer short-lived access tokens, guard against confused-deputy behavior and check the current MCP authorization specification before implementation.

Authorize the Actual Tool Action

A tool may invoke several API endpoints, and several tools may share one endpoint. Enforce user, tenant, action, resource, parameters and policy at execution time, not only during discovery. Verify delegated identity and resource ownership before write operations; an approval gate should identify the exact target and proposed change.

Third-Party MCP Server Risk

Review source and maintainers, allowlist approved servers, pin versions and assess dependencies as part of the software supply chain. Sandbox where appropriate, review updates before promotion and reassess permissions when tools or descriptions change. Do not grant blanket filesystem or network access merely to simplify setup.

Policy Gateway and Traceability

A gateway can mediate MCP/API tool requests, validate identity and scopes, apply tool allowlists and rate limits, require approvals and block prohibited targets. Record actor, tool, relevant parameters, target, policy decision, approval, result and timestamp as appropriate. Minimize sensitive values in telemetry while preserving enough context for investigation.

Integration and Abuse Testing

Test schema validation and invalid parameters, unauthorized tool calls, malformed responses and timeouts. Exercise privilege escalation, replay, cross-tenant access and version incompatibility. Verify that a denied call cannot be reissued through a broader tool or substituted endpoint, and that duplicate write requests remain safe.

Implementation and Deliverables

Inventory candidate systems, choose direct API or MCP per consumer, define tool contracts and scopes, review downstream authorization, test failure and abuse cases, then release with logging and update ownership. Deliver a tool catalog, integration architecture, scope model, authorization design, schema definitions, hardening checklist and test scenarios.

Frequently Asked Questions

Does MCP replace an API?

No. An MCP tool often calls an existing API; choose the interface that fits the consumers and enforce downstream authorization either way.

Does discovering a tool mean an agent may use it?

No. Discovery describes a capability, while execution still requires actor, tenant, action, resource and parameter checks.

Should a server forward a client token to downstream systems?

No. A protected HTTP MCP server must validate the client token for itself and must not pass it to a downstream API. Obtain a separate token issued for that API through an appropriate delegated or service authorization flow.

How should third-party servers be introduced?

Review code and dependencies, pin an approved version, limit permissions, sandbox where appropriate and test upgrades before promotion.

What should be recorded for a tool call?

Capture actor, tool, target, policy decision, approval and result with a timestamp; omit unnecessary sensitive parameter values.

Map Your Tool Boundaries

Identify the systems, users and actions an agent needs. We can turn them into narrow tool contracts and an authorization test plan.