Tools MCP and External Integration
MCP Client — Stack
Mcp client › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
You are choosing a connection manager that other people's processes will be plugged into, and the qualities that matter are mostly about containment.
- Transport coverage. Whether both local subprocess and remote HTTP connections are supported, since the useful servers are split between the two and migrating a connection from one to the other should not be an application rewrite.
- Process supervision. For locally spawned servers: whether the library reaps children on host exit, bounds their memory, captures their error stream, and restarts them sanely. Libraries that merely spawn and forget leave the cleanup to you.
- Connection isolation. Whether one unreachable or misbehaving server degrades only its own offerings, or stalls enumeration and invocation for every other connection.
- Surface control. Whether the library exposes hooks to filter, rename, and pin the advertised set before it reaches the model, rather than handing it over wholesale.
- Change handling. What the library does when a server announces its offerings have changed, and whether the application can observe that event rather than discovering it through a failed call.
- Authorisation integration. Whether an interactive authorisation flow can be driven from the host's own user interface, and where the resulting tokens are kept between sessions.
- Observability. Whether each request carries a correlation identifier through to the server and back, so a slow turn can be attributed to a specific connection.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Official MCP SDKs (TypeScript, Python, Java, Kotlin, C#, Go, Rust and others) | Almost all first-party integration work; they track the specification most closely | Client-side ergonomics vary widely between language ports; process supervision is usually left to the embedding application |
| Desktop and IDE hosts acting as the client (assistant desktop apps, editor extensions) | Developer workstations, where the user is present to approve connections and authorisation flows | Connection configuration lives in a per-user file outside any fleet management; what each engineer has connected is unknown to the organisation |
| Agent frameworks with built-in MCP connectors | Wiring servers into an existing agent loop without writing transport code | The framework decides how server tools are named and how results are truncated, often without a way to override |
| Connecting through a gateway instead of directly | Fleets where connection policy, credentials, and auditing must be centralised | Adds an in-path dependency and hides upstream error detail unless the gateway is careful to preserve it |
| Hand-rolled JSON-RPC client over the transport | Constrained runtimes with no suitable SDK, or very narrow single-server integrations | Initialisation, capability negotiation, and notification handling are more detail than they look; expect to re-implement the specification's edge cases |
| Inspector and test harness tooling | Verifying what a server actually offers before trusting it in a product | A debugging surface, not a runtime; do not leave one reachable in a deployed environment |