wikidata-mcp-server

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

Annotations already provide readOnlyHint and openWorldHint, and the description adds substantial behavioral context: fields narrow the upstream fetch, oversized entities return an 'outline' with byte sizes, category sizes are additive, and Q-IDs/P-IDs route to the correct endpoint automatically. No contradiction with annotations.

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 front-loaded with the core purpose, then cost, overflow, retrieval_notice, endpoint handling, and sibling routing. It is long and dense, and some phrasing is awkward ('granularity fields does not carry'), but every sentence carries operational value with no filler.

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 with overflow behavior, field-selection subtleties, and sibling routing, the description covers all operational essentials. An output schema exists, so return-value details need not be repeated, and nothing an agent needs to call the tool correctly is missing.

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 100%, so the baseline is 3, but the description adds meaning well beyond the schema: the fields parameter narrows the upstream fetch and affects cost, omitting fields can trigger overflow, and Q-IDs versus P-IDs change endpoint behavior. This is operationally important guidance the schema alone does not convey.

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 verb and resource: 'Fetch a Wikidata entity (item or property) by QID or PID.' It also distinguishes from siblings by explaining Q/P endpoint handling and the fields parameter, so an agent can tell this tool apart from wikidata_get_labels, wikidata_get_sitelinks, and wikidata_get_statements.

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 description explicitly directs agents to wikidata_get_statements for deep claim traversal and large statement sets, and instructs following the retrieval_notice literally rather than self-selecting sections. It does not explicitly name when to prefer wikidata_get_labels or wikidata_get_sitelinks, though the fields-narrowing guidance implies those alternatives.

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?

The read-only nature is already marked by annotations (readOnlyHint: true). The description adds valuable context by noting it returns no claim data, and the parameter schema clarifies the languages fallback behavior. While these are useful additions, the core safety profile (read-only, no side effects) is already well-covered by annotations, so the incremental contribution is moderate.

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?

Concise yet information-dense: the core purpose followed by the most critical operational constraints ('Lightweight', 'no claim data', '50 ID limit', 'batched') and a use-case anchor. Every sentence earns its place without redundancy. Exactly the right size for the tool's simplicity.

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?

The existence of a complete output schema means the return shape is documented elsewhere. The description sufficiently covers the primary use case, the 'lightweight' nature, and the batching. A small gap: it doesn't explicitly state the behavior when an ID cannot be found (e.g., error vs. skip), but this is covered by the output schema's error handling and isn't critical for basic usage.

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 100%, and the schema itself documents both parameters clearly (with formats in the IDs description and fallback in the languages). The description adds semantics by reinforcing the batch limit ('50') and providing a usage example pattern. However, it doesn't add new syntax details beyond what's already in the schema.

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 uses a specific verb ('Resolve') with a clear resource ('QIDs or PIDs to their human-readable labels and descriptions'), and explicitly scopes what the tool does NOT do ('returns no claim data') and its batch limit (50 IDs). It clearly differentiates itself from siblings like wikidata_get_entity and wikidata_get_statements by its specific focus on label resolution.

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 description includes a use-case pattern ('receive QIDs from a SPARQL query, then humanize them') and notes the batching behavior. However, it doesn't explicitly mention sibling tools or state when NOT to use it, which limits its utility for an agent choosing between 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 and idempotentHint, so safety is covered. The description adds key behavioral context: the item-vs-property limitation is not present in annotations, and the note about 300+ sitelinks informs about scale. This adds value beyond structured fields without contradicting them.

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 tightly written: it leads with the function, then explains the filter options, and closes with the critical item-vs-property constraint. Each sentence contributes new information with no redundancy, and the most important caveat is placed last for emphasis.

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 an output schema present and annotations providing read-only/idempotent hints, the description covers all necessary invocation details: purpose, filters, scale expectations, and a critical domain restriction. An agent has enough to correctly select and call this tool without additional information.

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 100%, so parameters are documented. However, the description enriches understanding by explaining the purpose of the filters (sites for specific language editions, wikis_only for Wikipedia-only) and the underlying concept of a sitelink mapping site codes to article titles. It also highlights the property exclusion, which is not in the schema descriptions but is crucial for correct invocation.

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 clearly states the action ('Fetch Wikipedia and Wikimedia project article URLs') and the resource ('for a Wikidata item'). It distinguishes from sibling tools by explicitly noting that only items (Q-IDs) have sitelinks, not properties (P-IDs), which immediately separates it from property-related tools like wikidata_get_statements.

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?

Provides explicit guidance on using the 'sites' parameter to filter by language and 'wikis_only' to restrict to Wikipedia. It also warns that major items can have 300+ sitelinks, implying potential large responses. While it doesn't explicitly state when NOT to use this tool, the property exclusion clarifies a boundary, and the context is clear enough for an agent to decide.

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?

Beyond the read-only and idempotent annotations, the description discloses meaningful behaviors: default QID-to-label resolution, the outline fallback for oversized result sets, the need to re-call with selected P-IDs, and the preferred-rank currency note. This goes well beyond what annotations alone convey.

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 dense but efficient: primary function first, then payload-size caveat, then the outline recovery mechanism, then the intended use case. Every sentence contributes actionable information with no redundancy.

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 a rich output schema, complete parameter documentation, and annotations covering safety, the description still adds the missing behavioral context: oversize handling, label resolution defaults, and rank semantics. Nothing critical is missing for an agent to select and 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 coverage is complete at 100%, so the parameters are already documented. The description adds useful semantic context beyond the schema: what happens when properties is omitted, the outline response shape, and the effect of label resolution on payload size and speed.

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 opens with a specific verb+resource ('Fetch property claims for a Wikidata entity') and adds detail about qualifiers, references, and label resolution. It clearly distinguishes itself from sibling tools like get_entity, get_labels, and sparql_query, which serve different purposes.

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 description gives practical guidance: use the properties parameter to narrow to specific P-IDs, and expect a large result set if omitted. It also characterizes the tool as designed for fact verification, which signals an appropriate use case, though it does not explicitly name when-not-to-use alternatives.

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=true and openWorldHint=true, but the description goes far beyond by disclosing specific return states (match=entity, match=null, multipleMatches), the rejection behavior for non-external-id properties, and detailed normalization rules (whitespace trimming, URL prefix stripping, DOI uppercasing, ORCID hyphen normalization). This behavior is not derivable from annotations or schema and adds substantial transparency.

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 dense but well-organized: purpose first, then return semantics, then use cases, then constraints, then normalization. Every sentence provides non-redundant information, and the most critical constraints (must be external-id) are positioned before the parameter-specific details. No fluff or repetition.

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?

Given the tool has 3 parameters, an output schema (present per context), and rich annotations, the description completes the picture by covering success/failure states, multi-match edge cases, property type restrictions, and normalization. Nothing an agent needs for correct invocation is missing, and the existence of an output schema means return values need no further elaboration.

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?

Despite 100% schema coverage, the description enriches parameter meaning substantially. For the 'value' parameter, it explains acceptable resolver URL prefixes that get stripped; for the 'property' parameter, it enumerates valid P-IDs (P356, P698, P496, P10283, P345) and explicitly warns that non-external-id types are rejected. This goes well beyond the schema's own field descriptions.

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 clearly states the tool's function: 'Look up a Wikidata entity by an external identifier' with specific examples like DOI, PubMed ID, ORCID, OpenAlex. It also describes the return behavior (match=entity, match=null) and distinguishes from sibling tools by focusing exclusively on external identifier resolution rather than direct QID lookup, search, or property statements.

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 description provides explicit when-to-use context through 'Common cross-server join use cases' and maps identifiers to properties. It also gives when-not-to-use guidance by stating the property must be external-id type, with examples of rejected properties (P31, P18). However, it does not explicitly name alternative tools or conditions for choosing a sibling such as wikidata_get_entity or wikidata_search_entities, so it stops short of full alternative comparison.

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?

The description adds meaningful behavioral details beyond the annotations: it clarifies that the API returns no total count, pagination is offset-based, and no result ceiling indicator exists. The annotations already indicate read-only/open-world behavior, so the description only needs to add quirks and return format, which it does.

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: the first states exactly what the tool does, the second gives return-type guidance, and the third addresses pagination can. There is no filler or redundant restating, and the most important details are front-loaded.

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?

Combined with the fully-covered input schema, attached output schema, and read-only/open-world annotations, the description is complete for an agent to invoke the tool correctly. It also covers important behavioral caveats (pagination without total count) that the schema would not.

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 input schema covers 100% of parameter semantics, so the baseline is 3. The description adds only marginal color — e.g., plain-language examples for type values — but the formal parameter documentation already contains the same meaning for query, limit, offset, and language.

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 opens with a specific verb and resource ('Search Wikidata for items or properties by text query') and explicitly states the result type ('QIDs or PIDs with labels, descriptions, and match metadata'). This clearly distinguishes the tool from direct-lookup siblings like wikidata_get_entity, which fetch by exact ID rather than full-text search.

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 description gives clear contextual guidance on when to set type="item" vs type="property", and warns about pagination. It doesn't explicitly state 'use wikidata_get_entity for direct lookups' or list exclusions, but the search semantics are implied well enough that an agent can select this tool when the user has a text query.

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 (readOnlyHint: true, openWorldHint: true) are reinforced rather than contradicted, and the description adds substantial behavior beyond them: SELECT-only enforced, auto-injection of standard prefixes, the dynamic wikibase:label SERVICE injection rule, the 60s hard server timeout, and the SPARQL 1.1 JSON binding format. An agent can predict failure modes and output shapes without a trial call. No contradiction with annotations; annotation_contradiction = false.

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?

Dense but never padded. Every clause delivers a distinct fact: purpose, capability scope, prefix injection, label SERVICE behavior, timeout, response format, and cross-tool routing. The core purpose leads, and behavioral details follow in logical order with zero fluff.

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 full SPARQL endpoint, the description covers the critical gotchas an agent would otherwise discover through failed calls: auto-injected prefixes, label SERVICE magic, timeout ceiling, and response shape. An output schema exists to carry return-value documentation. Minor gaps like rate limiting, error handling for malformed queries, and caching are not addressed, but these are optional given the output schema's presence.

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?

At 100% schema coverage, the baseline is 3, but the description adds meaning beyond the schema: it explains the 60s server cap that rationalizes the timeout parameter's 55s maximum, and it clarifies the label SERVICE auto-injection rule that governs how the language and query parameters interact. The 'use LIMIT to keep queries fast' tip connects the query param to performance behavior.

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 sentence, 'Execute a SPARQL SELECT query against the Wikidata Query Service,' is a textbook example of specific verb + resource. It further enumerates capability ('multi-hop traversals, aggregations, subqueries, OPTIONAL, FILTER, UNION, BIND') and implicitly differentiates from siblings by naming wikidata_get_labels as the follow-up for humanization, clarifying what this tool is not for.

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 closing pointer to 'Use wikidata_get_labels to humanize QID results' gives one alternative-routing hint, and 'Full graph power' implies this is the heavy-duty sibling versus simpler accessors. However, there is no explicit statement of when to prefer this over wikidata_get_entity, wikidata_get_statements, or search tools — the when/when-not boundary is implied, not stated.

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