maviapi
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MAVIAPI_TOOLS | No | Comma-separated API slugs to expose as typed per-endpoint tools (e.g. booking,airbnb,kiwi), or 'all'. | |
| MAVIAPI_API_KEY | No | Your API key from the maviapi dashboard. Defaults to maviapi's shared demo key (30 requests/minute, 300/day per network). | |
| MAVIAPI_BASE_URL | No | Point at another maviapi deployment. | https://api.maviapi.com |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
maviapi gives you live, structured JSON from websites that have no official API (travel, e-commerce, news, events, finance and more). Workflow: search_apis to find an API for a site or topic, get_api to read its endpoints and parameters, then call_api to fetch data. If no API covers the site you need, create_api builds one (about half an hour; follow it with get_build_status).
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_apisA | Find a ready-made maviapi API for a website or topic, e.g. "hotels", "flights", "booking.com" or "turkish news". maviapi turns websites that have no official API into structured JSON endpoints, and monitors and repairs them when the site changes. Leave |
| get_apiA | Show one maviapi API's endpoints: what each returns, its parameters (required ones marked), and the fields in the response. Accepts the API slug from search_apis, or the site's domain (e.g. "airbnb.com"). Read this before call_api. |
| call_apiA | Fetch live, structured JSON from a website through a maviapi endpoint. |
| create_apiA | Start an API draft for a website that no catalog API covers. maviapi's build agent studies the site and builds a JSON API from a plain-language description. This returns a request_id at once; follow it with get_build_status. Build completion does not publish the API. Use your own account and key to review and publish the draft in the dashboard. With the shared demo key each network gets 3 free builds per 30 days. |
| get_build_statusA | Progress of a build started with create_api: queued, building, deploying, published, or failed. The build status published means the build completed, not that the API is publicly available. Checks catalog visibility separately; the owner reviews and publishes drafts in the dashboard. Check back every few minutes rather than in a tight loop. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool maps to a distinct stage of one workflow: search_apis discovers, get_api inspects endpoints/params, call_api executes, create_api drafts a new API, and get_build_status polls a build. The descriptions explicitly spell out the handoffs (e.g. search_apis → get_api → call_api), so misselection is unlikely even between get_api and call_api.
All names follow a consistent verb_noun snake_case pattern: search_apis, get_api, call_api, create_api, get_build_status. The get_* prefix is used coherently for read operations and create_ for mutation.
Five tools is tightly scoped to the domain: discovery, schema inspection, execution, provisioning, and async status. No tool looks redundant and none feels padded.
The core discover→inspect→call and request→build→status workflows are covered. There is a gap at the end of the lifecycle: publishing a draft must happen in the dashboard, and there is no tool to update, delete, or manage created APIs, nor to check credits.