That's entirely different to what's being desired by GP.
> > My dream tooling is for every tool to have an terminal interface so that I can create comprehensive megabooks to get all the context that lives in my head. i.e. jira, datadog, github etc, all in one pane.
My perspective on this is essentially having jira/datadog/github/etc be pluggable into the CLI, and where standard bash commands & pipes can be used without major restrictions. (Something akin to Yahoo Pipes)
MCP is highly centered around LLMs analyzing user requests & creating queries to be run on MCP servers. What's being desired here doesn't centralize around LLMs in any sense at all.
It’s actually not too far off. Yes MCP is designed for LLM interactions, but we observed that it’s an invocation API that’s pretty generic. So we built a package format that encapsulates computations and makes them accessible from any of MCP, REST, JSON-RPC over WS (the generic cousin of MCP)..
We build logic once and make it automatically accessible from any of these consumption methods, in a standardized way to our clients, and I am indeed piping some of these directly in the CLI to jq and others for analysis.
That's entirely different to what's being desired by GP.
> > My dream tooling is for every tool to have an terminal interface so that I can create comprehensive megabooks to get all the context that lives in my head. i.e. jira, datadog, github etc, all in one pane.
My perspective on this is essentially having jira/datadog/github/etc be pluggable into the CLI, and where standard bash commands & pipes can be used without major restrictions. (Something akin to Yahoo Pipes)
MCP is highly centered around LLMs analyzing user requests & creating queries to be run on MCP servers. What's being desired here doesn't centralize around LLMs in any sense at all.