[dead]
Ask HN: Why do we need MCP?
21–29 of 29 posts
Re: Ask HN: Why do we need MCP?
#22MCP and APIs are extremely similar, but MCP provides a common protocol that everyone can follow, so every agent can use the same protocol regardless of whether the backend uses REST, OpenAPI, or GraphQL. It will just work, and agents know how to crawl other MCPs; therefore, providing an MCP tool makes it much easier for an agent to develop a usage pattern.
Re: Ask HN: Why do we need MCP?
#23I use CLI tools for Git, Atlassian (ACLI), and Metabase, plus custom SigNoz shell scripts to drive API calls instead of an MCP server. This setup works very well at the moment for me.
I run a few agents side by side and I've been going back and forth on whether to bother with MCP servers at all. I'm not clear on what each of those is doing in your loop though. Could you go into a bit more detail?
Re: Ask HN: Why do we need MCP?
#24[flagged]
Re: Ask HN: Why do we need MCP?
#25[flagged]
Re: Ask HN: Why do we need MCP?
#26MCP and APIs are extremely similar, but MCP provides a common protocol that everyone can follow, so every agent can use the same protocol regardless of whether the backend uses REST, OpenAPI, or GraphQL. It will just work, and agents know how to crawl other MCPs; therefore, providing an MCP tool makes it much easier for an agent to develop a usage pattern.
To add to this, MCPs usually focus on capabilities. This is especially useful in multi-hop situations.
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.
Re: Ask HN: Why do we need MCP?
#27MCP and APIs are extremely similar, but MCP provides a common protocol that everyone can follow, so every agent can use the same protocol regardless of whether the backend uses REST, OpenAPI, or GraphQL. It will just work, and agents know how to crawl other MCPs; therefore, providing an MCP tool makes it much easier for an agent to develop a usage pattern.
To add to this, MCPs usually focus on capabilities. This is especially useful in multi-hop situations. 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 r…
My biggest problem is that msps can't be chained together and that the response schema is not know models are very good at filtering with jq to get only the relevant fields
Re: Ask HN: Why do we need MCP?
#28[flagged]
Re: Ask HN: Why do we need MCP?
#29I use CLI tools for Git, Atlassian (ACLI), and Metabase, plus custom SigNoz shell scripts to drive API calls instead of an MCP server. This setup works very well at the moment for me.
I run a few agents side by side and I've been going back and forth on whether to bother with MCP servers at all. I'm not clear on what each of those is doing in your loop though. Could you go into a bit more detail?
I have a simple workflow consisting of:
- acli to pull ticket details from Jira.
- 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.