111–120 of 127 posts
These are discoveries of workflows. Some of them work some of them don’t. The ones that really click, they explode in popularity like OpenClaw.
There is some important context missing from the article. First, MCP tools are sent on every request. If you look at the notion MCP the search tool description is basically a mini tutorial. This is going right into the context window. Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) MCP in general will bloat your context significantly. I think I counted…
So basically the best way to use MCP is not to use it at all and just call the APIs directly or through a CLI. If those dont exist then wrapping the MCP into a CLI is the second best thing. Makes you wonder whats the point of MCP
Earlier quoted context omitted.
There are very few stateful MCP Servers out there, and the standard is moving towards stateless by default. What is really making MCP stand out is: - oauth integration - generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI.
> What is really making MCP stand out is: > - oauth integration I don't see a reason a cli can't provide oauth integration flow. Every single language has an oauth client. > - generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI. This is actually a valid point. I solved it by using a sane agent harness that doesn't have artificial restrictions, but I understand that…
I started adding cli's for a few things last week. Initially just for myself but it didn't take me long to figure out that codex / claude code / etc. are pretty good at figuring out cli's as well. And creating them. If you have APIs, generating a usable cli for them is pretty straightforward. With lots of nice features, documentation, bash/zsh autocomplete support and other bells and whistles. Doing that manually is…
There is some important context missing from the article. First, MCP tools are sent on every request. If you look at the notion MCP the search tool description is basically a mini tutorial. This is going right into the context window. Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) MCP in general will bloat your context significantly. I think I counted…
I have an MCP server with ~120 functions and probably 500k tokens worth of help and documentation that models download.
But not all at once, that would be crazy. A good MCP tool is hierarchical, with a very short intro, links to well-structured docs that the model can request small pieces of, groups of functions with `—-help` params that explain how to use each one, and agent-friendly hints for grouping often-sequential calls together.
It’s a similar optimization to what you’re talking about with CLI; I’d argue that transport doesn’t really matter.
There are bad MCP serves that dump 150k tokens of instructions at init, but that’s a bad implementation, not intrinsic to the interface.
Earlier quoted context omitted.
Exactly. You shouldn't use MCPs unless there is some statefulness / state / session they need to maintain between calls. In all other cases, CLI or API calls are superior.
There are very few stateful MCP Servers out there, and the standard is moving towards stateless by default. What is really making MCP stand out is: - oauth integration - generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI.
There is some important context missing from the article. First, MCP tools are sent on every request. If you look at the notion MCP the search tool description is basically a mini tutorial. This is going right into the context window. Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) MCP in general will bloat your context significantly. I think I counted…
So basically the best way to use MCP is not to use it at all and just call the APIs directly or through a CLI. If those dont exist then wrapping the MCP into a CLI is the second best thing. Makes you wonder whats the point of MCP
I only use them for stuff that needs to run in-process, like a QT MCP that gives agents access to the element hierarchy for debugging and interacting with the GUI (like giving it access to Chrome inspector but for QT).
There is some important context missing from the article. First, MCP tools are sent on every request. If you look at the notion MCP the search tool description is basically a mini tutorial. This is going right into the context window. Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) MCP in general will bloat your context significantly. I think I counted…
Which applications that support MCP don't let you select the individual tools in a server?
The best things about AI hypergrowth is the opportunities to discover of meta-frameworks and workflows. This is something Anthropic kills at (MCPs, Skills, Claude Code terminal agents). These are discoveries of workflows. Some of them work some of them don’t. The ones that really click, they explode in popularity like OpenClaw.