Skip to main content
Glama
Sign In
maviapi

maviapi

by kuzenlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Build a new maviapi API

create_api

Start an API draft for a website lacking a suitable catalog API by describing the data you need; get a request_id, then track build progress with get_build_status.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "description": "<description>"
    },
    "name": "create_api"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe website, e.g. "https://news.ycombinator.com".
descriptionYesThe data wanted from the site, as specific as you can: pages, fields, filters. E.g. "front-page stories with title, url, points, comment count and author".
build_anywayNoBuild even though the catalog already has an API for this site (it lacks what you need).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing async behavior (returns a request_id at once), the fact that a completed build is unpublished, and that the shared demo key caps each network at 3 free builds per 30 days. The only gap is that it doesn't say how long a build typically takes or what happens to drafts left unpublished.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five short sentences, front-loaded with the purpose, then the async contract, then the publish caveat, then the quota. Every sentence carries information the agent needs and none repeat the annotations or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly discloses the only returned value (request_id) and the handoff to get_build_status, which is the key thing an agent needs. Minor gaps remain around build duration and failure modes, but nothing blocks a correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by framing description as plain-language input that the build agent interprets and by clarifying that url anchors the build to a real site rather than a catalog entry. It doesn't add format or sizing guidance for either string beyond the schema examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Start an API draft for a website") plus the scoping condition ("that no catalog API covers"), which cleanly separates it from search_apis, get_api and call_api. It also names what the agent must do next (get_build_status), so the tool's role in the workflow is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: use this only for sites the catalog doesn't cover, follow the returned request_id with get_build_status, and use build_anyway when catalog coverage exists but is insufficient. It also states that completion is not publication and that publishing happens in the dashboard with your own account and key.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools