MCP Server vs API: Stripe, HubSpot and GitHub Expose a Fraction of Their Surface

GitHub's official MCP server reaches 22 of the 51 categories in its own REST API. HubSpot's reaches 36 of the 123 API families it publishes. A vendor announcing Model Context Protocol support is telling you an agent can get in the door, not which rooms it can enter. We counted both sides of that gap for Stripe, HubSpot and GitHub, so you can see what an agent can and cannot do before you buy one.

The short answer: an MCP server is a curated subset of a vendor's API, chosen by the vendor. At GitHub and HubSpot that subset covers well under half of the public API. Stripe is the exception in shape, because 2 generic tools front a documented list of 152 methods. Check the list, not the logo.

If you need the protocol background first, read how MCP became the default agent interoperability standard. This post assumes you know what a tool call is and asks a narrower question: how much of the vendor's product does the official server actually reach?

How the MCP server vs API coverage ratio was counted

A coverage ratio needs a numerator and a denominator from the same vendor, read on the same day. Both sides of every ratio in this post come from the vendor's own public pages, read on 17 October 2026.

The numerator is what the official MCP server documents. We used only vendor-published tool lists: the GitHub server's README, Stripe's MCP page and HubSpot's remote server page. Community wrappers are excluded, for the reasons covered in the analysis of MCP server supply chain risk.

Why we counted API families, not endpoints

The cleanest denominator would be a count of every REST operation in each vendor's OpenAPI file. None of the three vendors states that total anywhere we could find. The most recent public figure for GitHub is from 2020, when GitHub said its OpenAPI description held more than 600 operations, according to InfoQ's report on the launch.

So the denominator here is the vendor's own grouping of its API. GitHub lists 51 top-level categories in its REST API documentation. HubSpot's public spec index lists 123 API families. Stripe's denominator is the 21 product namespaces in its official Node library, explained in the Stripe section below.

A family counts as reachable if at least one documented tool reads or writes it. That is a generous test. GitHub's Actions category has 14 subcategories, and an agent reaching 4 Actions tools counts the same as one reaching all 14. Every ratio below is therefore a ceiling on real coverage, not an estimate of it.

We think a generous numerator is the right call. If a vendor fails a test this lenient, the conclusion is safe.

Stripe MCP: 15 tools that front 152 API methods

Stripe built its server around a different idea from the other two. Instead of one tool per action, it ships 4 API tools: search for a method, get its parameters, read, and write. The page describes stripe_api_read as able to "read data with any Stripe API GET method" and stripe_api_write as covering POST, PATCH, PUT and DELETE.

The other 11 tools are a mix: account information, Atlas company formation, analytics, documentation search, an implementation planner, a feedback tool, and 5 Treasury tools marked public preview. So the tool count of 15 tells you almost nothing about reach.

The supported methods list is the real contract

Below the tools, Stripe's MCP page publishes a "Supported API methods" list. We counted 152 entries across 64 resources: 112 reads and 40 writes. They cover the core of payments and billing: customers, charges, refunds, payment intents, invoices, subscriptions, prices, products, disputes and webhook endpoints.

The intro to that list says the access "makes much of the API available through MCP". Much, not all. The tool descriptions say "any" method. We read the narrower phrase as the binding one, because it is the one written for someone deciding what to rely on.

Stripe's official Node library groups its newer products into 21 resource namespaces. Only 6 contain a resource that appears on the MCP methods list: the billing portal, Checkout, Issuing, Tax, test helpers and the v2 API. 14 do not, including Terminal, Identity, Radar, Reporting, Financial Connections, Entitlements and Billing meters. One, Sigma, we could not map with confidence.

Top-level resources show the same pattern. Quotes, Files and the v1 Connect accounts API exist in the library and do not appear on the methods list. If your agent needs to draft a quote or verify an identity, the documentation gives you no assurance it can.

Stripe also puts a human between the agent and the money. The page states that refunds and outbound payments need a person to click an approval link before they run. We think that is the correct design, and the other two vendors should copy the principle.

GitHub MCP server: 96 tools across 22 of 51 REST categories

The github-mcp-server README lists 96 distinct tools: 92 in 22 local toolsets and 4 more on the remote server. That is the largest tool list of the three by a wide margin, and it still reaches fewer than half of GitHub's REST categories.

The default configuration is smaller again. With no toolsets specified, the server loads context, repos, issues, pull requests and users. By the README's own list that is 45 tools, so an agent installed with defaults sees under half of the 96.

Many GitHub tools take a method parameter, so one tool such as issue_read covers several operations. GitHub explained why in its 28 January 2026 changelog. Merging the Projects toolset into 3 tools cut token usage by around 23,000 tokens, or 50%.

The same changelog shows a second filter. With a classic personal access token, the server detects the token's scopes and hides tools the token cannot use. So the tools an agent sees depend on the credential as well as the server, which matters for anyone running agents on shared tokens. That design question is covered in the comparison of agent credentials and user impersonation.

All 29 categories with no tool are listed. Matching is by function: a category counts as reached if any tool in the README performs an operation documented in it. The repos category counts as reached even though its webhooks subcategory has no tool, which flatters GitHub's ratio slightly.

The small utilities row deserves fairness. 7 of the 29 gaps are reference lookups such as emojis, gitignore templates and licences, which no agent needs as a tool. Strip those out and GitHub reaches 22 of 44 categories, an even 50%.

The delivery row is the one that matters. An agent can open a pull request, review it and merge it through MCP. It cannot post the check run that gates the merge, or create the deployment that follows it. We think that boundary is deliberate: GitHub wants the release decision to stay inside Actions, where it owns the audit trail.

HubSpot MCP: 32 tools against 123 API families

HubSpot's remote MCP server page lists 32 tools. The page notes that availability varies by subscription, user permissions and account configuration. The tools cover CRM search, reads and writes, properties, pipelines, owners, campaigns, conversations, marketing email drafts, landing pages, website pages, blog posts and answer engine optimisation data.

HubSpot's public spec index lists 123 API families. We mapped each to the tool list and found 36 reachable. That is a coverage ratio of 29%, and it splits sharply by area.

CRM records are open, the CRM machinery is not

Of the 66 families in HubSpot's CRM group, 29 are reachable. Contacts, companies, deals, tickets, leads, activities, products, quotes, line items and custom objects are all in. Associations, imports, exports, timeline events, forecasts, pipeline governance and property validations are not.

The read and write split matters too. HubSpot documents writes for contacts, companies, deals, tickets, leads, line items, products and custom object records. Every create or update through manage_crm_objects shows a proposed-changes summary and waits for explicit user confirmation. No delete action is documented anywhere on the page.

Outside the CRM, almost everything is closed

Of the 57 families outside the CRM group, 7 are reachable. All 4 automation families have no tool: Automation V4, Actions V4, Sequences and Email Templates. None of the 7 Commerce families has one either, and neither do Files, Forms, HubDB, webhooks, settings or audit logs.

Marketing email is the cleanest example. The server can create and update email drafts. No send tool is listed, and the single-send and transactional send APIs have no tool. A person still presses the button. That fits the commercial picture described in the breakdown of HubSpot's Breeze credit repricing, where the automation an outside agent cannot reach is the automation HubSpot sells.

The model context protocol coverage ratio, side by side

Put the three vendors in one table and the tool count stops predicting anything. Stripe has the fewest tools and arguably the widest documented reach into its core product. GitHub has six times as many tools and still leaves most of its delivery machinery out.

Denominators are each vendor's own grouping of its public API and are not comparable across vendors. Stripe's namespace ratio excludes its 79 top-level resource files, where most core payments objects sit and where coverage is far higher.

What stays outside the model context protocol, and why

Line up the gaps and a pattern appears that no single vendor's page shows. The surfaces with no agent access fall into four groups, and they are the same four at all three companies.

Automation stays inside the vendor's own product

None of the three lets an outside agent build or edit the vendor's own automation. HubSpot has no workflow tool. GitHub lets an agent trigger an Actions run but has no tool for runners, secrets or variables. Stripe lists webhook endpoints and stops there.

This is the part of the gap we read as strategic. Automation is the layer each vendor is now selling as its own agent product, and an open automation API would let a rival agent replace it. The wider version of that fight is laid out in the inventory of which SaaS incumbents opened the workflow.

Money, sending and administration stay behind a human

The second group is defensive rather than commercial. Stripe gates refunds and payouts behind a human approval link. HubSpot writes email drafts and sends nothing. Neither GitHub nor HubSpot exposes billing or settings at all.

These are the actions that end up in a support escalation or a lawsuit when an agent gets them wrong. Holding them back is the vendor managing its own liability, which is a reasonable thing to do. Just do not mistake it for a technical limit that a later release will remove.

Where this coverage count is weakest

This post makes a counting argument, so its weaknesses are counting weaknesses. Here they are, stated as plainly as the findings.

The denominators are the vendors' own groupings

A REST category at GitHub and an API family at HubSpot are not the same unit. HubSpot splits finely, so "Tasks Series" is its own family, while GitHub folds 17 subcategories into "orgs". That is why the table warns against comparing ratios across vendors. The ratio is most useful for tracking one vendor across releases.

The matching is also our judgement. We decided, for example, that GitHub's Copilot assignment tools do not cover the REST copilot category, which is about seat and policy management. A different reader could move 2 or 3 categories either way. That shifts GitHub between roughly 39% and 49%, and the conclusion does not change.

Stripe's generic tools may reach further than its list

Stripe's tool descriptions say "any" GET method and "any" write method. If that holds in practice, the real reach is close to the whole API, and the namespace ratio understates Stripe badly. We did not test unlisted methods against a live account, so we cannot say which reading is true.

We still treat the published list as the contract. A buyer cannot hold a vendor to behaviour it has not documented. If Stripe means "any", it should say so in the list.

Some of the gap is economics, not strategy

The strongest case against this post is that tool lists are small because models handle large tool lists badly. GitHub's own 50% token saving from merging one toolset shows the cost is real. A vendor exposing every endpoint as a tool would make its server worse for every agent that installed it.

That argument is right about tool count and wrong about coverage. Stripe proves a server can reach 152 methods through 2 tools without bloating the context. The choice not to reach a surface at all is a separate decision from how many tools to spend on it.

How to use the MCP server vs API ratio when you evaluate an agent

If you run delivery or operations, you are the one who finds the gap. In week three, the agent cannot do the step everyone assumed it could. The ratio exists to move that discovery to before the contract. These checks, which also slot into a wider AI agent procurement checklist, take an afternoon per vendor.

The fallback row is where most pilots fail quietly. When a step sits outside the MCP server, an agent vendor will often route it through a direct API integration instead. That works, but it brings back every credential, scope and audit question MCP was supposed to standardise. The cost of that route is examined in the analysis of legacy integrations and agent write access.

Our recommendation is blunt. If a required step is outside the official server and the agent vendor's answer is "we call the API directly", price that step as a custom integration, because that is what it is.

Frequently asked questions

Where to start

Pick the one workflow you most want an agent to run, and write its steps as verbs on objects: "create deal", "post check run", "send email". Then open the vendor's official MCP page and mark each step found or missing. If more than one step is missing, you have a custom integration project with an agent attached.

Then save the page. Tool lists change with every release and none of the three pages we read carries a revision date. A copy dated today is the only way to prove later what the vendor offered when you bought.

Related reading