Skip to main content
Glama
Sign In
webscout-mcp

webscout-mcp

by wxs-lang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

web_compare_sites

Compare multiple website URLs side by side to benchmark SEO, performance, content, and links, then receive ranked metrics and prioritized recommendations.

Instructions

Compare several websites side by side on SEO, performance, content and links.

Fetches each URL, computes metrics, and returns a ranked comparison with a per-metric matrix and prioritised recommendations. Use this to benchmark a page against competitors, or to check whether your own pages regress.

Scores are 0-100 per axis and a weighted overall. Comparisons are only as good as the markup available to a plain HTTP fetch: a JavaScript-rendered page may look thin even when it is not, and that will be visible as a low content score.

A URL that cannot be fetched is reported as an entry with an error and its recovery reason, rather than failing the whole comparison.

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": {
      "urls": "<urls>"
    },
    "name": "web_compare_sites"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlsYes
namesNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.4.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does much of it: it discloses the fetch-and-compute pipeline, 0-100 per-axis plus weighted overall scoring, the plain-HTTP limitation for JS-rendered pages, and partial-failure semantics where an unfetchable URL yields an `error` entry instead of failing the call. It omits cost/latency expectations for fetching multiple URLs and any rate or auth considerations.

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

Conciseness4/5

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

What the tool does and what it returns is front-loaded in the first paragraph, with caveats (JS rendering, per-URL errors) following in order of importance. Every sentence carries information, though the metric/scoring detail is slightly padded across two paragraphs.

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

Completeness3/5

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

An output schema exists, so return structure needn't be spelled out, and behavioral edge cases are well covered. The remaining hole is input-side: the `names` parameter is entirely unexplained and there is no guidance on how many URLs a comparison expects, which matters for a fan-out tool.

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

Parameters2/5

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

Schema description coverage is 0% for two parameters, yet the description never mentions `urls` or `names`. It gives no minimum URL count, no indication of what `names` is for, and no note that names align positionally with urls — meaning the undocumented schema is not compensated for.

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

Purpose5/5

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

States a concrete verb and resource ('Compare several websites side by side') plus the exact axes compared (SEO, performance, content, links) and the return shape (ranked comparison, per-metric matrix, recommendations). This is clearly distinguishable from single-page siblings like web_fetch or web_extract.

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?

Gives two explicit use cases: benchmarking a page against competitors and checking for regressions on your own pages. It stops short of naming alternatives (e.g. use web_fetch for a single URL) or stating when not to reach for it, so it stays at a clear-context-but-no-exclusions level.

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

Deploy Server

Other Tools