Composite Service
also known as Capability Aggregation, Workflow Tool, Consolidated MCP Tool, Higher-Level MCP Tool
Expose one MCP tool that orchestrates several underlying API calls into a single higher-level operation, so the agent invokes a task-level capability instead of chaining many low-level endpoints.
This pattern helps complete certain larger patterns —
- specialisesModel Context Protocol★★— Standardise how agents discover and call tools so that a tool written once is usable by any conformant agent.
Context
A team is building an MCP server over a set of fine-grained APIs, or over several different services. Agents need to accomplish a multi-step task — create a project, set its variables, then deploy it — that maps to several endpoint calls in a fixed order.
Problem
A one-to-one endpoint-to-tool mapping pushes orchestration onto the model: it must know the right call order, thread each output into the next input, and handle partial failures across calls. This bloats the tool list, spends tokens on intermediate reasoning, and makes brittle multi-call sequences that fail in hard-to-debug ways. The team needs the agent to express intent at the level of the task, not the level of individual HTTP calls.
Forces
- Fewer, higher-level tools are easier for the model to choose among, but each hides more logic that must be maintained on the server.
- Orchestration in the server is written once and testable; orchestration in the model is re-derived on every call.
- Aggregating endpoints couples them — a change in one underlying API can ripple into the composite tool.
- A composite tool must define its own error semantics for partial failure across the calls it bundles.
- Too much aggregation produces opaque mega-tools that are hard to debug and hard to reuse.
Example
A platform exposes fine-grained endpoints for creating a project, setting environment variables, and starting a deployment. Instead of giving the agent three separate tools to sequence, the team ships one MCP tool, deploy_project, whose handler runs the three calls in order and returns a single result. The agent asks to deploy a project in one call, and if the environment-variable step fails the tool returns a typed error naming that step rather than leaving a half-created project behind.
Diagram
Solution
Therefore:
Identify recurring multi-call workflows and expose each as one MCP tool whose handler performs the calls, threads the intermediate results, and returns a single typed result. Keep each composite cohesive — one business capability per tool, such as a deploy_project that internally creates the project, sets environment variables, and triggers the deployment — and keep the underlying integrations modular so one API's change does not cascade. Define explicit partial-failure semantics so the tool reports which underlying call failed. This is the capability-aggregation step beyond direct-api-wrapper; when the orchestration is itself better expressed as code the agent writes, see mcp-as-code-api, and when many composites need organising under one server, hierarchical-tool-selection helps the model navigate them.
What this pattern forbids. Orchestration of the bundled calls must live in the server tool, not in the model; the agent may invoke the composite capability but must not be required to sequence the underlying calls itself.
And the patterns that stand alongside it, or against it —
- alternative-toDirect API Wrapper★— Expose an existing API as MCP tools by mapping each operation one-to-one to a tool, so a stable API becomes agent-callable with minimal wrapper logic.
- complementsMCP-as-Code-API★— Materialize MCP servers as a directory of typed code wrappers so the agent writes code that imports them and large tool outputs flow between calls inside the sandbox without ever entering the model's context window.
- complementsHierarchical Tool Selection★— Organise tools into a tree of categories so the agent first picks a branch and then a specific tool within it.
Neighbourhood
Click any neighbour to follow the language. Scroll to zoom, drag to pan.