Composite Service

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.

Solution

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.

When to use

• Common tasks span several endpoints in a fixed order.
• A one-to-one tool surface is too large or too chatty for reliable tool selection.
• Orchestration logic is stable enough to own on the server and reuse across tasks.
• Partial-failure handling across calls should be consistent rather than re-derived by the model.