6 ms·

I still struggle to see how a MCP endpoint is easier for agents to work with compared with a REST endpoint and a skills.md file.

by cube00 2mo ago

peterlk 2mo ago
Yep. I’ve found that having an endpoint that serves a well, documented openapi.yaml is very effective for agentic usage. The biggest difference is that you can break down a REST API into RPC-like chunks and save on some tokens if you break up the tools well. But pragmatically, I think saying “tell your agent to hit /api/v3/openapi.yaml” is quite useful
- ulrikrasmussen 2mo ago
  We did a prototype to integrate an agent into our application and basically just gave it a tool to discover the OpenAPI spec and call endpoints. It worked surprisingly well! One caveat was that some responses were too big and would poison the context, but then I gave the agent a GraalJS engine and allowed it to save responses and post-process them using JS. For the little amount of work required this gives the agent a lot of power without having to give it full CLI and without having to create bespoke tools.
pianopatrick 2mo ago
or a CLI
- pjmlp 2mo ago
  CLI don't work in cloud environments like MACH architecture. Plus why spawning processes all the time.
  - fallat 2mo ago
    This is the strongest argument I've seen against CLI for LLMs. Thank you.
  - deleted 2mo ago
    [deleted]
preommr 2mo ago
Because it's a separate marketing term. Instead of the CEO mandating that the API server has to be agent compatible (where who knows what that means), they can just say "our product has an MCP". On a technical level, who knows what it actually is (is it actually the new stateless version, does it have all the endpoints, is the regular API more feature-rich, do I need those features for my workflow?, etc.). But at a surface-level, the intention is clearer, and lets other gears (like sales and marketing) keep spinning without getting bogged down in technical details.
- anon84873628 2mo ago
  All that, yes. And at a technical level, it is much easier to have a single spec to follow. When a customer complains that their client isn't working, I can point at how they aren't following OAuth discovery properly or something.
davidrichards 2mo ago
At my company Parallel AI, I just built an extremely well documented openapi spec and then MCP builds from that. Complete alignment with UI/API/MCP so there is no extra work. Are others doing this? It seemed obvious to me, but I don't hear others saying it.
- pjmlp 2mo ago
  Yes, for .NET and Java backend stuff, it is basically extending what is already there. On low code/no code tools, you get additional metadata for webhooks.
- techscruggs 2mo ago
  The challenge with this is that it often causes a proliferation of MCP tools which bloats context, which is one of the reasons that MCP was created.
  - mickdarling 2mo ago
    I created MCP AQL, which is an extension to the MCP spec, specifically to reduce the bloat for MCP tools. It only has five CRUDE endpoint: Create, Read, Update, Delete, and Execute using a GraphQL-like structure for tool calling of the operations within the endpoints. It's very efficient, and robust. there's all kinds of exemplar tools and components to make adapters for any MCP server. You don't even need to rewrite your own MCP server. Just create an adapter for it. All open source at MCPAQL.com
  - davidrichards 2mo ago
    Oh sorry I didn't explain that we are not dumping the entire endpoint list to the MCP. We have 400+ endpoints so this would be terrible. We tag each endpoint by category in the OpenAPI spec and require the MCP to request actions by tag and optional query term. At most we return 10 endpoints at a time and the LLM can request more using pagination. These tags also create your categories in API doc websites like swagger/mintlify so its a win win. OpenAPI spec is the single source of truth.
  - xienze 2mo ago
pjmlp 2mo ago
Me too, it is just another RPC endpoint, heck all of this kind of stuff could even be done with Sun RPC.
MikhailTal 2mo ago
Not all agents have access to a sandbox/cli/code execution environment to run arbitrary api calls etc. MCP helps by essentially having another tool call without needing a sandbox. If you do have a sandbox, then might as well do codemode if you insist on mcp https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/
- agentdev001 2mo ago
  Devil's advocate will say "Well, the agent would need an MCP client to use MCP-served resources... if you can give it that, why not give it an HTTP client?"
notatoad 2mo ago
it's not easier for agents to work with. it's easier for organizations to work with. for agents, they're essentially the same thing - remote endpoints, and instructions on how to call those endpoints. what MCP brings is centralized updating and distribution of the instructions, and a promise that the skill and the REST api won't be out of sync with each other. the one thing that skill.md+REST doesn't solve is how you get that skill.md to somebody else's computer, and how you ship an update to somebody else's computer once they've got a copy of the skill. if that's a problem you need to solve, you can either start inventing skill.md distribution protocols, or you can just use MCP.
- boredumb 2mo ago
  How is distributing a markdown file the bottleneck?
  - tass 2mo ago
    Because it’s something else that’s non-standard between providers.
  - stillpointlab 2mo ago
    It is the automatic distribution and automatic update. The questions isn't "how does one download a text file to another persons computer?". It is "how does someone with a skill.md file on their computer discover that a new version of that file is available". This isn't a "bottleneck" but rather a capability (or lack thereof). As you add more and more capabilities, especially ones relevant to enterprise situations like authentication, authorization, governance, etc. then MCP starts to pay off. If you do not need those capabilities, then you do not need MCP. And then you shouldn't use it. But if you do need those capabilities then it might be worth using MCP rather than inventing your own way to do them.
    - boredumb 2mo ago
      I see. In my head it would be something like the agents harness having a list of services it interacts with, reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.
wolttam 2mo ago
The model has zero awareness of MCP, it’s the harness’ job to talk to the MCP server and simply present the model with the tools just like any other tool. The only giveaway to the model about where the tools come from is the ‘mcp__’ prefix in the name
mikeocool 2mo ago
Companies got to release an MCP server for their product and tell their investors they were pivoting to be AI native.
ihuman 2mo ago
I don't want to expose my API key to Claude. An stdio MCP server wrapping an API lets me hide it
- mathisfun123 2mo ago
  wtf is the difference when 1) you put a key in front of the mcp 2) you mcp a whole bunch of privileged access. it's like saying "i don't want to give Claude access to my file system but i'm fine letting it run bash" ......
  - intrasight 2mo ago
    The difference is that the LLM never sees your keys/secrets. My understanding is that can make a big difference.
    - JV00 2mo ago
      Does mcp guarantee that, per se?
      - anon84873628 2mo ago
        Not if you assume the straw man like grandparent, but yes if you use it thoughtfully.
c0rruptbytes 2mo ago
easier to gate MCP tools? you can allow/deny tools very easily
ffsm8 2mo ago
Mcp predates skills - and has a more granular permission model then skills + bash commands.
big-chungus4 2mo ago
MCP can also handle authorization, since you don't want to put your password to skills.md and send it to China
lubujackson 2mo ago
I work on an MCP server and I agree. There is no need to make MCP servers the gateway for agentic or programmatic integration - that's exactly what API servers handle out of the box. The value of MCP servers is fine-toothed access on a tool-by-tool basis and leaving output digestion to the LLM. LLMs do GREAT utilizing well-defined tools to accomplish tasks. Look at Datadog's MCP, instead of figuring out a multitude of filter and navigation options your LLM can immediately navigate to what you want and extract the precise data you need. Tool instructions with defined I/O structures let LLMs fly. But for a nightly cron job pulling down stats or something like that? Why the hell do you want to route through a protocol built for in-person consumption? This is such a pointless overreach for the protocol. What would have been better is blessing a standardized pattern for exporting any MCP tool definition into a well-structured API endpoint. Then everything related to API endpoints like doc generation, comes along for free. Instead we get this kitchen sink protocol that is going headlong toward polyfill hell, since no two IDEs support the same protocol features like structured content, local state, elicitations, etc., even from the same provider - Claude Code/Desktop/web all handle MCP connections differently. It's a shitshow. Almost every major MCP service uses the same baseline default features (plain context) rather than build around partially-supported features. Why add more and more specs on the pile when adoption is so far behind?
ketozhang 2mo ago
It's determinism, flexibility, and language. To the LLM, the a skill input is deterministic, inflexible, and outputs natural language. A REST API (not the REST itself, but modern output being JSON primitives) outputs are deterministic, flexible, but doesn't output natural language. An MCP as an input is deterministic, flexible, outputs natural language. Then we ask the same question on whether the LLM gets back a response that is deterministic. Skills output are not deterministic, it requires LLM to generate tokens to take action. It may or may not take the specific actions instructed by the skill. So, Skills + REST API = MCP only if you can deterministically call on the REST API.
- ketozhang 2mo ago
  In other words: * /skill may or may not call on the instructed action * /tool (or @tool) will guarantee the action is taken This is overgeneralizing and we need to talk about harness-specific features like hooks (which adds a deterministic action to skill usage).
adrian_m 1mo ago
Off the top of my head: * Your agent can easily be configured to always allow certain MCP tools. This is very hard to do for only certain REST endpoints. This is even more relevant in enterprise settings, where permission configs might be done centrally. * If the provider wants to change how an endpoint works, it's a breaking change for a REST API. Not with MCP, as the "endpoints" (tools) are dynamic and tell the agent how to use them.
- mendapi 1mo ago
  [flagged]
hyveops 1mo ago
[flagged]

I still struggle to see how a MCP endpoint is easier for agents to work with compared with a REST endpoint and a skills.md file.

by cube00 2mo ago

I still struggle to see how a MCP endpoint is easier for agents to work with compared with a REST endpoint and a skills.md file.

peterlk 2mo ago

Yep. I’ve found that having an endpoint that serves a well, documented openapi.yaml is very effective for agentic usage. The biggest difference is that you can break down a REST API into RPC-like chunks and save on some tokens if you break up the tools well. But pragmatically, I think saying “tell your agent to hit /api/v3/openapi.yaml” is quite useful

ulrikrasmussen 2mo ago
We did a prototype to integrate an agent into our application and basically just gave it a tool to discover the OpenAPI spec and call endpoints. It worked surprisingly well! One caveat was that some responses were too big and would poison the context, but then I gave the agent a GraalJS engine and allowed it to save responses and post-process them using JS. For the little amount of work required this gives the agent a lot of power without having to give it full CLI and without having to create bespoke tools.

pianopatrick 2mo ago

or a CLI

pjmlp 2mo ago
CLI don't work in cloud environments like MACH architecture. Plus why spawning processes all the time.
- fallat 2mo ago
  This is the strongest argument I've seen against CLI for LLMs. Thank you.
- deleted 2mo ago
  [deleted]

preommr 2mo ago

Because it's a separate marketing term. Instead of the CEO mandating that the API server has to be agent compatible (where who knows what that means), they can just say "our product has an MCP". On a technical level, who knows what it actually is (is it actually the new stateless version, does it have all the endpoints, is the regular API more feature-rich, do I need those features for my workflow?, etc.). But at a surface-level, the intention is clearer, and lets other gears (like sales and marketing) keep spinning without getting bogged down in technical details.

anon84873628 2mo ago
All that, yes. And at a technical level, it is much easier to have a single spec to follow. When a customer complains that their client isn't working, I can point at how they aren't following OAuth discovery properly or something.

davidrichards 2mo ago

At my company Parallel AI, I just built an extremely well documented openapi spec and then MCP builds from that. Complete alignment with UI/API/MCP so there is no extra work. Are others doing this? It seemed obvious to me, but I don't hear others saying it.

pjmlp 2mo ago
Yes, for .NET and Java backend stuff, it is basically extending what is already there. On low code/no code tools, you get additional metadata for webhooks.
techscruggs 2mo ago
The challenge with this is that it often causes a proliferation of MCP tools which bloats context, which is one of the reasons that MCP was created.
- mickdarling 2mo ago
  I created MCP AQL, which is an extension to the MCP spec, specifically to reduce the bloat for MCP tools. It only has five CRUDE endpoint: Create, Read, Update, Delete, and Execute using a GraphQL-like structure for tool calling of the operations within the endpoints. It's very efficient, and robust. there's all kinds of exemplar tools and components to make adapters for any MCP server. You don't even need to rewrite your own MCP server. Just create an adapter for it. All open source at MCPAQL.com
- davidrichards 2mo ago
  Oh sorry I didn't explain that we are not dumping the entire endpoint list to the MCP. We have 400+ endpoints so this would be terrible. We tag each endpoint by category in the OpenAPI spec and require the MCP to request actions by tag and optional query term. At most we return 10 endpoints at a time and the LLM can request more using pagination. These tags also create your categories in API doc websites like swagger/mintlify so its a win win. OpenAPI spec is the single source of truth.
- xienze 2mo ago

pjmlp 2mo ago

Me too, it is just another RPC endpoint, heck all of this kind of stuff could even be done with Sun RPC.

MikhailTal 2mo ago

Not all agents have access to a sandbox/cli/code execution environment to run arbitrary api calls etc. MCP helps by essentially having another tool call without needing a sandbox. If you do have a sandbox, then might as well do codemode if you insist on mcp https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/

agentdev001 2mo ago
Devil's advocate will say "Well, the agent would need an MCP client to use MCP-served resources... if you can give it that, why not give it an HTTP client?"

notatoad 2mo ago

it's not easier for agents to work with. it's easier for organizations to work with. for agents, they're essentially the same thing - remote endpoints, and instructions on how to call those endpoints. what MCP brings is centralized updating and distribution of the instructions, and a promise that the skill and the REST api won't be out of sync with each other. the one thing that skill.md+REST doesn't solve is how you get that skill.md to somebody else's computer, and how you ship an update to somebody else's computer once they've got a copy of the skill. if that's a problem you need to solve, you can either start inventing skill.md distribution protocols, or you can just use MCP.

boredumb 2mo ago
How is distributing a markdown file the bottleneck?
- tass 2mo ago
  Because it’s something else that’s non-standard between providers.
- stillpointlab 2mo ago
  It is the automatic distribution and automatic update. The questions isn't "how does one download a text file to another persons computer?". It is "how does someone with a skill.md file on their computer discover that a new version of that file is available". This isn't a "bottleneck" but rather a capability (or lack thereof). As you add more and more capabilities, especially ones relevant to enterprise situations like authentication, authorization, governance, etc. then MCP starts to pay off. If you do not need those capabilities, then you do not need MCP. And then you shouldn't use it. But if you do need those capabilities then it might be worth using MCP rather than inventing your own way to do them.
  - boredumb 2mo ago
    I see. In my head it would be something like the agents harness having a list of services it interacts with, reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.

wolttam 2mo ago

The model has zero awareness of MCP, it’s the harness’ job to talk to the MCP server and simply present the model with the tools just like any other tool. The only giveaway to the model about where the tools come from is the ‘mcp__’ prefix in the name

mikeocool 2mo ago

Companies got to release an MCP server for their product and tell their investors they were pivoting to be AI native.

ihuman 2mo ago

I don't want to expose my API key to Claude. An stdio MCP server wrapping an API lets me hide it

mathisfun123 2mo ago
wtf is the difference when 1) you put a key in front of the mcp 2) you mcp a whole bunch of privileged access. it's like saying "i don't want to give Claude access to my file system but i'm fine letting it run bash" ......
- intrasight 2mo ago
  The difference is that the LLM never sees your keys/secrets. My understanding is that can make a big difference.
  - JV00 2mo ago
    Does mcp guarantee that, per se?
    - anon84873628 2mo ago
      Not if you assume the straw man like grandparent, but yes if you use it thoughtfully.

c0rruptbytes 2mo ago

easier to gate MCP tools? you can allow/deny tools very easily

ffsm8 2mo ago

Mcp predates skills - and has a more granular permission model then skills + bash commands.

big-chungus4 2mo ago

MCP can also handle authorization, since you don't want to put your password to skills.md and send it to China

lubujackson 2mo ago

I work on an MCP server and I agree. There is no need to make MCP servers the gateway for agentic or programmatic integration - that's exactly what API servers handle out of the box. The value of MCP servers is fine-toothed access on a tool-by-tool basis and leaving output digestion to the LLM. LLMs do GREAT utilizing well-defined tools to accomplish tasks. Look at Datadog's MCP, instead of figuring out a multitude of filter and navigation options your LLM can immediately navigate to what you want and extract the precise data you need. Tool instructions with defined I/O structures let LLMs fly. But for a nightly cron job pulling down stats or something like that? Why the hell do you want to route through a protocol built for in-person consumption? This is such a pointless overreach for the protocol. What would have been better is blessing a standardized pattern for exporting any MCP tool definition into a well-structured API endpoint. Then everything related to API endpoints like doc generation, comes along for free. Instead we get this kitchen sink protocol that is going headlong toward polyfill hell, since no two IDEs support the same protocol features like structured content, local state, elicitations, etc., even from the same provider - Claude Code/Desktop/web all handle MCP connections differently. It's a shitshow. Almost every major MCP service uses the same baseline default features (plain context) rather than build around partially-supported features. Why add more and more specs on the pile when adoption is so far behind?

ketozhang 2mo ago

It's determinism, flexibility, and language. To the LLM, the a skill input is deterministic, inflexible, and outputs natural language. A REST API (not the REST itself, but modern output being JSON primitives) outputs are deterministic, flexible, but doesn't output natural language. An MCP as an input is deterministic, flexible, outputs natural language. Then we ask the same question on whether the LLM gets back a response that is deterministic. Skills output are not deterministic, it requires LLM to generate tokens to take action. It may or may not take the specific actions instructed by the skill. So, Skills + REST API = MCP only if you can deterministically call on the REST API.

ketozhang 2mo ago
In other words: * /skill may or may not call on the instructed action * /tool (or @tool) will guarantee the action is taken This is overgeneralizing and we need to talk about harness-specific features like hooks (which adds a deterministic action to skill usage).

adrian_m 1mo ago

Off the top of my head: * Your agent can easily be configured to always allow certain MCP tools. This is very hard to do for only certain REST endpoints. This is even more relevant in enterprise settings, where permission configs might be done centrally. * If the provider wants to change how an endpoint works, it's a breaking change for a REST API. Not with MCP, as the "endpoints" (tools) are dynamic and tell the agent how to use them.

mendapi 1mo ago
[flagged]

hyveops 1mo ago

[flagged]