Exepal

SEO report (Semrush-style, for founders)

seo_report

Read-onlyIdempotent

SEO report for one website: estimated Google traffic and keywords, 12-month trend, top 100 keywords, quick wins, competitors, top pages, on-page problems with fix prompts and a plain-language summary. Use when a founder or marketer asks how a site is doing on Google, what it ranks for, who its search competitors are or what to fix next. Data from DataForSEO (estimates, one country per call). Returns strength 0-100, overview {traffic, keywords, trafficValueUsd, positions {top3, top10, top20, top30, top100}, newKeywords, lostKeywords}, history[] by month, topKeywords[] and quickWins[] {keyword, position, volume, difficulty, cpc, intent, url, traffic}, competitors[], topPages[], health {score, problems, items[] with fix prompts}, summary and actions[]. Not charged when the data source fails. Price: $0.50 per call from Exepal credit; not charged if the call fails.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "seo_report"
  }
}

Input Schema

Name	Required	Description	Default
`domain`	Yes	Website, e.g. notion.com (subdomains count as the same site only when you pass them)
`country`	No	Two-letter country for Google data: us (default), gb, ca, au, nz, ie, in, sg, ae, za, ph, pk, np, de, fr, es, it, nl, br, mx, jp

Output Schema

Name	Required	Description
`kind`	No	report
`domain`	No
`health`	No	On-page checks of the home page
`actions`	No	Next steps, most valuable first
`country`	No
`history`	No	Up to 12 months
`summary`	No	Plain-language summary
`language`	No
`overview`	No
`strength`	No	0-100 SEO strength, log scale
`topPages`	No
`quickWins`	No	Keywords on positions 4-20 with real volume
`competitors`	No
`generatedAt`	No	ISO 8601
`topKeywords`	No	Top keywords by traffic

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and idempotency, and the description adds material context beyond them: the upstream data source is DataForSEO with estimates, only one country per call, and the price is $0.50 per call with no charge when the data source or the call fails. Cost and estimate-quality caveats are exactly the behavioral details an agent needs before invoking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and usage sentences are front-loaded and waste-free, but the third sentence is a long dump of return fields (overview, history, topKeywords, quickWins, competitors, topPages, health, summary, actions) that duplicates the output schema. That block adds length without adding decision-relevant value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, read-only report tool with an output schema, the description covers the important unknowns: data source, estimate nature, single-country limitation, and pricing/failure billing. Return values are already in the output schema, so those are covered. Only data freshness and rough response-time expectations are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'domain' and 'country' are already documented in the input schema, including the subdomain caveat and the country enumeration. The description only reinforces the 'one country per call' limit. With the schema doing the heavy lifting, the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete verb+resource ('SEO report for one website') and enumerates what the report contains (traffic, 12-month trend, top keywords, competitors, top pages, on-page problems). That gives an agent a clear picture of scope. It does not explicitly distinguish itself from the related siblings seo_rank, seo_keywords and seo_gap, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names concrete triggers: 'Use when a founder or marketer asks how a site is doing on Google, what it ranks for, who its search competitors are or what to fix next.' That is a clear when-to-use statement tied to real user intents. It never states when NOT to use it or which narrower sibling to pick for keyword research or rank checks instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Exepal tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?