Skip to main content
Glama

Compare two audits' entities

compare_entities
Read-only

Compare two audits of a site and get the change set: entities added and removed, entities that gained or lost an @id, occurrence changes, new and resolved conflicts and dangling references, summary deltas, and the pages each audit saw that the other did not. Defaults to the previous audit versus the latest. An entity is only reported as removed when every page that declared it was crawled again; anything unproven is reported separately as not crawled, so a smaller crawl never reads as a site that deleted its structured data. Each gainedId and lostId entry carries a coverage field saying whether the newer audit visited every page that declared the old version and found the replacement there. Absence of a gainedId entry is not proof a fix failed: the match needs the type and the name to be unchanged, so changing the @id and the name in one edit appears as a removal plus an addition instead. Fix-and-verify loop: call list_entities with problem="no-id" to find entities declared on several pages with nothing to tie them together, give each one an absolute @id, re-run the audit with run_audit, then call compare_entities and check that gainedId contains the keys you fixed. gainedId is the only confirmation that the fix landed: an entity that gained an @id changes key, so it would otherwise look like one removal plus one addition. Check each entry's coverage field before calling it done: "proven" means the newer audit visited every page that declared the broken version AND found the replacement on all of them, "partial" means one of those could not be established.

Input Schema

NameRequiredDescriptionDefault
to_run_idNoThe newer audit. Defaults to the latest audit that stored at least one entity. When both runs are named they are ordered chronologically whichever field named them.
website_idNoThe registered website to read, on the hosted server. Ignored by the local server, which reads the project store. When both this and run_id are given, run_id wins and this is ignored; naming a run of a different website is answered about the run.
from_run_idNoThe older audit. Defaults to the one before the newer audit, for the same site. When both runs are named they are ordered chronologically whichever field named them, so a diff always reads forward in time; read fromRunId and toRunId on the result for the direction actually used.
occurrence_thresholdNoSmallest occurrence change worth reporting. Default 1, meaning every change. Raise it on a site that publishes constantly, where a site-wide entity moves by one on every audit and would otherwise fill the change set with noise. Affects occurrenceDeltas only: entities added, removed, or changing their @id are reported whatever this is set to.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +{}
  2. Changed3 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / occurrence_threshold / maximum
      Added value: +9007199254740991
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already establish a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description goes well beyond them: it explains the conservative removal rule ('only reported as removed when every page that declared it was crawled again'), the meaning of the coverage field ('proven' vs 'partial'), and the key-change pitfall where an @id fix appears as a removal plus an addition.

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-loaded with the change-set contents and mostly dense with real behavioral information, but the coverage field is explained twice (mid-paragraph and again in the closing sentence about 'proven'/'partial'), which is avoidable repetition.

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

Completeness5/5

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

With no output schema, the description carries the full burden of explaining the return shape, and it does: change-set sections, coverage semantics, direction fields, and the occurrenceDeltas scope. For a 4-parameter diff tool this leaves nothing an agent needs missing.

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 the schema itself already documents defaults, ordering, website_id precedence, and the occurrence_threshold noise guidance, so the description adds little new semantics for the parameters. Baseline 3 is appropriate where the schema does the heavy lifting.

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 precise verb and resource ('Compare two audits of a site and get the change set') and then enumerates the exact entity-level outputs it produces (added/removed entities, gainedId/lostId, occurrence deltas, conflicts, dangling refs, page coverage). That entity-level granularity makes it unmistakable from the sibling compare_audits, which works at audit level, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit when-to-use workflow: call list_entities with problem="no-id", assign absolute @ids, re-run with run_audit, then call compare_entities and verify gainedId. It also names the default direction (previous vs latest) and warns where gainedId absence is not proof of failure, so both the trigger and the non-trigger are covered.

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.