One app needs a single internal API, and nobody else will use it. What is the simplest integration?
Why A is the answer
A direct tool defined in that app
MCP pays off when many hosts share an integration. For one app and one API, a direct tool has less to run.
In detail
- MCP pays off when many hosts share an integration.
- For one app and one API, a direct tool has less to run.
- Move to MCP if other hosts need it later.
Use case
An illustrative scenario, not a real incident.
One app calls one internal API, and no other team will use it. A direct tool takes an afternoon. An MCP server would need its own deployment and owner.
See it in different ways
flowchart TD
A{"Used by one app?"} -->|Yes| B["Direct tool in that app"]
A -->|No| C{"Many hosts need the same system?"}
C -->|Yes| D["MCP server owned by that team"]
C -->|"Another agent owns the task"| E["Agent to agent"]stateDiagram-v2 [*] --> HowManyApps HowManyApps --> DirectTool: one app HowManyApps --> McpServer: many apps McpServer --> Stdio: local process McpServer --> StreamableHttp: remote, with OAuth
flowchart TD
Q{"How many apps need it?"}
Q -->|"One"| A0["Direct tool"]
Q -->|"Several"| A1["MCP server"]Key point: MCP pays off when integrations are shared.
Why the other options are wrong
- B. A nightly export of the API data into the app's knowledge base
- A nightly export goes stale.
- C. A shared MCP server with its own deployment, owner and support process
- A shared server adds a deployment and an owner with no other users.
- D. An agent-to-agent setup with a dedicated agent in front of the API
- A dedicated agent adds a layer for a simple call.