41–50 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.
I am very curious how many MCP servers will actually implement all of this: "MCP authorization today is built around a person approving access in a browser. That works well for interactive clients, but more and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents. We want MCP servers to have a st…
"Oh no it's a long lived token that's bad"
Put it in a secret manager like 1pw cli and now start an agent...
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.
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.
Sometimes I really respect senior developers. When specs change, you obviously have to update existing work too. Looking at this MCP change, it seems like it's becoming stateless—I'm already wondering how to adapt. Senior programmers always advised me to only use things that have been around for at least three years. Now I finally understand why.
> "only use things that have been around for at least three years" Yikes. I can understand the desire to mitigate churn, but following this advice would be career suicide. Trying new things is essential.
I had to give maintenance to things people deployed to pad their resumes with "shiny new thing", and it was not fun.
If you intend to deploy and leave that as legacy for some poor shlemiel, sure.
If you intend to stay and actually keep things running, it's much better to use tried and tested stuff.
Earlier quoted context omitted.
Because you're a dev thinking for devs. No 60 year old is going to use Claude skills with the CLI. If my customers want their AI to interact with my product and MCP is the best way about it.
> 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 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.
Are others doing this?
It seemed obvious to me, but I don't hear others saying it.
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.