Build an MCP Server in Python That Wraps a CLI Tool

Most useful MCP servers are a thin layer over something that already exists — a linter, a scanner, a build tool, an API client. The MCP part is small. What takes the time is everything around it.

This is the shape that worked for a server wrapping five analyzers across five languages, including the four times it got the same thing wrong.

The lesson that repeated once per backend: every tool you wrap will flood you with findings you did not promise, and you will not know which ones until you run it on somebody else's code.

ESLint express/lib: 31 of 33 findings were one default-on rule → 2 genuine SpotBugs spring-petclinic: 5 irrelevant findings → 0, fixture keeps its 4 Roslyn eShopOnWeb: a bogus xUnit finding → 0, fixture keeps CA5351 detekt style and complexity rules → --disable-default-rulesets

Also covered

· A minimum viable server, and the SDK rename that breaks imports · The docstring as the activation surface — a server whose docstrings said "Kotlin/JVM" while it routed five languages had four of them unreachable, working perfectly, called by nobody · Layers that stay cheap to change: ports as Protocols, one composition root · Subprocess rules — always a timeout, never check=True (analysis tools exit non-zero when they find something), argv as a list, controlled working directory, isolated environment · Routing, so a partial install still works · Meeting the user where they point, instead of demanding a path only the tool's author knows · Capping responses honestly; errors that name the command that fixes them · Packaging: ship setup inside the package, then prove the install from an empty environment · Supply chain — a tool that runs other tools pins its actions to commit SHAs · Testing in layers, then verifying through the client

Working Python throughout, plus references on subprocess handling with the traps that only appear on real projects, tool contracts with before/after docstring rewrites, and architecture with the full composition root.