Infrastructure for APIs in the age of agents.
From an agent's first read of your docs to its millionth production call, Scalar is the layer in between: hosted, observed, and kept in sync from one OpenAPI document.
The ultimate interface is a chat box
For two decades we obsessed over purpose-built interfaces. Every product earned its own: an issue tracker shaped around sprints, an inbox tuned for speed, a calendar laid out by the week, an API reference with every endpoint in its sidebar. Teams argued over layouts, keyboard shortcuts and empty states, because the interface was the product.
Now the interface people reach for first is a chat box. There is nothing to learn: ask for the issues still open before Thursday, and the answer comes back in the conversation. The interface that matters is the one an agent can use: your API, and the documentation that explains it.
The internet already has a name for this: going headless. Products ship an MCP server beside their app, and product teams have started to ask what their product is when nobody opens it.
Scalar gets your product into the chat box
Scalar gives an agent what it needs from the OpenAPI document you already maintain: documentation it can read, and an MCP server it can call.
First, an agent has to understand your product. It wants Markdown, not a rendered page, so Scalar serves both from one source, along with an llms.txt. Under it all is an open source core with 15.7k GitHub stars and eight framework integrations.
Then your users' agents act on it, with no code at all. Someone asks Claude or ChatGPT for something, and the agent calls your API itself. Scalar turns your OpenAPI document into that MCP server, and any API fits in a fixed tool set of about 0.2% of context.
MCP & Agent
Connect your APIs to LLMs quickly, securely, and with minimal context. One line connects Claude, ChatGPT or any remote MCP client to the operations you choose, with nothing to deploy.
Then a developer's agent builds on it
Your customers' coding agents write the integration now. Scalar generates typed SDKs from your OpenAPI document, one pull request per release, so an agent's code compiles the first time.
TypeScript, Python, Go, Java, Kotlin, and Ruby are generally available, plus a CLI, published to npm, PyPI, Go modules, Maven Central, and RubyGems with changelogs. Coming from Stainless? Upload your stainless.yml as it is and existing call sites keep working.
Customer showcase: Warp
Warp builds AI-native employee management and wants everything in its app reachable by API. Some of its customers already connect Claude to everything, building reports, sending an employee invite, or signing an offer without opening the app. When its SDK vendor discontinued its product, Warp moved its TypeScript, Python, and Go SDKs and its CLI to Scalar: every language at parity, with no breaking changes.
import WarpAPI from "warp-hr";
const client = new WarpAPI({
apiKey: process.env["API_KEY"], // defaults to the API_KEY env var
});
const assignments = await client.timeOff.listAssignments();
import os
from warp import Warp
client = Warp(
api_key=os.environ.get("WARP_API_KEY"),
)
time_off = client.time_off.list_assignments()
package main
import (
"context"
"os"
sdk "github.com/TeamWarp/warp-go-sdk"
"github.com/TeamWarp/warp-go-sdk/option"
)
func main() {
client := sdk.NewClient(
option.WithAPIKey(os.Getenv("WARP_API_KEY")),
)
timeOff, err := client.TimeOff.ListAssignments(context.Background(), sdk.TimeOffListAssignmentsParams{})
if err != nil {
panic(err)
}
_ = timeOff
}
We run the infrastructure. You run your API.
People ask a chat box, developers ask a coding agent or install an SDK, and every path leads back to your API. From the one OpenAPI document you already maintain, Scalar builds docs to read, an MCP server to call, and typed SDKs to build on.
Connecting takes one line, from any remote MCP client to the operations you choose. Behind that line, an MCP server is a production service. It must stay up, authenticate callers, absorb agent traffic, and track a protocol that changes every few months. Scalar runs yours at mcp.yourcompany.com, with OAuth, rate limits and nothing to deploy, and goes where MCP goes. You see call counts, errors and latency per tool and client, with arguments never stored. You keep shipping your API.
The interface is still the product. It has moved to your API, where its newest users are agents working for your customers. The care that once went into screens belongs there now: every button backed by an operation, and every operation described so plainly that nothing is left to guess.
Make your API ready for the agents that are already looking for it.
Start with your OpenAPI document. Docs, SDKs, and a hosted MCP server all follow from it.
