91–100 of 184 posts
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.
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.
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 s…
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.
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…
I can see that.
I am developing my first custom agents. I am finding that if I offload some workflow to another agent (e.g. Claude Code), the simplest way to control what it can or cannot do is via an MCP server (which only lets it access tools that I develop/approve myself). I do need that control in the corporate environment.
Maybe there are easier ways to do it, just learning and exploring now.
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.
Earlier quoted context omitted.
Is that really much different from building an API for your app though? Claude can use those just as easily.
With authentication and on mobile? I agree that on desktop it's not particularly relevant. Or through openclaw. But for most people who use it through mobile, MCP solves some problems.
It's been a long time since I've used Claude, but is it not able to just use curl and an API key that it keeps in its "memory" on mobile? Or can it only use curl on the desktop?
Earlier quoted context omitted.
> If my customers want their AI to interact with my product and MCP is the best way about it. Would be really interested to know how many of your customers actually use the MCP, who aren't already devs thinking like devs. I have doubts that many non-technical people are connecting AI to third-party services via MCP (or even using AI at all beyond "mundane" things like "generate an image of my cat as a clown" or "show…
I actually have data on this albeit it's a bit skewed. None of our clients are dev like folk but they are financial folks. We sell financial data for big players so not the analysts (seat cost is over 50k per year) and of our ~10k users within the last 6 months of us launching MCP we have 1500 DAUs on the MCP
Earlier quoted context omitted.
Would you prefer gRPC, thrift, avro, etc... ?
Those are mostly at a different layer. You can speak Thrift or Avro or Protobuf over stdio or HTTP or TCP or carrier pigeon. gRPC spans layers, and it uses HTTP in a more intrusive way than even MCP does — it expects to own the entire URL space at the IP/port in question. Using gRPC in a nontrivial way for MCP would be fairly heavy-weight: you would probably need to set up reflection and figure out how to bind all th…
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.
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…