Skip to main content
Glama

List declared entities

list_entities
Read-only

List the entities a site declares in its JSON-LD, collapsed across every crawled page into one graph, so an Organization declared identically on 60 pages is one row rather than 60. Declarations collapse by resolved @id, or by type and name when there is no @id, so the SAME real-world thing can still occupy several rows when its declared identity differs between pages: a relative @id such as "#organization" resolves against each page and yields one row per page. That is the split-identity problem, not a quirk of this tool. Filter by @type, by declaring page, by problem class, or by a text match on the name. Page-local entities (a page's own WebPage, BreadcrumbList and unnamed images) usually outnumber the site's actual subject matter and are hidden unless include_page_local is true. Returns a filtered summary, a page of nodes, total, and hasMore; keep requesting pages while hasMore is true rather than describing a site from one page. 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
qNoOnly entities whose name or @id contains this text. Case-insensitive substring, not a pattern.
pageNoOnly entities declared on a page whose URL CONTAINS one of these strings. Not a prefix test and not a glob, so "/blog" matches https://example.com/blog/post and https://example.com/tag/blog alike. Several values are an OR.
typeNoOnly entities carrying one of these @type values. Case-insensitive. Several values are an OR: an entity matching any one of them is kept.
limitNoEntities to return. Default 25, maximum 100.
offsetNoEntities to skip, for paging through a result larger than limit. Default 0. Ordering is by page count descending, then by key, and is stable across calls on one audit, so paging does not repeat or skip a row.
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.
problemNoOnly entities with one of these problems: no-id, conflict, dangling, single-page, split-identity. Several values are an OR.
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.
include_page_localNoInclude entities that describe one page rather than the site's subject matter, such as a page's own WebPage or BreadcrumbList. False by default because they usually outnumber everything else.

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 only declare readOnlyHint=true and destructiveHint=false, which are baseline. The description adds substantial behavioral context: the collapse by resolved @id or by type/name, the split-identity problem, the pagination contract (hasMore), the run_id default behavior (latest audit that stored at least one entity), and the meaning of the 'coverage' field ('proven' vs 'partial'). It also explains the gainedId confirmation in compare_entities. This goes far beyond what annotations provide.

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 densely packed with necessary information. It is front-loaded with the core purpose and collapsing behavior, then expands into filtering, pagination, and the fix-and-verify loop. While every sentence earns its place, it could be slightly more structured with bullet points or paragraphs, but given the complexity it remains appropriately sized.

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 9 parameters, no output schema, and many behavioral subtleties, the description covers the essential aspects: the collapsing rule, split-identity problem, filtering options, pagination, run_id defaulting, include_page_local, and the fix-and-verify workflow including the interpretation of coverage. It also mentions the return shape (filtered summary, page of nodes, total, hasMore). Nothing an agent needs to call this correctly 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 extra semantic context beyond the schema: it explains the filtering options in plain terms (filter by @type, page, problem, name), the include_page_local rationale, and the nuance of run_id (that it defaults to the latest audit that stored entities, not necessarily the latest audit). It also clarifies the meaning of the problem enum values indirectly through the workflow. These enrich the schema descriptions.

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 clearly states the verb 'List' and the resource 'entities a site declares in its JSON-LD', and immediately clarifies the collapsing behavior across pages. It distinguishes itself from siblings like get_entity (which likely retrieves a single entity) and compare_entities by its aggregation scope. The mention of split-identity further disambiguates it from a naive list.

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 guidance on when to use this tool: in the fix-and-verify loop it says 'call list_entities with problem="no-id"' and then follow with run_audit and compare_entities. It also warns against relying on a single page by instructing to 'keep requesting pages while hasMore is true'. It explicitly names alternatives and the workflow sequence, leaving no ambiguity.

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.