Skip to main content
Glama

wikidata-mcp-server

by io.github.cyanheads

Resolve Wikidata External ID

wikidata_resolve_external_id
Read-only

Look up a Wikidata entity by an external identifier such as a DOI, PubMed ID, ORCID iD, or OpenAlex ID. Returns match= on success, match=null when not found, and match=null with multipleMatches populated when a Wikidata data integrity issue causes more than one entity to claim the same external ID. Common cross-server join use cases: CrossRef DOI → Wikidata paper QID (P356), PubMed PMID → Wikidata paper QID (P698), ORCID → author QID (P496), OpenAlex ID → entity QID (P10283). The property must be one whose Wikidata data type is external-id — item-valued or media properties (e.g. P31 instance-of, P18 image) are rejected rather than returning an empty match. Known value normalization is applied automatically: surrounding whitespace is trimmed, identifier-resolver URL prefixes are stripped (https://doi.org/, https://pubmed.ncbi.nlm.nih.gov/, https://orcid.org/), DOIs are uppercased, PMID prefixes stripped, ORCID hyphens normalized.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesThe external identifier value to look up (e.g., "10.1038/nature01234" for a DOI, "32283226" for a PubMed ID, "0000-0002-1825-0097" for an ORCID). A resolver URL is accepted for DOI, PubMed, and ORCID — the prefix is stripped before lookup.
languageNoLanguage code for label and description in the response (e.g., "en", "de").en
propertyYesP-ID of the external identifier property, whose Wikidata data type must be external-id (e.g., "P356" for DOI, "P698" for PubMed ID, "P496" for ORCID, "P10283" for OpenAlex ID, "P345" for IMDb ID). Properties of any other data type are rejected — check an unfamiliar P-ID's data type with wikidata_get_entity.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
matchNoMatching entity, or null when no Wikidata entity claims this external identifier (including the case where multipleMatches is populated). A null match is not proof of absence — the Query Service backing this lookup lags the live wiki, so a recently added identifier may not be indexed yet.
valueNoThe normalized value that was searched (may differ from input due to canonicalization).
propertyNoThe P-ID used for the lookup.
multipleMatchesNoPresent when more than one Wikidata entity claims this external ID (data integrity issue). match is null when this field is present. Inspect the list and select the correct QID manually.

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All wikidata-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct access pattern: entity retrieval, label resolution, sitelinks, statements, external ID lookup, text search, and SPARQL. Any apparent overlap (e.g., get_entity with fields vs. get_statements) is explicitly disambiguated in the descriptions.

Naming Consistency5/5

All tools share a consistent wikidata_ prefix followed by verb_noun style: get_entity, get_labels, get_sitelinks, get_statements, resolve_external_id, search_entities. Even sparql_query follows the predictable action-oriented pattern, so the set reads uniformly.

Tool Count5/5

Seven tools is well-scoped for a Wikidata knowledge-access server. Each tool earns its place, covering the primary retrieval methods without adding redundant or purely cosmetic variants.

Completeness5/5

For a read-only Wikidata MCP server, the surface is essentially complete: direct entity lookup, label humanization, sitelink mapping, statement fetching with qualifiers/references, external ID resolution, text search, and full SPARQL querying. There are no obvious dead ends for the domain it serves.

Resources