Scan websites for AI visibility and marketing health with interactive dashboard.
Scored across 5 tools
scan_website is the core scan, compare_scan handles competitor side-by-side, refresh_scan re-runs with updated parameters, and get_score_breakdown drills into a dimension—each has a distinguishable purpose. Some overlap exists between scan_website/compare_scan/refresh_scan (all scan-domain), but outputs differ enough to guide selection.
All tools use snake_case with a verb_noun structure (compare_scan, refresh_scan, scan_website, submit_lead), which is consistent and predictable. get_score_breakdown is a slightly longer/compound name but still fits the same pattern.
Five tools is a tight, well-scoped set for a website-scanning service and each earns its place. It leans slightly thin, with no scan-listing or history retrieval tool, but not problematically so.
The scan lifecycle (scan, compare, refresh, breakdown) and lead capture are covered, but there is no way to list or retrieve previously saved scans, and no delete/history management. These gaps are workable but represent missing operations an agent might expect.
Scan a competitor and return side-by-side comparison
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| max_pages | No | ||
| competitor_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about crawling, cost, latency, authentication, or rate limits. The existence of a max_pages control strongly implies a multi-page crawl, but the description never acknowledges or bounds that behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler, which is structurally fine, but at this brevity it is under-specified rather than concise — nothing about inputs or behavior is front-loaded because nothing is stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with 0% schema coverage, no annotations, and no output schema, the description is far too thin. Missing: which parameter is the target vs competitor, what the comparison contains, and how max_pages bounds the scan.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all 3 parameters. The description implies a competitor URL but never names or maps url vs competitor_url, and it gives no meaning to max_pages (default 3, max 10), which is the one parameter whose effect is non-obvious. It does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Scan a competitor and return side-by-side comparison" gives a verb (scan) and the deliverable (comparison), but it's ambiguous about what is being compared with what — the two required URI params (url and competitor_url) are never referenced, so the agent can't tell which is the subject. It also fails to distinguish itself from the sibling scan_website, which sounds nearly identical in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no statement of when to prefer this over scan_website or refresh_scan, and no mention of prerequisites. The agent must infer the comparison workflow entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed line-item breakdown for a score dimension
| Name | Required | Description | Default |
|---|---|---|---|
| checks | Yes | ||
| dimension | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It says 'get detailed line-item breakdown,' which implies a read operation, but it does not confirm side effects, authorization requirements, or what a 'line-item' actually consists of. The term 'detailed' is vague and does not explain the return structure or any potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, front-loading the core purpose. It is appropriately sized, but given the lack of other context, it could earn its place better by including a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain what the tool returns, but it does not. The 'checks' parameter is undefined, and the description does not clarify how the dimension enum affects the breakdown. This is insufficient for an agent to invoke the tool correctly without additional implicit knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage. The description mentions 'score dimension,' which maps to the 'dimension' parameter, but it does not explain the 'checks' parameter at all. Given the low schema coverage, the description must compensate for both parameters, and it fails to do so fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' and identifies a clear resource: a detailed line-item breakdown for a score dimension. This distinguishes it from sibling tools like compare_scan, refresh_scan, scan_website, and submit_lead, none of which perform a similar breakdown function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or how it relates to alternatives. There are no mentions of exclusions, prerequisites, or scenarios where this tool should be preferred over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-scan with updated parameters
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| max_pages | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and delivers none of it. It does not say whether the re-scan creates a new scan record, overwrites prior results, preserves history, requires ownership of the original scan, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single fragment is short but that is under-specification rather than conciseness; there is no front-loaded statement of effect or return. Nothing beyond the name is communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation-style tool with no annotations, no output schema, and an undocumented schema, this description is completely inadequate. An agent cannot safely decide when to call it or predict its effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so neither the url nor max_pages parameter is documented anywhere. The phrase "updated parameters" adds no meaning about which parameters can be changed, whether url must match the original scan, or how max_pages bounds the crawl.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Re-scan" is a verb echoing the tool name refresh_scan, and "with updated parameters" restates the existence of inputs rather than describing the operation. It does not distinguish this from the sibling scan_website or explain what a refresh actually produces versus a fresh scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no condition that selects refresh_scan over scan_website, and no exclusion for when a re-scan is inappropriate. The agent is left to guess entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan any website for AI visibility and marketing health. Returns scores for GEO (Generative Engine Optimization), Multimodal readiness, Agent-Ready infrastructure, and 6-dimension Marketing Health. Identifies critical findings with prioritized fix recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website URL to scan (e.g. https://example.com) | |
| industry | No | Industry vertical for context | general |
| max_pages | No | Maximum subpages to scan (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuine value beyond that by enumerating the return content (GEO, Multimodal readiness, Agent-Ready infrastructure, 6-dimension Marketing Health, prioritized findings) – meaningful disclosure given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first front-loads purpose, the second enumerates outputs. No filler, no repetition of the name, and the size is proportionate to a single-purpose scan tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully summarizes the return shape, and annotations cover the safety profile, so an agent has enough to invoke correctly. The missing piece is usage context – when this is preferred over refresh_scan or compare_scan – which is not addressed anywhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have full schema descriptions (100% coverage), so the schema carries the semantics. The description adds no information about url, industry, or max_pages behavior, which is the expected baseline when the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb and resource ("Scan any website") plus the domain of analysis (AI visibility and marketing health), so an agent knows exactly what it does. However, it does not differentiate itself from siblings like refresh_scan or compare_scan, leaving the agent to infer the boundary from naming alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says "any website," which is broad but gives no when-to-use conditions, no prerequisites (auth, rate limits, scan duration), and never mentions the alternatives. With refresh_scan and compare_scan as siblings, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a lead for service booking
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| tier | Yes | ||
| Yes | |||
| company | No | ||
| scan_url | Yes | ||
| findings_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. "Submit" implies a write/mutation with external side effects, but the description says nothing about persistence, permissions, duplicates, or confirmation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single short sentence is not concise so much as under-specified; it omits nearly everything an agent needs while spending words on the vague phrase "for service booking".
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no annotations, no output schema, and 0% schema documentation, the description is far too thin. An agent has no basis for supplying valid arguments or understanding the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 6 parameters (4 required), and the description adds no meaning for any of them. Key fields like tier (enum), scan_url, and findings_count are left entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ("Submit a lead"), so an agent can grasp the basic action. However, "for service booking" is vague and there is no differentiation from siblings like scan_website or get_score_breakdown, nor any indication of what a 'lead' comprises here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool versus alternatives, no prerequisites, and no mention of the relationship to the sibling scan tools. Usage must be entirely inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_scan2 fields changedInput schema / properties / competitor_url / maxLengthAdded value: +2048Input schema / properties / url / maxLengthAdded value: +2048refresh_scan1 field changedInput schema / properties / url / maxLengthAdded value: +2048scan_website1 field changedInput schema / properties / url / maxLengthAdded value: +2048submit_lead1 field changedInput schema / properties / scan_url / maxLengthAdded value: +2048compare_scanget_score_breakdownrefresh_scanscan_websitesubmit_leadAI visibility for your brand: scores, competitors, prompts, site health and articles.
Public website health scan, AI-crawler and structured-data readiness, and a local presence score.
Scan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
Scan any website's AI readiness: AI search visibility and AI agent usability. Free, no auth.
Add one secure layer between your agents and this server.
