Skip to main content

​
Every API Is Now an MCP Server

AI agents can now use marketplace APIs directly over the Model Context Protocol:
  • Per-API servers at https://mcp.jojapi.com/{api-slug}: every documented endpoint becomes a tool, with parameter schemas, billing summaries and response examples derived from the API’s public documentation — the tool names match the OpenAPI spec’s operationIds.
  • A marketplace discovery server at https://mcp.jojapi.com: agents search the catalog, read full endpoint docs and call any endpoint from a single connector (search_apis, get_api, get_endpoint, call_endpoint).
  • Your existing key, your existing billing: calls authenticate with a JoJ API key sent as a header (Authorization: Bearer jk_...) and go through the gateway like any other request — same plans, quotas, rate limits and usage headers. Gateway errors come back as readable tool errors with the fix linked.
  • Connect button: every API page has a Connect dialog with ready-made snippets for Claude Code, Cursor, VS Code and claude.ai, prefilled with one of your keys.

​
Per-API-Key Analytics

Usage now splits by API key, so you can tell your apps, environments and teammates apart — a much-requested feature:
  • Filter analytics by key (Workspace → subscription → Analytics): every chart — requests, usage, latency, spent balance — can be scoped to a single key.
  • Usage by API key: a breakdown table under the chart shows each key’s requests, share of traffic, usage, average latency and pay-as-you-go spend over the selected period.
  • Request logs name the key: every log row shows which key made the request, and the list can be filtered to one key.
  • Last used (Workspace → API Keys): each key shows when it last made a request — handy for spotting keys that are no longer in use before deleting them.
  • Deleted keys keep their history: deleting a key stops it working immediately, but its name stays attached to its past usage and logs.
Per-key data accrues from August 23, 2026 — earlier usage appears aggregated as “Before key tracking”. To get the most out of the breakdown, give each application or environment its own named key.

​
Response Documentation, OpenAPI-Complete

Endpoints can now document their responses — per status, with JSON example bodies — and the model matches the OpenAPI Responses Object exactly:
  • Every response key OpenAPI allows: a concrete status code (200), an uppercase range (4XX) or default. The Studio editor accepts all three, the API page renders them, and the OpenAPI import no longer drops range or default entries.
  • Named examples: one status can carry several example bodies — each with a name and an optional summary — to document different situations: a match versus an empty result, two different causes of a 400. The API page renders every example under its status.
  • Round-trip fidelity: the OpenAPI export emits a single anonymous example as the singular example (what tooling renders most reliably) and anything richer as the named examples map; the import collects every named application/json example instead of only the first.

​
Capture Live Responses as Examples

Writing example bodies by hand is the tedious part of good documentation — so now you don’t have to:
  • Capture from live request (Studio → endpoint → Responses): send a real request through the gateway, prefilled with your documented example parameters, and save the live response as an example. Need a 400 example? Break a parameter on purpose and capture that.
  • Save as example (API page playground): as the API’s owner, every completed playground request gains a Save as example button that files the response body into your documentation.
  • Generate example responses (Studio → Endpoints): bulk-capture across every endpoint whose parameters are documented. The estimated credit cost is shown before anything is sent, results are reviewed before anything is saved, and only clean 2xx responses are pre-selected. Endpoints that can’t be captured are listed with what’s missing — doubling as a documentation to-do list.
Captured bodies are real responses, so a review step guards what goes public:
  • Trim arrays to first 2 items cuts a 200-element list down to a readable example in one click.
  • Fields that look like credentials or personal data (API keys, tokens, e-mail addresses) are flagged for redaction before publishing.
  • Responses produced by the gateway itself — auth, billing and quota errors — are detected and never auto-saved. Those are documented centrally in gateway-generated responses, which the playground now links.
Capture requests go through the gateway like any consumer request and are billed as such — so what you capture is exactly what your consumers will see.