No, because HTTP already is. You can't have every MCP added. Every harness has a search tool, so just fetch data as needed. MCP isn't for search, it's for interacting. Sometimes that's search but mostly not.
For web services, what is the point of MCP or even a skill when modern agents can just find API docs on their own and use it?
I think in this day and age agents no longer need official 3P integrations, they can just use whatever API is already available (and in some cases even the UI).
We run AI inside VMs that are only given tightly controlled access to our internal servers. Routing calls through MCPs that only allow specific access lets us keep things secure for servers that don't allow that fine control through the API.
I think of the mcp as another UI. You have your human UI and your robot UI and the API serves both. Makes sense when the actions you want the agent to make are not exactly 1:1 mapping to an endpoint.
But yeah of course an agent can usually figure out how to use your API, can just take more time and tokens.
Figuring out the quirks of each api is a waste in tokens but I agree once you decide on a specific integration it makes sense to use an api.
Still, mcp means you don’t need to figure out the quirks.
Net, I think mcp is extremely good for resource constrained circumstances. I add mcp servers to many of my own applications and it’s an automatic productivity boost.
As a bonus, when I want to automate the integration I literally make my automations use mcp.
The thing that mostly makes MCP more token efficient is that its methods usually have good documentation/examples and smaller surface area, so it’s easier for the agent to navigate. But this can (and should) also be applied to the API itself...
The other thing is discoverability, but I’m not sure a simple web search would be significantly less efficient.
I just don't see why I would use any other API, including for programmatic access, rather than one optimized for agents. Do you have an example of where a custom API is better?
My custom MCP server for example handles long running tasks by returning a handle that can be cancelled/queried. This is done in a generic way that all agents can deal with and needed no special instructions.
> Three things still have to be built, server by server
> citation
Nope, as long as the MCP server exposes enough metadata to be cited (mostly trivial), citation is a job of the client/LLM.
> trust
Also just a function of the client. The server can't aid here at all as it's inherently untrustworthy in the system.
> measurement
Maybe. Though it's debatable how much measurement _each_ server needs, and whether that actually gives meaningful insight to optimize. This might as well be measured outside of the servers, in the client/a centralized logging system that also sees surrounding context.
This is just an ad for contextetech. Search engines build their own index, which is hard. Decentralized search engines like Searx have middling results, and it's a project running for over a decade. "Smart" is subjective, and not something I'd trust an LLM to determine.
No, because HTTP already is. You can't have every MCP added. Every harness has a search tool, so just fetch data as needed. MCP isn't for search, it's for interacting. Sometimes that's search but mostly not.
Pi doesn't have a search tool. I think of web search as an interaction with a search engine. So it makes perfect sense to use MCP.
(although i don't, i have a CLI)
For web services, what is the point of MCP or even a skill when modern agents can just find API docs on their own and use it?
I think in this day and age agents no longer need official 3P integrations, they can just use whatever API is already available (and in some cases even the UI).
We run AI inside VMs that are only given tightly controlled access to our internal servers. Routing calls through MCPs that only allow specific access lets us keep things secure for servers that don't allow that fine control through the API.
I think of the mcp as another UI. You have your human UI and your robot UI and the API serves both. Makes sense when the actions you want the agent to make are not exactly 1:1 mapping to an endpoint.
But yeah of course an agent can usually figure out how to use your API, can just take more time and tokens.
Figuring out the quirks of each api is a waste in tokens but I agree once you decide on a specific integration it makes sense to use an api.
Still, mcp means you don’t need to figure out the quirks.
Net, I think mcp is extremely good for resource constrained circumstances. I add mcp servers to many of my own applications and it’s an automatic productivity boost.
As a bonus, when I want to automate the integration I literally make my automations use mcp.
The thing that mostly makes MCP more token efficient is that its methods usually have good documentation/examples and smaller surface area, so it’s easier for the agent to navigate. But this can (and should) also be applied to the API itself...
The other thing is discoverability, but I’m not sure a simple web search would be significantly less efficient.
I just don't see why I would use any other API, including for programmatic access, rather than one optimized for agents. Do you have an example of where a custom API is better?
My custom MCP server for example handles long running tasks by returning a handle that can be cancelled/queried. This is done in a generic way that all agents can deal with and needed no special instructions.
(Excluding for performance reasons here...)
[flagged]
> Three things still have to be built, server by server
> citation
Nope, as long as the MCP server exposes enough metadata to be cited (mostly trivial), citation is a job of the client/LLM.
> trust
Also just a function of the client. The server can't aid here at all as it's inherently untrustworthy in the system.
> measurement
Maybe. Though it's debatable how much measurement _each_ server needs, and whether that actually gives meaningful insight to optimize. This might as well be measured outside of the servers, in the client/a centralized logging system that also sees surrounding context.
This is just an ad for contextetech. Search engines build their own index, which is hard. Decentralized search engines like Searx have middling results, and it's a project running for over a decade. "Smart" is subjective, and not something I'd trust an LLM to determine.
As always, the answer to an article whose title is a yes/no question: no
No.. MCP is for actions
Decentralised search sounds weird to me. Searching always needs a centralised collection.
Why?
I don’t need a centralized collection to search my own computer. Why couldn’t that extend to my own little corner of the web?
[flagged]
No
no
[flagged]