Skip to main content
Glama

Get one declared entity

get_entity
Read-only

Get one entity as the map recorded it: the properties the map keeps (name, url, logo, image, sameAs, telephone, email, address, description), the pages that declare it, the properties whose values disagree between those pages, and the references in and out of it. The map keeps those nine and @type and nothing else, so a property missing here may still be in the page's JSON-LD, and a disagreement in a property outside that set is not detected. Accepts the entity key, its @id, or its name. Use this after list_entities to see why an entity was flagged, before deciding what to change. Edges and declaring pages are capped; the counts tell you when. 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

TableJSON Schema
NameRequiredDescriptionDefault
keyYesThe entity key, its @id, or its name. Resolved in that order of certainty: an exact @id match, then an exact key match, then the key formed by prefixing the value with "id:", then an exact case-insensitive name, and only then a case-insensitive substring of a name. The first match wins.
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. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: the map keeps only nine properties plus @type, so missing properties may still exist in page JSON-LD; disagreements outside that set are not detected; edges and declaring pages are capped with counts indicating truncation; run_id resolution skips audits that stored no entities; and gainedId is the only confirmation that a fix landed. This is rich, non-obvious behavior disclosed clearly.

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?

The description is long but every sentence earns its place: the first sentence defines the return shape, the second explains the nine-property limitation, the third gives usage context, and the rest covers caps, run_id semantics, and the fix-and-verify loop. It is front-loaded with the core purpose and progressively adds operational detail. Slightly dense, but not padded.

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 read-only lookup tool with 100% schema coverage and no output schema, the description covers what the agent needs: what is returned, what is not returned, how key resolution works, how run_id defaults, how caps are signaled, and how to confirm a fix landed. The fix-and-verify loop even ties it to sibling tools. Nothing critical is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the resolution order for key ('exact @id match, then exact key match, then id: prefix, then case-insensitive name, then substring') and by clarifying run_id's default behavior (latest audit that stored at least one entity, not necessarily the latest audit). It also explains website_id's local-vs-hosted behavior and precedence. This goes beyond the schema, so a 4 is warranted.

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?

The description opens with a specific verb and resource ('Get one entity as the map recorded it') and enumerates exactly what the returned entity includes: the nine kept properties, declaring pages, disagreements, and references. It also distinguishes itself from siblings by naming list_entities, compare_entities, and get_entity_findings/get_entity_graph implicitly through scope. This is a clear, specific purpose statement.

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?

The description gives explicit when-to-use guidance: 'Use this after list_entities to see why an entity was flagged, before deciding what to change.' It also provides a full fix-and-verify loop naming list_entities, run_audit, and compare_entities, and explains when to pass run_id ('If you are checking whether a change landed, name the run'). This is exemplary usage guidance.

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.