Every API on JoJ API is now an MCP server
Point your AI agent at mcp.jojapi.com/{api} and every documented endpoint becomes a callable tool — same key, same gateway, same billing. Here's how it works and how to connect Claude Code, Cursor or VS Code in under a minute.
By JoJ API · · 3 min read
As of today, every API on the JoJ API marketplace is also a Model Context Protocol server. Not a wrapper you install, not an SDK you generate — a URL you hand to your agent:
https://mcp.jojapi.com/{api-slug}
Connect it, and every documented endpoint of that API shows up as a tool: typed parameters, required fields, enums, defaults, billing summaries, example responses. The agent calls it with your regular JoJ API key, through the same gateway as every other request, billed to the same subscription.
Sixty seconds to a working tool
Take the X (Twitter) API. In Claude Code:
claude mcp add --transport http joj-twitter https://mcp.jojapi.com/twitter --header "Authorization: Bearer jk_..."
That's the whole integration. Ask Claude to look something up on X and it picks the right endpoint from the API's own documentation, fills the parameters, and gets back the response plus a usage line:
usage — credits used: 1, credits remaining: 997
Cursor and VS Code take the same server as an mcp.json entry, and every API page now has a Connect button that writes these snippets for you — with one of your own keys already filled in.
One connector for the whole catalog
If you'd rather not wire a server per API, https://mcp.jojapi.com is a marketplace-wide discovery server with four tools:
search_apis— search the catalogget_api— one API's overview and endpoint listget_endpoint— full parameter and response documentationcall_endpoint— execute any endpoint (needs your key)
An agent can go from "I need SERP data" to a successful call without you configuring anything but the one connector. Searching and reading documentation is free; only real calls hit your subscription.
The part we didn't have to build
The honest reason this shipped fast: an API marketplace already is most of an MCP server.
Tool schemas? Our providers already document parameters with types, requirements and enums — the same data that renders the API pages and the OpenAPI specs. Tool names match the spec's operationIds (get_v1_search), so what an agent sees over MCP and what you see in the OpenAPI export are the same identifiers.
Auth, metering, quotas, rate limits? The MCP layer doesn't reimplement any of it. A tool call is a gateway call. Your key never appears in tool arguments or URLs — it travels as an HTTP header on the connection, and the gateway strips it before anything reaches the upstream provider, exactly as it always has.
Even the errors work in the agent's favor. When a plan runs out of quota mid-conversation, the agent doesn't get a bare 402 — it gets told what ran out and where to fix it, with the pricing page linked. Agents read error messages. Ours now say something useful.
Limits, stated plainly
- Responses over 50,000 characters are truncated (with a note) — an agent's context window is a budget, and a 4 MB response body is an attack on it.
- Calls time out at 95 seconds; streaming (SSE) endpoints are delivered buffered.
- Tool lists follow the API's public documentation with ~5 minutes of cache.
- claude.ai custom connectors support header auth in beta; Claude Code, Cursor, VS Code and the Claude API support it everywhere today. OAuth is on our roadmap for the web-first clients.
The full guide — auth shapes, error semantics, client-by-client setup — is in the MCP documentation. The catalog is at jojapi.com/hub; every API page now links its MCP server next to its OpenAPI spec.