61–70 of 81 posts
can someone explain to me the difference between MCP and calling a cli tool eg curl or whatever i still don’t understand i’ve been using ai for years now.
MCP is tool calling with continued context/rich context, tool calling alone will PROBABLY die after single call whereas MCP keeps continuity by design (You can use MCP for tool calling but not vice versa). Hope this help you understand.
Earlier quoted context omitted.
Skills are less exciting because they're effectively documentation that's selectively loaded. They are a bigger deal in a sense because they remove the need for all the scaffolding MCPs require. E.g. I needed Claude to work on transcripts from my Fathom account, so I just had it write a CLI script to download them, and then I had it write a SKILL.md, and didn't have to care about wrapping it up into an MCP. At a clie…
Skills are good for context management as everything that happens while executing the skill remains “invisible” to the parent context, but they do inherit the parent context. So it’s pretty effective for a certain set of problems. MCP is completely different, I don’t understand why people keep comparing the two. A skill cannot connect to your Slack server. Skills are more similar to sub-agents, the main difference be…
> "I expect us to go back to extending our agents with the most accessible programming language: natural language." I don't agree with this. Natural language is so ambiguous. At least for software development the hard work is still coming up with clearly defined solutions. There is a reason for why math has its own domain specific language.
> Natural language is so ambiguous. As a former tech comms guy I will say: Natural language can be bent into arbitrary precision. Write something, then enter a read-rewrite-reread loop as the devil's advocate (this is key) until it stops being ambiguous or having multiple conceivable interpretations. Yes with English this process can be a pain in the butt, until you get the hang of it.
> "I expect us to go back to extending our agents with the most accessible programming language: natural language." I don't agree with this. Natural language is so ambiguous. At least for software development the hard work is still coming up with clearly defined solutions. There is a reason for why math has its own domain specific language.
> Natural language is so ambiguous. As a former tech comms guy I will say: Natural language can be bent into arbitrary precision. Write something, then enter a read-rewrite-reread loop as the devil's advocate (this is key) until it stops being ambiguous or having multiple conceivable interpretations. Yes with English this process can be a pain in the butt, until you get the hang of it.
> "I expect us to go back to extending our agents with the most accessible programming language: natural language." I don't agree with this. Natural language is so ambiguous. At least for software development the hard work is still coming up with clearly defined solutions. There is a reason for why math has its own domain specific language.
> Natural language is so ambiguous. As a former tech comms guy I will say: Natural language can be bent into arbitrary precision. Write something, then enter a read-rewrite-reread loop as the devil's advocate (this is key) until it stops being ambiguous or having multiple conceivable interpretations. Yes with English this process can be a pain in the butt, until you get the hang of it.
There's a good reason we use jargon in professions, or more constrained and less ambiguous languages for maths/coding
> "I expect us to go back to extending our agents with the most accessible programming language: natural language." I don't agree with this. Natural language is so ambiguous. At least for software development the hard work is still coming up with clearly defined solutions. There is a reason for why math has its own domain specific language.
> Natural language is so ambiguous. As a former tech comms guy I will say: Natural language can be bent into arbitrary precision. Write something, then enter a read-rewrite-reread loop as the devil's advocate (this is key) until it stops being ambiguous or having multiple conceivable interpretations. Yes with English this process can be a pain in the butt, until you get the hang of it.
Earlier quoted context omitted.
Skills are like the "end-user" version of MCP at best, where MCP is for people building systems. Any other point of view raises a lot of questions. Aren't skills really just a collection of tagged MCP prompts, config resources, and tools, except with more lock-in since only Claude can use it? About that "agent virtual environment" that runs the scripts.. how is it customized, and.. can it just be a container? Aren't…
There's no lock-in there. Tell your agent of choice to read the preamble of all the documents in the skills directory, and tell it that when it has a task that matches one of the preambles, it should read the rest of the relevant file for full instructions. There are far fewer dependencies for skills than for MCP. Even a model that knows nothing about tool use beyond how to run a shell command, and has no support for…
This is wrong and an example magical thinking. AI obviously does not mean that you can ship/use software without addressing dependencies? See for example https://github.com/anthropics/skills/blob/main/slack-gif-cre... or worse, the many other skills that just punt on this and assume CLI tools and libraries are already available
Earlier quoted context omitted.
Skills are good for context management as everything that happens while executing the skill remains “invisible” to the parent context, but they do inherit the parent context. So it’s pretty effective for a certain set of problems. MCP is completely different, I don’t understand why people keep comparing the two. A skill cannot connect to your Slack server. Skills are more similar to sub-agents, the main difference be…
Are you sure, i thought skill were loaded into the main context, unlike (sub)agents. According to Claude they're loaded into the main context. Do you have link?
Earlier quoted context omitted.
Are you sure, i thought skill were loaded into the main context, unlike (sub)agents. According to Claude they're loaded into the main context. Do you have link?
No, just their header / when they should be invoked, the actual contents of the skill is never loaded in the main context.
Earlier quoted context omitted.
There is a LOT under the surface. custom routes, bidirectional streaming choices (it started as a "local first" protocol). Implementing an endpoint from scratch is not easy, and the spec documentation moves very quickly, and generally doesn't have simple-to-digest updates for implementation. I haven't looked in a few months, so my information might be a bit out of date, but at the time - if you wanted to use a python…
Well if your language of choice didn't have any good library support for HTTP, the web version of hello world would be hard too, but it would not say much about the protocol. Even with these constraints the core MCP design is actually pretty good. First, use stdio transport, and now your language only needs to speak JSON [1]. Then, forget about building proxies and routers and web stuff, and offload that to mcpjungle…
For reference, I think writing an MCP proxy layer in (lang of choice) is significantly harder than writing something to respond to GET / over http, both in complexity of what clients need out of a server (web clients are hardened to deal with all kinds of bad behavior), and in the amount of stuff you actually need to write, and also in the lack of documentation.