When the client is an AI assistant: the MCP server and the Claude skills
Why this matters. This route did not exist two years ago and is now how a growing share of people meet the product. The user never sees an endpoint name.
Three things sit on this door, and they do different jobs.
The MCP server
The Model Context Protocol is how an assistant is handed tools. Our server exposes our endpoints as tools an assistant can call on a user's behalf: 72 read-only tools, more than 100 documentation resources and three prompt templates, reaching marketplace products as well as our own data (checked 2026-09-01).
There is a trap in those numbers, and this course fell into it: it printed 75 tools and warned the reader that 72 was the page count rather than the tool count. Both are 72, and that is not a coincidence — the 100+ resources are 72 endpoint reference pages, one per tool, plus 7 subscription-plan guides and 28 general reference pages. Two figures that match for a reason read like a mistake, so somebody 'corrected' one of them.
Treat the count as a reading rather than a constant either way: it grows with the API, and the number to quote is the one on the page today.
Read-only is the sentence that matters most. An assistant connected to this server can ask; it cannot write, cannot change an account, cannot spend anything. A client worried about giving a model access to their subscription is asking a real question, and that is the real answer.
The Claude skills
Packaged instructions that teach an assistant how to work with our data: which endpoint answers which question, what the parameters mean, how the responses are shaped. The server hands over capability; the skills hand over competence. A model with tools and no instructions will call the wrong one confidently.
The ChatGPT assistant
A different shape again: it generates code against our API rather than calling it. The output is something a person runs, which means the failure mode is a plausible snippet against an endpoint that does not work that way, rather than a bad call.
Tools are not an API key
Worth being precise, because the distinction decides several client conversations.
Handing someone an API key gives them the whole surface and the whole responsibility. Handing an assistant a set of tools gives it a named, described, bounded set of actions, and the description of each tool is ours rather than theirs. That moves the burden onto our tool descriptions: if a tool is described badly, the assistant will pick it for the wrong question and the user will never know why the answer was odd.
The skills and the server carry the same catalogue
The numbers line up, and noticing that saves you re-learning them. The skills package 72 documented endpoints, 28 reference guides and 7 subscription-plan guides, plus a small dependency-free Python client and analysis templates. Those are the same 72, 28 and 7 that make up the server's 100+ resources, because both are built from one catalogue of our API.
What differs is what the assistant does with it. The server hands over tools it can call; the skills hand over instructions for calling them, and an assistant can have either without the other. A client already using the MCP server who asks what the skills would add is asking a real question, and the answer is competence rather than reach.
Try it now
Write the one sentence you would send a client asking whether they can rely on the MCP server today. Then write what you would add if they asked whether their assistant could accidentally change something.