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.
Review the selected operation list before publishing. In the Preview CLI workflow, omitting an operations filter can select all operations; specify a filter when you need a restricted surface.
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
Review the collection's quality report before publishing. The readiness panel uses the AI Readiness category and its findings, rather than a separate three-check percentage.
Fail findings appear as errors and Partial findings as warnings; NotApplicable checks are excluded from the readiness issue list. The report covers the collection, so inspect findings alongside your selected tools.
The shared grade thresholds are A ≥84, B ≥74, C ≥64, D ≥52, otherwise F. If the AI Readiness category is N/A, the panel can fall back to the overall collection grade. Inspect coverage in the full report. A score is a documentation signal, not a guarantee of safe or correct agent behavior.
How the hosted runtime serves every call
Elva hosts the MCP runtime. At call time it uses the published tool definition to build an upstream request, applies configured authentication, and returns the result to the client.
Preview, draft, and published states
Preview lets you inspect a proposed tool definition without saving a deployment. A draft saves the configuration but is not a callable published server. Publish when the selected tools and authentication are ready, then use the returned runtime URL to connect.
Preview: CLI draft and preview commands require a compatible build. Contract-generated MCP servers publish through their parent contract, so the contract's review and governance rules remain in effect.
After a collection scan or spec update, synchronize or rebuild the MCP definition and publish it separately. Test the published tool list and a read-only call; a successful import alone does not update an existing MCP deployment.
On this page
- Hosted MCP servers