Wikidata + Google Knowledge Graph MCP

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description correctly spends its words elsewhere: it discloses the return content (contradictions, evidence, uncertainty) and a real behavioral limitation ('Google crosscheck is disabled remotely'). It does not explain the effect of refresh or max_candidates, hence not a 5.

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?

Four short sentences, result and scope front-loaded, no filler. The caveats are dense but each conveys a distinct constraint rather than restating the name.

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?

For a tool taking a nested, schema-undocumented envelope and producing no output schema, the description should say more about what the envelope requires and what refresh/max_candidates do. It adequately signals the return contents, but the input contract remains largely a black box.

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 coverage is 0% and there are 4 parameters, including a nested open envelope object (additionalProperties: true) with no shape documented anywhere. The description clarifies only one parameter indirectly (google_crosscheck is disabled remotely) and does not explain refresh, max_candidates, or what an envelope must contain, leaving most of the call contract undocumented.

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 audit of one existing Wikidata QID against one local identity envelope.' The 'existing' qualifier implicitly distinguishes it from the discovery sibling kg_discover_identity, though it never names it. Clear enough for an agent to know what the tool does.

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?

Usage is implied by 'audit of one existing Wikidata QID' (i.e., use when you already have a QID to validate), but there is no explicit when-to-use versus kg_discover_identity, kg_resolve, or kg_lookup_entities, and no stated prerequisites. The caveats ('provider agreement is not local identity proof') hint at intent without routing the agent.

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 genuinely useful behavioral context beyond that: it discloses the ambiguity and insufficient-evidence return states, that sameAs candidates arrive unapproved, and that Google crosscheck is remotely disabled.

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?

Four dense sentences, each carrying distinct information, with the core purpose front-loaded. There is no filler, though the terse telegraphic style borders on cryptic for terms like 'evidence envelope'.

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?

For a read-only tool with no output schema, the description does cover return states, which is valuable. But it omits any explanation of the required nested envelope structure and refresh semantics, which is a meaningful gap given 0% schema coverage and a nested object parameter.

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. It clarifies max_candidates ('default 3, maximum 5') and implicitly the disabled google_crosscheck flag, but the required 'envelope' object (nested, additionalProperties) and 'refresh' are left entirely unexplained 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 description names a verb (discovery) and resource (identity) and specifies scope ('one identity', 'canonical', 'local evidence envelope'). However, 'identity' and 'evidence envelope' are undefined jargon, and it does not distinguish itself from the closely related sibling kg_resolve or kg_audit_identity, leaving the agent to guess which tool to pick.

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 when this tool should be preferred over kg_resolve, kg_lookup_entities, or kg_audit_identity. The only routing signal is the relational scope of the sibling names, which the description does not leverage.

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 establish read-only, idempotent, open-world and non-destructive behavior, so the safety profile is covered. The description adds genuine output-shape context beyond that: results are capped at 12 properties and 3 evidence properties and include ranks, qualifiers and references, which tells the agent this is a compact rather than exhaustive fetch.

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 sentences, front-loaded with the scope and then the result limits, with essentially no wasted words. It is slightly elliptical in the opening clause, which costs a point.

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 describe the return shape reasonably (properties with ranks, qualifiers, references). However, it omits the lang parameter's effect, defaults, and the behavior when optional filters are omitted, leaving gaps an agent would need to guess at.

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 schema documents none of the four parameters. The description partially compensates by implying the props and evidence parameters and their caps (12 and 3) and the single-QID id, but it never explains lang or what happens when props/evidence are null.

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 states the resource (facts for one Wikidata QID) but uses a vague phrasing rather than a clear verb, so it is not immediately obvious whether it retrieves, summarizes, or resolves an entity. It also fails to distinguish itself from siblings like kg_lookup_entities or kg_resolve, which an agent would plausibly confuse with this tool.

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 alternatives such as kg_lookup_entities or kg_search, and no mention of prerequisites or exclusions. The only implicit guidance is the 'one QID' scope.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the identity caveat, which is genuine behavioral context, but the 'at most 10 QIDs' limit merely restates the schema's maxItems=10 and nothing is said about refresh semantics or return shape.

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, front-loaded sentences with no filler. It is efficient, though the second sentence is slightly cryptic and could have been spent on parameter meaning instead.

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?

For a four-parameter tool with no output schema and zero schema-level parameter descriptions, the definition leaves lang, fields, and refresh entirely unexplained. An agent cannot confidently construct a call beyond the required qids array.

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% for four parameters, so the description must compensate and largely does not. It covers only the qids cap (already in maxItems) and says nothing about lang, fields, or refresh — notably refresh, whose behavior (cache invalidation?) is opaque.

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 action on a specific resource: compacting selected Wikidata facts for supplied QIDs, with a hard cap of 10. The clause 'Fact lookup does not establish local identity' hints at the boundary with the identity siblings (kg_audit_identity, kg_resolve), though it never names them. An agent can grasp the core purpose without opening the schema.

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 explicit when-to-use guidance and no alternative tool is named. The single caveat ('does not establish local identity') implies a boundary with the identity/resolve siblings but leaves the agent to infer the routing rule. This is the weakest dimension.

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 establish read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds useful boundary information (maximum depth 2, 10 results), but does not explain how the inverse/hierarchy flags change the traversal, what happens at the depth limit, or the shape of the result set.

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?

One tight sentence with the resource front-loaded and the bounding constraints at the end. It is efficient, though slightly terse given the seven parameters it must orient the caller around.

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?

For a traversal tool with no output schema and nothing but 0%-covered schema fields, the description leaves gaps: result format, behavior of prop/lang filtering, and what inverse/hierarchy actually return are unspecified. It is adequate but not complete.

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 coverage is 0%, so the description bears full responsibility for the 7 parameters, and it only partially compensates: it hints at the depth and limit caps and gestures at inverse/hierarchy via 'outgoing, inverse or hierarchy'. Parameters like id, lang, and prop receive no meaning beyond what their terse schema titles imply.

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 states a specific action (retrieving relationships) on a specific resource (one Wikidata QID) and quantifies its boundedness. It is distinguishable from sibling tools like kg_entity, kg_search, and kg_lookup_entities, which retrieve entities rather than traverse relationships, though it does not name them explicitly.

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 statement of prerequisites or alternatives, and no indication of when this should be preferred over kg_entity or kg_search. The traversal intent is implied only by the word 'relationships'.

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 safety (readOnly, idempotent, non-destructive, open-world), so the description earns credit for adding behavior beyond them: it is deterministic, returns identity verdicts with reason codes, and surfaces uncertainty. The note that Google is disabled remotely is valuable operational context an agent can't get from annotations. It stops short of describing pagination, latency, or failure modes.

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?

Three tight sentences that front-load the purpose and then the return shape and the Google limitation. No filler. The 'Google is disabled remotely' phrasing is slightly cryptic but earns its place as an operational caveat.

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?

For a 21-parameter tool with no output schema, the description does more than most by sketching the return shape (verdicts, reason codes, uncertainty). However, with 0% schema coverage it leaves the parameter contract essentially undocumented, which is a substantial gap for a tool this complex.

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 carries the full burden and largely fails it. It gestures at 'local facts' and 'Wikidata evidence' but never explains what name, kind, venue, role, aliases, or the existing_* IDs mean or how they influence resolution. An agent must guess at nearly every field.

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: resolving one identity from local facts plus Wikidata evidence. This distinguishes it reasonably well from kg_discover_identity and kg_audit_identity, though it doesn't name those siblings explicitly. The core purpose is clear without opening the schema.

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 explicit when-to-use guidance relative to siblings like kg_discover_identity or kg_audit_identity, which an agent must choose between. The only directional note is 'Google is disabled remotely,' which reads as a limitation rather than a selection rule. Context is implied but not stated.

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 read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description still adds useful behavior beyond the schema: the 3-candidate default, the 5-candidate cap, and the fact that Google and fallback are disabled remotely — a real constraint an agent would otherwise discover only by failure.

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?

Three short sentences, no filler, with the core purpose front-loaded. The disabled-provider note is appended rather than integrated into the introduction, but nothing is wasted.

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?

For a 7-parameter tool with 0% schema description coverage and no output schema, the description covers the most consequential constraints (limit cap, disabled providers) but leaves several parameters and the shape of the returned candidates unexplained. Adequate, not complete.

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 coverage is 0% across seven parameters, so the description must compensate. It partially does: it explains limit semantics (default 3, max 5) and the state of provider/fallback, and 'place/type filtering' gestures at two more. But lang, query and the exact interaction between place and type are left undocumented.

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 a specific verb+resource: retrieving Wikidata entity candidates by name, with place/type filtering. It is clear what the tool returns, but it never distinguishes itself from sibling tools such as kg_entity, kg_lookup_entities or kg_resolve, which likely return entities too.

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 reach for this tool over the sibling lookup/resolve tools. The only routing hint is the operational note that Google and fallback are disabled remotely, which tells the agent what not to pass rather than when to use the 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?

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.