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 when it is invoked from that scope — 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 working in that scope 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 run through the same machinery every tool runs through:

• Visible. Every MCP tool call renders in the pane as it happens — its name and a one-line 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, when you ask. MCP calls go through the same approval decision as native tools. Add a server with --approve and every one of its calls waits for a human; without it, its calls run without a prompt — so decide per server.
• 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 engine, and every call shows up in the pane that made it.

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 are standard MCP servers (stdio or Streamable HTTP), 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. No secret better model.
• rysh is open-core — the CLI is Apache-2.0, the server is proprietary. Your machine, your keys, your data.
• An MCP server is third-party code with real capabilities. rysh makes its calls visible, and gated when you add it with --approve — 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