401–410 of 444 posts
Earlier quoted context omitted.
I suggest you implement an MCP server before adopting this as a firm technical opinion.
The opinion that more companies creating APIs is good?
Earlier quoted context omitted.
You’re right that having a shell is the ultimate tool, and an agent with a shell seems to perform better than one without one. But, making shells safe is really damn hard; e.g. in the context of running an agent on behalf of a SaaS customer in your AWS environment. For now some companies are accepting the performance/security tradeoff of disabling the shell and focusing on specialized tools. Remember: jq can always b…
jq cannot be just an MCP, unless it's acceptable that yuo pass all data through the context. If that's not acceptable and you want to have it as tool, then you need some other way to handle the data. I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files…
People seem to think that MCP exists to give agents more capability. That could not be further from the truth, which is actually the opposite: MCP exists to take capability away from agents. It exists to control them.
Earlier quoted context omitted.
I still didn't follow, you mean to pipe things between tool calls? Like if you want to query something and then update another without the intermediate getting brought in context?
Instead of requiring each session to understand the n tools used to solve a particular problem, you bundle up the solution in a conventional script (that's what I meant by "can", as in canning) that the agent can use with very little documentation in the context. When the model is smart enough to figure out the composition of underlying tools during regular execution, it will also be able to do the canning up as a sc…
Earlier quoted context omitted.
jq cannot be just an MCP, unless it's acceptable that yuo pass all data through the context. If that's not acceptable and you want to have it as tool, then you need some other way to handle the data. I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files…
jq can 100% be an MCP tool. Remember: Agent tools do not have to involve a network boundary. They can be natively implemented inside the agent harness, and/or they can be provided via a local MCP server. The point of making it a tool is to tightly allowlist what the agent is capable of executing; it can only execute jq, not any shell program, and moreover it isn't allowed to do things like redirection, pipes, etc; al…
That's really my only issue with MCPs.
With shell you can pass data from one component to another directly, not only being cheaper, faster, but also preserving complete integrity. While models nowadays seem to do data echoing well, there's always the chance they might not do it exactly.
There's no reason why a shell would not be able to limit abilities of a party using it as well, by virtue of just implementing only the desired functionality. What makes it more advanced in this context is the (standard) ability to express how to connect multiple components to each other, or to/from local storage. MCP does not have this.
Providing that does not have any inherent danger any more than jq's functions have an inherent danger. Actual execution of processes or real files does not need to be involved.
Earlier quoted context omitted.
jq can 100% be an MCP tool. Remember: Agent tools do not have to involve a network boundary. They can be natively implemented inside the agent harness, and/or they can be provided via a local MCP server. The point of making it a tool is to tightly allowlist what the agent is capable of executing; it can only execute jq, not any shell program, and moreover it isn't allowed to do things like redirection, pipes, etc; al…
Let's say you have a jq MCP. How do you pass data in and out to/from it without the data also being processed as tokens? That's really my only issue with MCPs. With shell you can pass data from one component to another directly, not only being cheaper, faster, but also preserving complete integrity. While models nowadays seem to do data echoing well, there's always the chance they might not do it exactly. There's no…
Provide a meta-tool which handles piping data in and out of any other tool, and make specific tools which can read/write data sources directly, bypassing context. Or you could go full code mode, but I'm not sure it's worth the lift unless you have Cloudflare numbers of APIs which would need tools.
I work on an internal model/vendor-independent chat app where the agent runs in the browser - every chat gets its own virtual origin private filesystem (OPFS) [1] directory where user attachments get written to and tools can read from/write to, and users can also provide read/write access to a real directory with window.showDirectoryPicker() [2] (both use the same API, so tools can route to/from either).
It can push and pull MBs of data through tools, e.g. pulling huge spreadsheets directly from SharePoint in 50,000 row chunks using a tool which calls the Excel Services REST API, passing those all into a code execution tool to join them together and process them, which generates an Excel output file using SheetJS, none of which goes into context.
People used to drag their multi-MB documents in and complain either it didn't work or the agent couldn't do anything useful with it. Now it just works.
[1] https://developer.mozilla.org/en-US/docs/Web/API/File_System...
[2] https://developer.mozilla.org/en-US/docs/Web/API/Window/show...
I use all three (MCP/CLI/API) based on what Claude excels at: * CLI: GitHub & AWS it already knows how to operate the CLIs well. Even learned about a few new CLIs like 1Password's op which it volunteered one day. * MCP: Supabase, Shopify etc. where the CLI would be non-obvious and the affordances from the tools/descriptions helps Claude maneuver. * API: Sometimes it just knows an API exists and is able to call it dir…
Also MCPs for programs like Chrome Dev tools or Playwright.
Sure you can use a cli tool and jq. Most cli tools that interact with third party providers are just APIs so you could argue it could be replaced with a curl.
Earlier quoted context omitted.
Let's say you have a jq MCP. How do you pass data in and out to/from it without the data also being processed as tokens? That's really my only issue with MCPs. With shell you can pass data from one component to another directly, not only being cheaper, faster, but also preserving complete integrity. While models nowadays seem to do data echoing well, there's always the chance they might not do it exactly. There's no…
> Let's say you have a jq MCP. How do you pass data in and out to/from it without the data also being processed as tokens? Provide a meta-tool which handles piping data in and out of any other tool, and make specific tools which can read/write data sources directly, bypassing context. Or you could go full code mode, but I'm not sure it's worth the lift unless you have Cloudflare numbers of APIs which would need tools…
I'm not saying MCP or the ways we use it cannot be extended to cover this use case, but my understanding is that nobody does it. But shell/code does, and more.
Earlier quoted context omitted.
Have you heard of the Ask Protocol? ( https://abject.world/ask-protocol/ ). I might be biased because I came up with it, but we are over complicating these systems. There is a simpler way, and it appears to work well since I built a system using it to test the idea.
Main points that came to my mind: - I think the comparison to TCP/DNS/BGP is the more apt one compared to MCP/A2A - Those protocols negotiate capabilities and exchange information about themselves, but not in a self-serving manner of just talking about themselves, but with the goal of ultimately transporting data for a higher layer. Ask Protocol lacks that. - Objects don't exist in a vacuum, but in a context. As the…
The reason comparing to TCP, DNS doesn't make sense is this doesn't replace those at all. The reason I compared against other agent frameworks and things like MCP is because that's the common question people have.
You are right objects don't exist in a vacuum but you are wrong an object that just exposes a description and an LLM reading it from the outside does better. Think about object oriented programming, objects expose and interface but don't reveal all of their internals. Calling the Ask handler could change internal state. Maybe response depends on what object is asking. Maybe the Ask handler might want to call the callers Ask handler too. You can't do that by just exposing a description.
You said the goal is to ultimately transport data to a higher layer. That's not the goal. You are thinking too hierarchical. The relationships between objects is dynamic and the concept of a higher layer makes no sense here since the point is to get rid of the hierarchical nature current agent protocols have.
Keep in mind I built a working system to test the concept. You can download and try it.