Skip to main content
Glama

Get the entity rule findings

get_entity_findings
Read-only

Get the schema/entity-* rule verdicts for an audit: what is wrong with the site's entity graph, which entity keys and pages each finding affects, and the fix text for each. Use this instead of re-deriving the problems from the graph yourself. Each finding names one problem across the whole site rather than one per entity, so a count of 1 can still mean hundreds of pages. The keys and pages on a finding are a SAMPLE: the rule that produced it clipped its own lists before this tool saw them, so the pages listed are never the complete affected set and no field reports how many were left out. Use list_entities with the matching problem filter for the full set. analyzed says whether the rules ran at all: false means this audit was never analyzed, so empty findings are an absence of evidence rather than a clean result. 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
run_idNoA specific audit run to read. Defaults to the latest audit that stored at least one entity, which is NOT always the latest audit: an audit that stored none is passed over, because the store cannot tell a site that declares nothing from an audit that predates the entity map. When one is passed over, warnings names it. If you are checking whether a change landed, name the run.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +{}
  2. Changed2 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
  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 read-only safety, yet the description adds unusually rich behavior: findings aggregate one problem site-wide (so count 1 can mean hundreds of pages), the keys/pages lists are a SAMPLE clipped before this tool saw them with no total reported, and 'analyzed: false' means empty findings are absence of evidence, not a clean result. These are non-obvious interpretation rules an agent cannot get from annotations.

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 purpose and then dense with non-obvious semantics, so most sentences earn their place. However, the extended fix-and-verify loop spans several sibling tools and pushes length well beyond what is strictly needed to select and invoke this tool.

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?

For a tool with no output schema, the description fully covers the return semantics (findings structure, sample/clipping caveat, analyzed flag, coverage field values 'proven'/'partial') plus how to confirm a fix landed via gainedId. Nothing an agent needs to interpret the results correctly is 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 description coverage is 100% and both parameters are thoroughly documented in the schema itself (run_id defaulting behavior, website_id being ignored by the local server, run_id precedence). The description adds workflow context around run_id but no new syntax or format detail, so the schema carries the load — baseline 3.

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 specific verb and resource ('Get the schema/entity-* rule verdicts for an audit') and enumerates exactly what each finding contains: the problem, the affected keys/pages, and the fix text. It explicitly distinguishes this from re-deriving problems from the graph and points to list_entities as the sibling for the full set.

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 explicit routing: 'Use this instead of re-deriving the problems from the graph yourself' and 'Use list_entities with the matching problem filter for the full set.' It also lays out the full fix-and-verify loop (list_entities, run_audit, compare_entities) with the exact condition that selects each step.

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.