Skip to main content
Glama

Compare two sites

mttr_compare
Read-only

Two sites already read, rule by rule: the scores and stages side by side, and the rules each is ahead or behind on by the share of its pages passing. With view "content", their content by meaning instead: their pages measured, page pairs both write about with words on each, and what only one of them writes about. Page titles come under "quoted".

Input Schema

NameRequiredDescriptionDefault
siteYesThe site, as a domain such as example.com.
viewNorules (the default) or content.
withYesThe other site, as a domain already read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds the meaningful prerequisite that both sites must be already read/crawled. It also outlines the return shape (scores, stages, rule pass-shares, page pairs with words on each, quoted titles), which is valuable 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.

Conciseness4/5

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

Front-loads the primary rules comparison, then presents the content view as the alternative, with zero redundant repetition. The phrasing is idiosyncratic ('by the share of its pages passing', 'come under quoted') and dense, slightly taxing readability.

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?

Given a read-only, 3-parameter tool with full schema coverage and no output schema, the description covers the prerequisite and sketches return contents sufficiently. Only sibling-selection guidance and the meaning of 'quoted' are left thinly explained.

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% and documents site, with, and the view enum, so the baseline is 3. The description does add meaning for the 'content' view's outputs, but it doesn't clarify the domain format or the 'rules' view's per-rule detail 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 comparison of two sites side by side on scores, stages, and rules ahead/behind, plus a content-by-meaning mode. The resource and action are clear, though it never names sibling comparison tools (mttr_competitors, mttr_similar) to differentiate itself.

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?

Explains the 'content' view as an alternative to the default 'rules' view and notes both sites must be 'already read'. However, it gives no guidance on when to pick this over mttr_competitors/mttr_similar or when-not to use it, leaving comparison-tool selection to inference.

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.

Resources