Wikidata + Google Knowledge Graph MCP

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

With readOnlyHint/idempotentHint already provided, the description still adds substantive behavioral context beyond annotations: 'Google crosscheck is disabled remotely' (disabling an input flag), 'Provider agreement is not local identity proof' (semantic caveat), and what is withheld ('Public prose, aliases, external links and media'). It does not contradict any annotation. Slightly less than 5 because the output shape remains vague and 'canonical audit' is left undefined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Six short sentences are front-loaded with a purpose statement, which is good, but several are cryptic fragments whose meaning cannot be recovered (e.g., 'bounded direct-record admission without recursive content certification' and 'identity evidence and uncertainty remain separate'). The structure is fine but the content is not earning its place.

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

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

There is no output schema, so the description takes partial credit for naming what is returned (contradictions, evidence, uncertainty) and stating withholding policy. However, with zero parameter documentation, an undefined envelope type, and no sibling differentiation, an agent still lacks enough to invoke this tool correctly.

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

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

Schema description coverage is 0% across four parameters, including a free-form nested 'envelope' object and three options (refresh, max_candidates, google_crosscheck) that have no prose meaning. The description never mentions any parameter by name, explains what an envelope must contain, or clarifies what refresh or google_crosscheck actually do, so it fails to compensate for the total schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Canonical audit of one existing Wikidata QID against one local identity envelope') and mentions an output ('returns contradictions, evidence and uncertainty'), so the purpose is intelligible. But it is not differentiated from siblings like kg_discover_identity or kg_resolve, and jargon like 'local identity envelope' is never defined, leaving the agent unsure what this tool actually produces.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. Sibling tools kg_discover_identity, kg_resolve, and kg_entity exist and are never referenced, so the agent gets no help choosing among them. The line 'New entities use bounded direct-record admission' gestures at a boundary but does not name the tool that handles new entities.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is pre-met; the description adds real behavioral context on top: it returns ambiguity and insufficient-evidence states, sameAs candidates are unapproved, Google crosscheck is disabled remotely, and public prose/aliases/external links/media are withheld. These are non-obvious outcome and withholding behaviors an agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, which is good, but the remainder is a seven-sentence wall of compressed jargon ('bounded direct-record admission without recursive content certification') whose clauses are hard to parse and unevenly weighted relative to their importance to an agent.

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

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

With no output schema, the description does some of the return-value work (ambiguity, insufficient-evidence states, withheld fields), but the required nested 'envelope' parameter is entirely unspecified and the dense internal terminology leaves an agent unsure what to pass or what a successful result looks like.

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

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

Schema description coverage is 0%, so the description carries the burden and only partially delivers: it covers max_candidates ('Default 3, maximum 5'), gestures at google_crosscheck ('disabled remotely'), and implies the envelope is local evidence, but says nothing about refresh and gives no format for the envelope object despite it being the sole required nested parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Canonical discovery of one identity from a local evidence envelope', which tells the agent this returns a single identity rather than a list. However, the vocabulary ('canonical', 'evidence envelope') is obscure and the description never distinguishes this from siblings like kg_resolve or kg_lookup_entities, so sibling differentiation rests on the name alone.

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

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

There is no statement of when to use this tool versus kg_resolve, kg_lookup_entities, kg_search, or kg_entity, all of which plausibly overlap with identity discovery. The only directive content (default 3, maximum 5 candidates) is a parameter constraint, not usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds substantive context: prose, aliases, URLs, media and references are withheld, admission is 'bounded direct-record', and identity evidence/uncertainty stay separate. That is real behavioral disclosure beyond the structured fields, even if cryptically worded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is jargon-dense and self-repeating: 'prose, aliases, URLs, media and references are withheld' is restated as 'Public prose, aliases, external links and media are withheld'. Four sentences where two would do, and none are front-loaded around what the tool returns.

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

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

With no output schema, four parameters at 0% schema coverage, and a non-obvious tool name, the description should carry the load but does not explain parameter meaning or return shape. It is incomplete for an agent that needs to construct a correct call.

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

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

Schema description coverage is 0% and the description explains none of the four parameters. The clause about 'identity evidence and uncertainty remain separate' loosely gestures at the evidence param, but id, lang, and props (with its maxItems limits) are left entirely undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The phrase 'Bounded structured facts for one Wikidata QID' names a resource and scope, so an agent can infer this retrieves entity facts by QID. But it lacks a clear verb (retrieve/read) and never contrasts itself with close siblings like kg_lookup_entities or kg_search, leaving differentiation to inference.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as kg_lookup_entities or kg_search. The only quasi-guidance is an implicit 'for one QID' scoping, which is not enough to route the agent between sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine value by disclosing what is withheld ('public prose, aliases, external links and media are withheld') and that identity is not established. But 'bounded direct-record admission without recursive content certification' is opaque jargon that conveys little actionable behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, which is good. The following four sentences are terse but several are cryptic enough ('identity evidence and uncertainty remain separate') that they consume space without yielding clear meaning.

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

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

There is no output schema, so the description should characterize the returned record; instead it only says 'compact' and lists omissions. Combined with three undocumented parameters and no return-shape detail, an agent lacks enough to call this reliably.

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

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

Schema description coverage is 0%, so the description carries the full burden for 4 parameters. It only addresses 'qids' (and the 10-item cap, which the schema already encodes via maxItems); lang, fields, and refresh are left entirely unexplained in both schema and prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Compact selected Wikidata facts for at most 10 supplied QIDs', which an agent can act on. It also partially differentiates from siblings by stating 'Fact lookup does not establish local identity', implicitly contrasting with kg_audit_identity/kg_discover_identity/kg_resolve. The heavy jargon ('compact facts') keeps it from being fully crisp.

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

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

The clause 'Fact lookup does not establish local identity' hints that identity-related work belongs to the identity siblings, which is useful implied routing. However, no sibling is named and no explicit when-to-use/when-not condition is given, so the agent must infer the boundary itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real operational context: depth capped at 2, results capped at 10, and explicitly which fields are withheld (public prose, aliases, external links, media). That last sentence is genuinely useful for setting output expectations. The 'bounded direct-record admission without recursive content certification' phrase adds some coverage caveat but is largely opaque jargon.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the bounds are front-loaded, which is good, but the middle sentences ('bounded direct-record admission without recursive content certification', 'Identity evidence and uncertainty remain separate') are compressed jargon that costs the reader more than it conveys. Roughly a third of the text is low-yield.

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

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

With no output schema and a 7-parameter signature, the description covers traversal bounds and omitted output fields, which is the most important part. It stops short of explaining lang behavior, how prop interacts with inverse/hierarchy, or what the returned relationship records look like.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and only partly does. It implies the semantics of depth (max 2), limit (10 results), and the inverse/hierarchy flags via 'outgoing, inverse or hierarchy', but leaves prop, lang, and id unexplained and never says what values prop accepts.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (one Wikidata QID) and the operation (bounded outgoing, inverse or hierarchy relationship retrieval), which is specific enough to separate it from kg_entity (single-record detail) and kg_search (query-based discovery). It never names a sibling explicitly, so the differentiation is inferable rather than stated.

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

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

There is no when-to-use guidance, no contrast with kg_entity or kg_lookup_entities, and no stated prerequisites. The agent must infer from the name and the word 'related' that this is the traversal tool rather than the detail tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Adds substantial value beyond the readOnly/openWorld/idempotent annotations: it discloses that Google is disabled remotely, that new entities use bounded direct-record admission without recursive certification, that identity evidence and uncertainty remain separate, and that prose/aliases/links/media are withheld. These are non-obvious behavioral traits. It does not, however, explain the shape of the returned verdicts or how reason codes should be interpreted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose in the first sentence, which is good. But the following sentences are dense, jargon-heavy fragments ('bounded direct-record admission without recursive content certification') that are hard to parse and not clearly ordered by importance, adding cognitive load without proportional value.

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

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

Covers the high-level mechanics (deterministic resolution, uncertainty handling, withholding of public fields, Google disabled) which is more than most definitions offer. However, with 21 undocumented parameters, no output schema, and no sibling differentiation, an agent still lacks enough to construct correct calls or distinguish this tool from its six siblings.

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

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

Schema description coverage is 0% across 21 parameters, so the description bears the burden of explaining the evidence fields, yet it mentions only that 'local facts' are supplied. No parameter name (city, kind, aliases, existing_wikidata_qid, explain) is explained or exemplified; the prose about uncertainty separation is relevant but gives no per-field semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Canonical deterministic resolution of one identity'. This distinguishes it from discovery-oriented siblings like kg_discover_identity, though it never names or contrasts them explicitly. An agent can infer the purpose but must guess at the boundaries with kg_lookup_entities and kg_audit_identity.

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

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

No explicit when-to-use statements, no prerequisites, and no named alternatives among the seven siblings. The phrase 'from supplied local facts and Wikidata evidence' implies the caller has evidence to provide, but the description never states when resolution is preferred over discovery, lookup, or audit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, yet the description still adds real behavioral context: default 3 / max 5 candidates, the remote disabling of Google and fallback, bounded direct-record admission, and the explicit withholding of public prose, aliases, external links and media. That last point materially sets agent expectations about output completeness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the total length is reasonable, but several fragments are opaque internal jargon ('bounded direct-record admission without recursive content certification', 'identity evidence and uncertainty remain separate') that a caller cannot act on. Those sentences do not clearly earn their place.

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

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

With no output schema and 7 undocumented parameters, the description does some of the needed work by disclosing withheld fields and candidate limits, but it leaves the return shape (how identity evidence vs uncertainty are presented) and the lang parameter unexplained, so an agent is only partially equipped.

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

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

Schema description coverage is 0%, so the description must carry the burden and it only partially does. It clarifies limit behavior (default 3, max 5, beyond the schema's null default), place/type filtering, and that provider=google and fallback are unusable, but 'lang' is never mentioned and the meaning of 'type' is left implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a concrete verb and resource: returns Wikidata entity candidates by name, with place/type filtering. That is enough to know what the tool does, but it never differentiates itself from the many siblings (kg_lookup_entities, kg_resolve, kg_discover_identity), so an agent cannot tell which search-like sibling to pick from the description alone.

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

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

There is no when-to-use guidance and no routing to alternatives. The only usage-relevant note is 'Google and fallback are disabled remotely', which usefully warns that provider=google and fallback=true will not work, but that is a constraint, not guidance on when to choose this tool over the other kg_* tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorldHint=false. The description adds genuinely useful context beyond those: no external provider calls are made, Wikidata is available, and Google Knowledge Graph is disabled. That backend-availability information materially affects whether sibling lookup tools will succeed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the most decision-relevant fact (provider availability) is stated up front after the framing sentence. It is slightly cryptic in the opening noun phrase but wastes no words.

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

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

With no parameters and no output schema, the description carries the burden of explaining what comes back, and it does convey the key operational state (which providers are on/off, that no external calls occur). A brief note on the response shape would make it fully self-sufficient, but what is present covers the agent's practical needs.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; the schema is trivially complete (100% coverage, no properties). Baseline 4 applies for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description reads as a noun phrase ('Public remote provider configuration and operational limits') rather than naming a verb, so it never explicitly says this tool reports knowledge-graph provider status. An agent can infer it returns configuration/availability info, but the phrasing is elliptical and doesn't distinguish the tool's role cleanly from the other kg_* lookups.

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

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

There is no when-to-use guidance, no mention of alternatives, and no prerequisites. The only indirect hint is the operational statement about provider availability, which an agent could use to decide whether lookups will work, but that is inference rather than stated guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.