Ask HN: Why do we need MCP?
Why not just publish your API docs and let the client's bot chain together what calls need to be made.
You could even repurpose the MCP so you only ever produce the API documentation as EVERY response. No LLM necessary.
You could even repurpose the MCP so you only ever produce the API documentation as EVERY response. No LLM necessary.
23 comments
[ 0.21 ms ] story [ 24.4 ms ] threadBut yeah, a lot of it (including tools) maps well to HTTP semantics. In fact, at work we implement our features as HTTP APIs, and we’ve built a framework that exposes them as MCP servers.
- gh for GitHub remote pushes, PR generation, and GitHub Actions tracking.
- A SigNoz shell script to monitor changes in the dev/stage/prod(logs, metrics, traces) environments.
- The Metabase CLI (mb) to verify data in the database. awscli and kubectl to fetch read-only Kubernetes data for the agent.
I also have the skills to understand how this workflow operates and how to use each of these tools.
For example: I give the agent the ticket URL or ID, the jira-ticket-pull skill gets invoked, and the agent now knows how to use acli to pull tickets. The agent goes through the ticket details and uses its skills to grill me on the description until the agent and I reach a common understanding of what to do. Then, it uses the TDD skill for implementation. At the end, there is a commit-and-push skill to enforce commit conventions, push the code, and create a PR using the gh CLI.
If the ticket is about monitoring or bugs, the agent uses SigNoz scripts instead to get more context. If it needs data from the database to ground itself, it uses mb to get it.
What it does well though is to keep things relatively simple. It is also good for things that takes time to return.
I find it competitive also for non LLM usages. I have done some PoCs with MCP instead of REST/OpenAPI, or GraphQL, or Protobuf and I liked MCP.
As an illustration, lets say I ask the agent to “Read the issue Bob posted today from Linear (issue tracker), pull relevant logs from DataDog (log tool) and suggest a fix”
In the MCP world, my agent doesn’t have to spend tokens / time understanding APIs or the protocol (as the parent comment suggests). Instead, it relies on the tool provider for the best way to “read the issue” or “pull logs”.
Same thing, in the API world, would usually involve multiple API hits (and possibly using the wrong APIs or params for them), interpreting the results and hitting few more APIs again.