Hosted MCP servers
Point Elva at a collection, pick the operations you trust, and it ships a hosted MCP server that agents can call over HTTP in one pass. No boilerplate project, no server to run, no runtime to babysit.
MCP is the Model Context Protocol: the open contract agents like Claude, Cursor, and VS Code speak to reach external systems. In MCP terms, a tool is a single callable action. Elva turns each operation you select into exactly one tool, so an agent sees your API as a clean list of things it can do, not a spec it has to parse.
From collection to callable server
Every deployment gets a stable deploymentId in the shape companySlug/mcpSlug, derived from your workspace and the name you give the MCP. That id is the address agents connect to.
1
Pick a collection
Open any collection in the catalog and start a new MCP. Elva reads the stored OpenAPI spec and lists every operation as a candidate tool.
2
Name it and select operations
Give the MCP a name (the slug is generated from it) and check the operations you want exposed. Each selected operation becomes one tool with an auto-generated name, capped at 64 characters to satisfy Claude's tool-name limit.
3
Set the target and auth
Set the upstream base URL and choose how the runtime authenticates to your API. Tune the timeout, pagination, and include/exclude filters if you need to trim the surface.
4
Generate and deploy
Elva compiles your selection into an execution schema, stores it, and publishes the deployment with status: published. The response returns the deploymentId, the live runtimeUrl, and the final toolCount.
Only the operations you select are exposed. Everything you leave unchecked is stripped from the generated schema, so agents never see endpoints you did not intend to publish.
Generation options
When you generate a deployment, these knobs shape which operations become tools and how the runtime calls them.
Option | What it controls | Default |
| The upstream API the runtime sends requests to | First server URL in the spec |
| Per-request timeout budget |
|
| Adds a pagination helper to list-style operations |
|
| Keep or drop operations by OpenAPI tag | none |
| Keep or drop by HTTP method | none |
| Drop operations whose path matches a pattern | none |
| The explicit set of operations that become tools | none selected |
Readiness checks before you ship
During creation, Elva scores each operation for AI-readiness so you know your tools are safe to hand to an agent. Every operation runs three checks:
- Missing request body schema (error) on
POST,PUT, andPATCHoperations that define no request body. - No response schema (warning) when there is no
200,201, or204response defined. - No description (info) when the operation has neither a summary nor a description.
The score is the share of checks that pass across all operations, graded A (90+), B (80+), C (70+), D (60+), else F. Filter the issue list by severity to fix the errors that matter most before an agent ever calls the tool. What each check protects agents from — and how to raise the grade in one pass — is covered on the AI readiness page.
How the hosted runtime serves every call
You do not deploy a server per API. A single stateless MCP runtime serves every deployment over HTTP. When an agent calls a tool, the runtime loads that deployment’s execution schema, builds the upstream request from the tool call, forwards it to your API, and returns the response as content the agent can read.
On this page
- Hosted MCP servers