Rysh as an MCP client: the whole MCP ecosystem in your panes

Every MCP server anyone publishes is a capability your rysh agents can pick up — governed, visible, next to your shell.

The best thing to happen to agent tooling in the last two years isn't a model. It's a protocol.

The Model Context Protocol (MCP) did for agent tools what LSP did for editor intelligence: decoupled the two sides. Before LSP, every editor implemented every language, badly. Before MCP, every agent product implemented every integration, badly — its own GitHub wrapper, its own database connector, its own everything, forever.

With MCP, whoever knows the domain publishes a server; whatever speaks the protocol gets the tools. The ecosystem around it is already sprawling — databases, browsers, issue trackers, cloud providers, internal company services — and it grows without any single vendor's permission.

rysh speaks it fluently, in both directions:

• As a client — this post — rysh consumes any external MCP server, and its tools become available to the engine.
• As a producer — Rysh Forge generates an MCP server from your OpenAPI spec, so your APIs join that same ecosystem.

What "available to the engine" actually means

This is the part worth slowing down for, because it's where rysh differs from "chat app with an MCP settings page."

rysh isn't one assistant with one toolbox. It's an engine — the same agentic runtime powers interactive pane agents in your terminal, headless autonomous agents spawned from markdown skill files, and the rest of the platform's surfaces. When rysh connects to an MCP server, the server's tools land in the engine's tool registry — alongside the built-in file/git/shell/web tools — not in one chat window's settings.

Practical consequences:

• The agent in your pane can use your issue tracker's MCP tools mid-conversation, two keystrokes from your shell.
• An autonomous agent you spawned from a .md skill file can use them in its loop — same tools, no re-wiring.
• Tools compose: one task can flow through a built-in tool, a Forge-generated tool, and an MCP-served tool without the agent caring which is which.

Connect once, and every agent-shaped thing in your workspace got more capable. That's the platform effect MCP was designed for — it just needs a runtime on the client side that treats tools as engine-level, not app-level.

Governance doesn't care where a tool came from

Here's the uncomfortable question about the MCP gold rush that too few people ask: you just gave an agent a pile of new capabilities written by strangers — under what supervision?

rysh's answer is that MCP tools get no special trust. They flow through exactly the machinery every tool flows through:

• Visible. Every MCP tool call renders in the pane as it happens — name, input, result — next to your shell, in the open. Not in a log you'd have to go find; in the workspace where you're already looking.
• Gated. rysh's approval model fronts tool execution. Dangerous operations wait for a human; that posture doesn't evaporate because the tool arrived over a protocol.
• Inspectable. The engine can enumerate what's currently loaded (there's a list_tools tool — agents can literally check their own toolbox), so "what can this agent actually do right now?" has an answer.

The pane-based audit trail matters more with MCP, not less. Third-party tools are the exact case where you want execution happening where humans can watch.

Both directions, one loop

Put the client side and the Forge side together and a nice loop closes:

1. Your platform team runs Forge on the internal billing API's OpenAPI spec → out comes an MCP server.
2. rysh sessions across the team connect to it — plus the public MCP servers for your issue tracker and your cloud.
3. Every pane agent and autonomous agent in every workspace now operates your internal systems and your external ones through one governed engine, and the audit trail is the pane everyone's already looking at.

Your company's capabilities become tools; tools become the shared vocabulary of every agent you run. That's the "one engine, every surface" thesis doing its job at the integration layer.

And you're not locked in either direction: Forge-generated MCP servers work with any MCP client, and rysh consumes MCP servers regardless of who wrote them. The protocol is the contract — which is precisely why we bet on it instead of inventing a proprietary plugin format.

Honest scope

• rysh runs on Claude — bring your own Anthropic key. The provider layer is pluggable; Claude is what's wired today. No secret better model.
• rysh is self-hostable — your machine, your keys, your data. It is not open source.
• An MCP server is third-party code with real capabilities. rysh makes its calls visible and gated — it cannot make a malicious server benign. Vet what you connect, the way you'd vet a dependency.
• Tool quality varies wildly across the MCP ecosystem: some servers ship beautiful, model-friendly descriptions; some ship context bombs. The engine surfaces what a tool declares — it can't rewrite a bad server into a good one. (Why tool design matters this much: the context-budget post.)

Already running MCP servers — or wishing your internal APIs were one? Design partners get to shape exactly how this integration story unfolds. → rysh.ai/design-partner

Companions: Rysh Forge: point it at an OpenAPI spec, get agent tools and an MCP server · Context-budget-aware tools