Skip to main content
Glama

Compare URLs

compare
Read-onlyIdempotent

Compare 2-5 URLs side by side with a structured diff: each URL's score and category breakdown plus who is ahead and by how much, per category and per URL pair. Requires Basic plan ($15/mo) or higher.

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": "compare"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlsYes2 to 5 URLs.

Output Schema

NameRequiredDescriptionDefault
diffNoWho leads, per category and per pair.
resultsNoEach URL's score and categories.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds a genuinely non-obvious gating constraint — a Basic plan ($15/mo) subscription is required — which annotations and schema cannot convey.

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

Conciseness5/5

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

Two sentences with zero waste: output shape is front-loaded, followed by the access prerequisite. Nothing is repeated verbatim from the schema beyond a needed reinforcement of the URL count.

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?

An output schema exists, so return values need no prose, and annotations cover safety. The plan requirement fills the main non-obvious gap; only minor details (e.g. whether duplicate or same-domain URLs are allowed) are absent, which for a one-parameter read tool is acceptable.

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 coverage is 100% for the single 'urls' parameter, including minItems 2 and maxItems 5, so the schema carries the semantics. The description restates the 2-5 range and the URI expectation but adds no format, ordering, or duplication rules beyond the schema.

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?

States a specific verb and resource ('Compare 2-5 URLs side by side') and specifies what the output contains: score, category breakdown, and per-category/per-pair deltas. It is clear on its own, but does not name or distinguish itself from near-neighbors such as competitive_audit or batch_audit.

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

Usage Guidelines3/5

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

The 'side by side' framing implies the comparative use case, and the 2-5 URL range is stated, but there is no explicit when-to-use/when-not-to-use guidance and no pointer to an alternative for single-URL or bulk scenarios.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.