upvote
> it's easier for organizations to work with.

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.

reply
No need to invent skill.md distribution protocols. Use `/.well-known/agent-skills/index.json` -- see https://github.com/agentskills/agentskills/pull/254.

It's already in use in several places (e.g., https://www.mintlify.com/docs/ai/skillmd#skills-discovery-en...) and is supported by `npx skills add`.

reply
Maybe I just need more patience, but I took a look at some tools that have MCPs, and their "setup guide" on how to start using the MCP server really gave me brain damage. Is this really easier to work with?
reply
For antiquated "enterprise" APIs that were already a mess of legacy cruft, yes. MCP forced vendors to reconsider the ergonomics of their interface.
reply
It seems like organizations will mostly want remote access via http and the other flavors of MCP aren’t so useful? Although, I suppose if you install an app locally, it might have an MCP interface.
reply
I guess it's similar to SOAP, it was usually over HTTP but sometimes the alternatives were used (eg. email [1])

[1]: https://www.w3.org/TR/soap12-email/

reply
That would be /llms.txt https://llmstxt.org/
reply
How is distributing a markdown file the bottleneck?
reply
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.

reply
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.
reply
Valid. There are many ways to do it.

But for enterprise there may be teams, each developing their own way to do it. Then there will be many different ways that it is done throughout the enterprise, which is hard re: governance. Better/easier to adhere to an industry standard which can be audited, especially for enterprises where that is a legal requirement.

That isn't a reason you should use it, just an explanation about why someone has to use it.

reply
>reaches out to service.com/agents.md for a fresh copy every so often and uses that to resolve the relevant tool calls.

that is basically what MCP is. except it answers all the questions that your version handwaves away - how often do you get a fresh copy, how do you describe the relevant tool calls, how are the tools organized, and how does auth work.

reply
If that truly is the main selling point - it seems like a shallow moat versus skills + rest..
reply
deleted
reply
Because it’s something else that’s non-standard between providers.
reply