Rysh Forge: point it at an OpenAPI spec, get agent tools and an MCP server

Your internal APIs are the reason your agents feel useless. Forge turns a spec into agent tools, SDKs, docs, and an MCP server.

Here's the unglamorous truth about why most companies' agents feel useless: the agent can't call anything that matters.

Your real leverage isn't in the model — it's in your internal APIs. The billing service. The provisioning endpoint. The inventory system. The CRM. An agent that can actually call those is an employee; an agent that can't is a very confident intern with no keycard.

And the path from "we have an API" to "our agent can use it" is hand-written glue, every single time: write a tool wrapper per endpoint, describe the parameters so the model understands them, handle auth, trim the responses so they don't nuke the context window, keep all of it in sync when the API changes. Multiply by every endpoint, then by every team that wants agents. This is the integration tax, and it's why "AI initiative" so often means "chatbot that can't do anything."

Rysh Forge exists to delete that tax. You point it at the machine-readable description of your API that you (hopefully) already have — an OpenAPI spec — and it generates the agent-facing layer:

##forge ./billing-api.openapi.yaml

Out the other side:

• Agent tools — each endpoint becomes a callable tool the rysh engine can use, with model-readable parameter descriptions derived from the spec.
• Context-budget-aware by construction — the generated tools are designed around your token window, not just around your API (this deserves its own post — it has one).
• SDKs and docs — the boring artifacts you'd have written anyway.
• An MCP server — the same API, exposed via the Model Context Protocol, so tools generated from your spec are consumable by any MCP client, not only rysh.

One spec in, a full agent integration surface out.

Why the spec is the right source of truth

The instinctive alternative — "just let the agent make HTTP calls with curl" — fails in practice for three reasons:

1. The model needs semantics, not just endpoints. A spec carries parameter types, enums, required fields, response schemas. Generated tools give the model exactly the contract, so it stops guessing field names and inventing query params.
2. Raw responses are context bombs. A single "list customers" call can return more JSON than your entire conversation history. Tools generated with a token budget in mind mediate that; curl doesn't.
3. Governance needs a seam. When every API interaction flows through a tool, it flows through rysh's existing machinery: every call visible in the pane, and the same approval model that gates the built-in tools applies to generated ones. A wall of ad-hoc curl gives you none of that.

There's also the maintenance story: the API changed? Re-run Forge against the updated spec. The generated layer is disposable output, not hand-tended glue.

Where the tools land

Forge output isn't a library you now have to wire up — the tools register into the same engine that runs everything else in rysh. Which means:

• A terminal pane agent can call your billing API mid-conversation, next to your shell.
• An autonomous agent spawned from a markdown skill file can use the same tools in its loop.
• Every call renders in the open, in a pane, like every other tool call — the audit trail isn't a separate product.

And because Forge also emits an MCP server, the flow works in the other direction too: teammates on other MCP-capable clients get the same tools, generated once, from the same spec. (rysh is also an MCP client — it consumes external MCP servers as happily as it produces them. Separate post.)

What about APIs that aren't reachable from here?

The spicy version of this problem: the API your agent needs isn't just undocumented-for-agents, it's unreachable — bound to loopback on a box in another network, private to a VPC, behind a bastion. Forge has an answer for that too — tunneling agent tool calls between rysh sessions, default-deny — and it's interesting enough (we proved it on camera against a loopback-only API) that it gets its own article.

Honest scope

• OpenAPI only, today. GraphQL and gRPC are on the roadmap — they are not live. If your API surface is GraphQL-first, Forge doesn't cover you yet; that's the honest state of it.
• 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 infra, your keys, your data. It is not open source.
• Generated tools are only as good as the spec. An OpenAPI file with empty descriptions and type: object everywhere will produce tools the model finds as confusing as your human SDK users do. Forge lowers the integration tax; it doesn't excuse a bad spec.
• Quality of generated SDK/docs output varies with spec complexity — review before shipping them to humans, same as you'd review any generated code.

The bigger picture

The pitch for an AI-native company isn't "we bought a chatbot." It's agents that can safely operate the systems the company actually runs on. That requires your internal APIs to be first-class citizens of the agent world — described, budgeted, governed, callable.

Forge is the on-ramp: the spec you already maintain becomes the integration, and every API you describe becomes something your agents — and your teammates' MCP clients — can use by lunch.

Have an OpenAPI spec and an agent that should be calling it? That's the exact shape of problem we want design partners for — bring your spec, we'll forge it together. → rysh.ai/design-partner

Companions: Forge tunneling: giving agents safe access to private APIs · Context-budget-aware tools