Skip to main content
Glama

wikidata-mcp-server

by io.github.cyanheads

Get Wikidata Entity

wikidata_get_entity
Read-only

Fetch a Wikidata entity (item or property) by QID or PID. The fields parameter narrows the upstream fetch, not just the response — asking for labels alone costs a fraction of the whole entity, so name the fields you need. Omit fields for all data; a well-connected item is large enough to overflow, and an oversized entity returns kind: "outline" — the field categories with their byte sizes — instead of the data. Follow its retrieval_notice literally rather than picking from sections yourself — it names a fields set already measured to fit, since category sizes are additive and requesting them all would overflow again; for a category too large to deliver whole (statements or sitelinks on a major item) it names the sibling tool that can narrow it. Q-IDs (e.g. Q76) fetch items; P-IDs (e.g. P31) fetch properties from the correct endpoint automatically. Use wikidata_get_statements for deep claim traversal with label resolution, and whenever an entity's statements are large — its properties parameter selects individual P-IDs, granularity fields does not carry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesQ-ID (e.g., "Q76") or P-ID (e.g., "P31"). Case-insensitive — normalized to uppercase.
fieldsNoFields to include. Options: "labels", "descriptions", "aliases", "statements", "sitelinks". Narrows the upstream fetch as well as the response, so a narrow selection is markedly cheaper. Omit for all fields.
languagesNoLanguage codes to include in labels, descriptions, and aliases (e.g., ["en", "de"]). A requested language with no label of its own falls back to the entity's multilingual ("mul") value, returned under the requested code. Omit to return all available languages.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNormalized entity ID (e.g., "Q76" or "P31").
kindNofull — the requested field categories carry their data. outline — the entity overflowed the inline byte budget, so sections lists the categories with their byte sizes instead, and retrieval_notice names how to fetch each one. The id and type are present either way.
typeNoEntity type: "item" or "property".
errorNoPresent when the call failed. Absent on success.
labelsNoMap of language code to label string (e.g., {"en": "Barack Obama", "de": "Barack Obama"}).
aliasesNoMap of language code to list of alias strings (e.g., {"en": ["Barack H. Obama", "President Obama"]}).
sectionsNoPresent when kind = outline: the entity's field categories, largest first, each with its byte size. Sizes are additive — a set of categories is only retrievable together if their total fits the budget, so follow retrieval_notice rather than requesting every name listed here.
data_typeNoProperty data type (e.g., "wikibase-item", "external-id"). Present on properties only.
sitelinksNoMap of site code (e.g., "enwiki") to sitelink metadata with title, url, and badges fields.
statementsNoMap of property ID to array of raw statement objects. Use wikidata_get_statements for resolved claims with label resolution, and whenever this entity's statements are large — its properties parameter selects individual P-IDs, granularity fields does not carry.
descriptionsNoMap of language code to description string (e.g., {"en": "44th President of the United States"}).
fieldsReturnedNoWhich fields were requested. In outline mode these are the categories the outline covers, not data returned.
retrieval_noticeNoPresent when kind = outline: the next call to make, and the authoritative one to follow. It names a literal fields set already measured to fit the budget, defers any category that would not fit alongside it, and for a category too large for fields to deliver at all names the sibling tool (wikidata_get_statements, wikidata_get_sitelinks) or the languages parameter that can narrow it.

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

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: '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.

Usage Guidelines4/5

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.

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