Docs / Endpoints: webhooks, APIs, MCP, apps

Turning an API into an MCP server

Most business APIs an assistant would be useful against have no MCP server and never will. Writing one means a service to host, a credential to hold, a schema per tool and a deployment to keep alive — for an API somebody else already built.

If you have configured a few calls against that API here, the server already exists. An endpoint set to offer tools publishes those calls as tools, with the schemas generated from what each call declares and the API’s own credential attached by the platform. There is nothing to write and nothing to deploy.

An endpoint an assistant can call is the page that walks it: the two decisions, the controls by their names, what a tool takes, the address, and who may reach which tool. It is proven by a real MCP client against a real node in the product’s own suite.

What it is worth

The API stays where it is. The assistant talks to your endpoint; your endpoint talks to the API with the credential you configured once. The assistant never receives it.

One table, several audiences. The same configured calls answer a script, a Test in the browser, an HTTP caller and an assistant. Adding a tool is naming an operation, not writing an adapter.

The tool list is generated. Whatever your operations declare is what the client is offered, so the description a client reads cannot drift from the call it makes.

What it costs

The endpoint is stateless. An assistant that retries a call starts a second run. Make what an operation points at safe to repeat — a lookup, or an upsert by an id the caller supplies — or accept that a retry is a second act.

A tool call is a run. It is queued fairly, runs in its own process, and answers within the synchronous budget like any other caller who waits. Long work belongs behind a webhook or a schedule, not a tool.

Who may call is a decision per operation, and signed-in callers are your app users — a population of the environment, never people who can sign in to the product.