Blog

Deep Dive

SEO MCP Tool Counts: We Audited Our Own 80-Tool Catalog

Our documented MCP catalog lists 80 tools, but browser OAuth exposes 25. See the breakdown, four placeholders, and how to evaluate access for a real SEO task.

By Abhi Bavishi, , 9 min read

RankParse's API-key MCP catalog lists 80 tools. Its browser OAuth connector exposes 25. Four entries in the larger catalog are documented placeholders.

Those numbers describe the same product. They explain why an SEO MCP comparison can look precise and still leave a buyer unable to answer a basic question: will this connection do the job I need?

We reviewed our own published tool tables to show what a headline count includes. This is a documentation audit, with a downloadable count sheet, rather than a runtime benchmark. The publisher is also the product being examined.

Reconstructing the 80-tool total

The following counts come from the category table in RankParse's MCP documentation, reviewed October 20, 2026. The CSV preserves the categories, endpoint availability, and source.

Documented groupToolsBrowser OAuthAPI key
Link graph and domain intelligence14YesYes
Live page and site checks5YesYes
Platforms2YesYes
Account and bulk lookups2YesYes
Websites and inbox proposals: reads2YesYes
Additional SEO tools, including placeholders5NoYes
Rank tracking7NoYes
Google Search Console18NoYes
Google Ads3NoYes
IndexNow2NoYes
Gmail outreach10NoYes
LinkedIn through Zeekeo5NoYes
Inbox actions5NoYes
Total802580

Download the dated catalog count sheet.

The first five groups sum to 25. The other eight sum to 55, so 55 of the 80 catalog entries are outside the browser OAuth connection. That is an access distinction, not a failure rate: the API-key endpoint serves a different set of workflows.

The documentation also identifies four placeholders: get_internal_links, get_link_velocity, get_new_links, and get_lost_links. They return not_yet_available. Subtracting them leaves 76 entries not labelled as placeholders. It does not establish that 76 tools will succeed for every account or every target. Unavailable endpoints

The missing denominator is the connection you will use

Suppose a content marketer uses Claude or ChatGPT in a browser and wants to know why an article lost clicks. The 18 Search Console tools in the broader catalog do not become available merely because the marketer connected browser OAuth.

The marketer needs either an approved performance export or the API-key endpoint with Search Console connected. Meanwhile, public page checks remain useful through the browser connection. The workflow crosses an access boundary that the number “80” conceals.

Now suppose an agency wants to identify links gained last week. The presence of get_new_links in a catalog is not sufficient: that entry is documented as a placeholder. Choosing a larger catalog has not supplied the missing historical comparison.

These examples point to a practical buying question: which required steps are executable through this exact endpoint, with this account's integrations?

Four questions to ask before comparing prices

Intended taskWhat the count cannot tell youEvidence to request
Review a public pageWhether the checker executes JavaScript or reads raw HTMLDocumented fetch and extraction behavior
Investigate lost clicksWhether this connection has access to the propertyEndpoint support, account authorization, and a dated report
Monitor newly acquired linksWhether historical comparison is implementedA supported response with the comparison periods
Send outreachWhether the tool is a draft operation or a sending actionRequired approvals, sending identity, and action semantics

A provider with fewer tools may satisfy all four requirements for your workflow. A provider with more may support useful adjacent work. Start by eliminating missing dependencies; then compare convenience, coverage, and price.

A callable tool can still return the wrong evidence for your claim

RankParse's backlink endpoint illustrates a second distinction. The default importance sort can return aggregated referrer rows. The recent sort returns URL-level records from the available snapshot. These support different statements. Backlink response behavior

An aggregated row can help identify a referring domain. It cannot substantiate a claim that a particular article currently contains a link. Even a URL-level snapshot record needs a live check if today's placement matters.

An evaluation should therefore record the source URL, dataset date where available, retrieval time, sample limit, and any partial response. A successful HTTP response is one check. An answer supported by the right evidence is another.

Visualize access and implementation separately

Two questions often get collapsed into one: does my connection expose this tool, and does the documented tool perform the operation? The catalog audit answers them using different evidence.

RankParse lists 80 API-key MCP tools. Browser OAuth exposes 25, or 31.25% of that catalog; 55 are API-only. Four of the API-only entries are documented placeholders.
Documentation audit, not a runtime benchmark. The four placeholders are part of the 55 API-only entries, not an extra group. Source and context. Download PNG.

Download the source notes and calculation inputs (CSV).

The browser subset is 25 of 80 entries, or 31.25% of the API-key catalog count. The remaining 55 entries are 68.75% of that count. These derived percentages describe catalog coverage only. They are not percentages of SEO work a browser agent can complete, because tools differ in scope and one task may need several tools.

The four placeholders belong to the additional SEO group outside the browser subset. Keep them visible in comparisons rather than silently treating them as completed features. Conversely, do not label every API-only entry “missing”: an API-key client may have access once its account and integrations are configured.

Map a real assignment before choosing a server

Consider an illustrative agency assignment: review a client's declining article and propose one next action. The analyst is responsible for the recommendation; the agent helps collect and organize evidence.

Start with a task map. The first step needs performance history. The second needs a current page inspection. The third may need documented product facts or a manual review of the article. The final deliverable must connect an observation to a decision without overstating the cause.

Traffic investigation task map: obtain performance history through connected Search Console or an export, inspect the current page, compare evidence scope and freshness, and review the recommendation. Browser OAuth lacks GSC tools.
Illustrative workflow using documented access boundaries; no live performance result is claimed. Source and context. Download PNG.

Write down the boundary at each step. Public page access is different from authorization to inspect a client's Search Console property. A successful connection to the MCP server does not imply that all third-party integrations are connected. A returned page title does not establish that the agent saw every rendered element.

This task map is also a useful way to compare products. Give each candidate the same required deliverable and record where you must supply an export, connect another service, or perform a manual check. A shorter setup may be worth paying for, but only when it produces the evidence you need.

Read errors as workflow information

Different failures call for different responses. A missing permission is not the same as a tool that has not been implemented, and neither is the same as a successful request with no matching records.

Response or observationWhat to establishAppropriate next step
Integration unavailableIs the required account connected and authorized?Complete the documented setup or supply an approved export
not_yet_availableIs this an explicitly documented placeholder?Choose another supported workflow; do not retry it as a transient failure
Empty resultDid the request succeed, and what filters or coverage limits apply?Preserve the empty result and inspect the request scope
Partial responseWhich requested fields or records are missing?Mark the deliverable incomplete where evidence is absent
Unexpectedly old observationWhat date does the underlying data represent?Perform a current check if the decision depends on today's state

These are interpretation categories, not a promise of identical error formats across providers. Use the specific server's documentation for exact response fields. Do not teach the agent to turn every failure into an empty success table: the reviewer needs to know which evidence was never collected.

Separate read operations from actions

An SEO workflow may begin with research and end with an external action, such as sending outreach. Treat that transition explicitly. The evidence needed to recommend a contact is different from the permission needed to send a message from a connected account.

For an evaluation, begin with a read-only deliverable. If sending is part of the intended workflow, test the documented approval path with an authorized test recipient and clearly defined content. Record which identity sends the message and what the human reviews before it leaves the system.

For RankParse, do not infer sending capability from browser OAuth: its documented tools are read-only. The API-key catalog includes integration-dependent actions, which need their own setup and authorization. A count of tools does not communicate these consequences to a user; the workflow should.

Keep a purchasing worksheet based on finished work

Use one row per required task rather than one row per advertised feature. Useful columns include endpoint, required integration, evidence returned, unresolved gaps, human review needed, billable calls, and outcome. Leave a field unknown when the trial did not establish it.

For the declining-article assignment, “connected successfully” is a setup observation. “Returned comparable page and query data, a current page check, and a reviewable next-step table” is a task outcome. Compare the latter when deciding whether the tool belongs in your process.

Do not turn a small trial into a universal success rate. A tool may behave differently on another property, content type, or account configuration. Describe the tested inputs and limitations so another reviewer can repeat the evaluation and understand where the conclusion applies.

A reusable acceptance test

Before paying for an expanded plan, choose one task with a concrete deliverable. For example: identify candidate referring domains for an editorial outreach review, retaining evidence for each candidate.

Ask the agent to return a table with the candidate, the supporting observation, the date or freshness limitation, and the next manual check. Record which requested fields are actually present. Leave missing values explicit.

Then repeat with the same inputs on another connection. Keep client/model settings, account access, task wording, retries, and billable calls in the run notes. Compare the finished deliverables before comparing the number of tool definitions.

Our MCP pricing guide covers the costs to record. The MCP versus browsing guide explains when source-page inspection still belongs in the workflow.

The useful purchasing unit is a completed, verifiable task. A catalog total becomes informative only after you know which entries your connection exposes, which are implemented, and which provide the evidence that task needs.

Method: sum the 13 documented category rows, sum the five OAuth-supported groups separately, and identify the four explicitly labelled placeholders. Counts describe documentation reviewed October 20, 2026; no tool execution success rate was measured.

Keep reading

Start free

Let your agent take the first pass.

100 free credits. No card. No seats.