Tool Calling and MCP: How Agents Connect to Enterprise Systems

An agent is only as useful as the systems it can touch. Tool calling is the model-level mechanism: you describe functions in JSON Schema, the model emits structured calls, your application executes them. MCP is the integration-level standard: it packages those tools so any compliant agent can consume them. The enterprise decision is to invest in both layers deliberately — schemas and descriptions as the quality lever, the protocol as the portability lever.

1. Two layers, two different problems

Most confusion about agent integration comes from collapsing two distinct layers into one. Tool calling is a model capability exposed through each vendor's API; MCP is an interoperability protocol for distributing tools to any model or framework. You need the first to make an agent act at all. You need the second only when integrations must be shared, reused, or survive a stack change — which, in an enterprise, is almost always.

2. The loop: request, tool_use, tool_result

The mechanics are the same across vendors, with different vocabulary. On the Claude API you pass tool definitions — name, description, `input_schema` — alongside the conversation. When the model decides to act, it stops with `stop_reason: "tool_use"` and returns one or more `tool_use` blocks naming the tool and its arguments. Your code executes the call and sends the output back in a `tool_result` block; the model then continues with the answer or the next call.^[1] OpenAI's shape is equivalent: you provide the function's name, a description, and a "JSON schema defining the function's input arguments," and the model returns a parsed tool call for your code to execute.^[2]

Three loop behaviors matter operationally. Parallel calls: models can emit several tool calls in one turn; both vendors let you disable this (`disable_parallel_tool_use` on the Claude API, `parallel_tool_calls: false` on OpenAI's) when tools have ordering dependencies or side effects.^[1][2] Schema enforcement: both vendors now offer a strict mode — OpenAI states that "Setting `strict` to `true` will ensure function calls reliably adhere to the function schema, instead of being best effort," and Anthropic's equivalent guarantees calls match your schema exactly — which converts a whole class of malformed-argument retries into a non-problem.^[2][1] Forcing: `tool_choice` lets you require a tool call rather than trusting prompt steering, which is the right control when a workflow step must not be answered from model memory.^[1]

3. Descriptions are the quality lever

The single most consequential sentence in the vendor documentation is easy to skim past: "Claude determines when to call a tool based on the user's request and the tool's description."^[1] The description is not documentation for humans — it is the routing logic. A vague description produces wrong-tool selection and missed calls no amount of orchestration code will fix. This is why tool definitions deserve the same review discipline as public API contracts: they are prompts with a schema attached.

Anthropic's engineering guidance on writing tools for agents makes the design rules concrete. Parameters should be self-describing — "Input parameters should be unambiguously named: instead of a parameter named `user`, try a parameter named `user_id`" — and namespacing (grouping related tools under common prefixes) helps delineate boundaries when the roster grows.^[5] The same post warns against proliferation: "Too many tools or overlapping tools can also distract agents from pursuing efficient strategies."^[5] The practical consequence: consolidate overlapping endpoints into fewer, task-shaped tools rather than exposing every internal API method as its own function.

Quality is measurable, not aesthetic. Anthropic recommends building evaluations for tools and instrumenting them: "We recommend collecting other metrics like the total runtime of individual tool calls and tasks, the total number of tool calls, the total token consumption, and tool errors."^[5] Treat those four series as the KPIs of your tool catalog. A tool whose call count is high but whose downstream task success is low is a description problem; a tool that burns tokens returning verbose payloads is a response-format problem. Both are fixable in the definition, not the model.

4. Error handling: the result is a prompt

The error path is where agent integrations diverge from classic API integrations. In a classic integration, an error message is for a developer reading logs. In an agent loop, the error text goes back into the model's context and steers the retry. Anthropic's guidance is explicit: "If a tool call raises an error, you can prompt-engineer your error responses to clearly communicate specific and actionable improvements, rather than opaque error codes or tracebacks."^[5] A `403` teaches the model nothing; "you lack the `finance-read` scope; try `get_public_summary` instead" redirects it in one turn.

Beyond message quality, apply the standard reliability discipline: separate retryable failures (timeouts, rate limits) from terminal ones (validation, authorization) in your tool-result format so the loop retries only what can succeed; cap retries and wrap slow backends in timeouts so one hung tool doesn't stall a multi-step run; and log every call with its arguments and outcome, because tool traces are the primary debugging artifact for agents. Where the model itself is the failure source — guessing a missing required parameter instead of asking — vendor behavior varies by model tier, so test the underspecified-request case explicitly rather than assuming the model will ask.^[1]

5. What MCP actually standardizes

Before MCP, every agent framework had its own tool plug-in format, so an integration built for one was a rewrite for the next — as Anthropic's announcement put it, "Every new data source requires its own custom implementation, making truly connected systems difficult to scale."^[6] MCP, released in November 2024, is "an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools."^[6] The specification defines three roles — hosts (the LLM application), clients (the connector inside the host), and servers (the services exposing capabilities) — communicating over JSON-RPC 2.0 with capability negotiation.^[4]

The strategic property is who holds the specification: it is MIT-licensed and maintained in a public repository containing the spec, protocol schema, and official documentation — not a proprietary SDK surface.^[3] And the ecosystem has converged: every major open-source agent framework covered in our framework comparison now consumes MCP servers through first-party support, which makes the protocol — not the framework — the durable integration asset. Build an internal system integration as an MCP server, and a later framework migration becomes re-wiring instead of rewriting.

6. From OpenAPI spec to agent tool

Most enterprises already describe their internal APIs in OpenAPI, and the major clouds treat that spec as a direct on-ramp to agent tooling. Amazon Bedrock agents define action groups by ingesting "an OpenAPI schema in JSON or YAML format," and the agent "uses the schema to determine the API operation that it needs to invoke and the parameters that are required to make the API request."^[7] Microsoft's agent service takes the same route: its OpenAPI tool "improves your function calling experience by providing standardized, automated, and scalable API integrations," connecting agents to external APIs via an OpenAPI 3.0 specification.^[8] The pattern converts an existing API catalog into a tool catalog with little bespoke code.

But the vendor docs quietly confirm the descriptions-first lesson. Bedrock instructs you to use each operation's `description` field "to inform the agent when to call this API operation and what the operation does," and notes its agents support only a subset of OpenAPI 3.0 — the `enum` field, for instance, is unsupported, with allowed values described in prose instead.^[7] Microsoft requires a well-formed, descriptive `operationId` "to help models efficiently decide which function to use."^[8] In other words: auto-generation gets you syntax, not quality. An API designed for developers — fine-grained CRUD endpoints, terse descriptions — is rarely the right shape for an agent, which is exactly the overlapping-tools trap the model vendors warn about.^[5] Generate from OpenAPI, then curate: merge, rename, and rewrite descriptions for the agent's decision, not the developer's reference.

7. Auth and least privilege: decided at the tool boundary

The tool layer is also where an agent's identity and blast radius are set. The cloud implementations show the accepted range: Microsoft's OpenAPI tool supports three authentication types — anonymous, API key, and managed identity — with managed identity (Microsoft Entra ID) recommended so credentials never live in the spec or prompt.^[8] Bedrock adds a human gate at the schema level: an `x-requireConfirmation` flag that requests user confirmation before an action fires, which AWS notes "may safeguard your application from taking actions due to malicious prompt injections."^[7] Scope every tool's credential to the minimum the described operation needs, and require confirmation on anything that writes. The full control framework — agent identity, approval tiers, audit — is covered in our agent governance guide; the point here is that these controls attach to tool definitions, so they must be designed with them, not bolted on after.

8. Honest objections

"MCP is another layer we don't need." Often true. A single agent with six internal tools gains nothing from a protocol hop; direct function calling is simpler, faster to debug, and fully supported. MCP earns its layer when integrations are shared across teams, frameworks, or vendors — the same argument as an internal API gateway. If you are sure you will only ever have one agent on one framework, skip it; few enterprises can honestly say that.

"The protocol is young and still moving." Also fair — the specification is versioned by date and continues to evolve, so pin the revision you build against and wrap client access behind a thin internal interface.^[4] The mitigations are ordinary dependency hygiene, and the MIT-licensed, publicly governed spec means churn risk is visible, not contractual.^[3]

"Every MCP server is new attack surface." Correct, and the strongest objection. A server that aggregates credentials and accepts instructions influenced by model output concentrates exactly the risks prompt-injection attacks exploit — which is why the confirmation gates and least-privilege scoping above are prerequisites, not enhancements, and why third-party MCP servers deserve the same vendor review as any software supply-chain dependency. The governance guide's controls apply in full here.

9. The read

For a CIO, CTO, or platform lead, this reduces to three decisions. Treat tool definitions as API products: owned, versioned, reviewed for description quality, and measured on runtime, call counts, token consumption, and error rates — the metrics the model vendors themselves recommend tracking.^[5] Keep the roster small and task-shaped: consolidation is both an accuracy lever and a per-request cost lever, with vendor guidance pointing the same direction.^[2][5] Standardize the integration layer on MCP for anything used by more than one agent or team, so the connector outlives the framework and model choices around it.^[6] Teams that do this turn integrations into compounding assets; teams that don't rebuild the same connectors with every stack revision.