Skip to main content
Glama

Check the entity graph for AI

check_entity_graph
Read-onlyIdempotent

Check how a page's structured data describes who and what it is about, the way AI knowledge graphs read it: which entities there are (Organization, Person, Article, Product), whether they link to each other by @id, whether author and publisher are real entities instead of plain text, whether sameAs points to real profiles (LinkedIn, Wikipedia, Wikidata, social) and whether those profile links load, and whether the Organization matches the one on the home page. Returns the graph, issues with stable codes and a suggested JSON-LD block with TODOs for details only the user knows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesFull address, for example https://example.com/blog/post. A bare domain also works.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
linksYes
issuesYes
entitiesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds significant behavioral context beyond that: it lists the specific checks performed (entity presence, @id linking, sameAs targets loading, homepage consistency) and states it returns the graph, issues with stable codes, and a suggested JSON-LD block with TODOs. This is highly informative about the output and process.

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?

It is essentially one long sentence detailing the checks, followed by a second sentence on return values. It is front-loaded with the core purpose, but the enumeration is dense and could be slightly more structured for readability. However, every clause adds value.

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 analysis tool with a rich output schema, the description is complete: it covers what is checked, how it relates to AI knowledge graphs, and what is returned (graph, issues, suggested block). No critical information is missing for an agent to call it correctly.

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 the single 'url' parameter is well-documented in the schema. The description doesn't add format details for the parameter, so baseline 3 is appropriate.

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 states a specific verb and resource ('Check how a page's structured data describes who and what it is about') and then enumerates exactly what is examined: entities, @id linking, author/publisher as entities, sameAs profile targets, and Organization matching. This is highly specific and clearly distinguishes it from siblings like validate_schema (validation) or generate_schema (creation).

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?

It doesn't explicitly say when to use this tool versus alternatives like validate_schema or generate_schema. The 'the way AI knowledge graphs read it' framing implies an AI-visibility use case, but no when-to-use or when-not-to-use guidance is provided.

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.