Skip to main content
Glama

Wikidata

by io.github.pipeworx-io

Get Entity

get_entity
Read-onlyIdempotent

Get full Wikidata entity by ID (e.g., "Q42" for Douglas Adams, "Q5" for human, "Q1764" for Budapest). Returns labels, descriptions, aliases, claims/statements (properties and values), sitelinks, and the revision the data came from — lastrevid plus the modified timestamp — so live statements can be pinned to a specific edit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesWikidata entity ID (e.g., "Q42", "Q937", "P31")

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesWikidata entity ID
typeYesEntity type (e.g., 'item', 'property')
labelYesEnglish label for the entity
claimsYesProperty claims/statements (up to 30 properties, 5 values each)
aliasesYesList of alternative names
modifiedYesUTC timestamp of that revision (ISO 8601)
lastrevidYesRevision id these statements were read at, for pinning the answer to a specific edit
descriptionYesEnglish description of the entity
revision_urlYesPermalink to that exact revision on wikidata.org
wikipedia_enYesEnglish Wikipedia article title if available
sitelinks_countYesNumber of Wikipedia/sister project links

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / lastrevid
      Added value: +{
+  "description": "Revision id these statements were read at, for pinning the answer to a specific edit",
+  "type": [
+    "number",
+    "null"
+  ]
+}
    • addedOutput schema / properties / modified
      Added value: +{
+  "description": "UTC timestamp of that revision (ISO 8601)",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • addedOutput schema / properties / revision_url
      Added value: +{
+  "description": "Permalink to that exact revision on wikidata.org",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedOutput schema / required
      Previous value: -[
-  "id",
-  "type",
-  "label",
-  "description",
-  "aliases",
-  "claims",
-  "sitelinks_count",
-  "wikipedia_en"
-]New value: +[
+  "id",
+  "type",
+  "label",
+  "description",
+  "aliases",
+  "claims",
+  "sitelinks_count",
+  "wikipedia_en",
+  "lastrevid",
+  "modified",
+  "revision_url"
+]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

This description goes beyond the readOnly/idempotent annotations by explaining the return payload in detail, including lastrevid and modified timestamp and their purpose. The provenance-pinning detail is especially valuable for agents deciding between live versus historical data. It does not cover edge-case behavior like missing IDs, but annotations already establish the safe read-only profile.

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 two sentences, front-loaded with the core purpose and then detailed with meaningful return information. It is dense but not bloated. The only minor excess is some overlapping explanation of the revision field and its timestamp, yet each clause still earns its place.

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 single-parameter, read-only, idempotent fetch operation, this description is complete. It states the input format, gives concrete examples, explains the full output contents including version metadata, and the output schema and annotations already cover any remaining structural and safety details. Nothing an agent needs to call this tool correctly is missing.

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

Parameters3/5

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

The input schema already covers 100% of the parameter with examples (Q42, Q1764, P31). The description adds one extra concrete ID example (Q5) and reinforces semantics through full entity retrieval, but it does not materially enrich what the schema already states. This meets the baseline for high schema coverage without adding substantial clarity.

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 starts with a specific action and resource: 'Get full Wikidata entity by ID'. It clearly enumerates what 'full' means (labels, descriptions, aliases, claims, sitelinks, revision info), so the agent understands exactly what this tool returns. The by-ID scoping also sets it apart from broader tools like search_entities.

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 phrase 'by ID' provides clear contextual guidance: this tool is for when an agent already knows a Wikidata entity ID and needs complete entity data. It does not explicitly mention when to prefer search_entities, resolve_entity, or compare_entities, but the ID-based usage is clear enough to avoid obvious mis-selection.

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

All Wikidata 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

A3.5/5.0
Disambiguation2/5

The tool set is extremely heterogeneous and overlapping. Multiple tools serve nearly identical purposes (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, discover_tools, suggest_questions), and entity-related tools (get_entity, get_wikidata_facts, entity_profile, compare_entities, resolve_entity) have unclear boundaries. The server is named Wikidata but only 3 of 34 tools actually relate to Wikidata, causing confusion about which tool is appropriate.

Naming Consistency2/5

Tool names mix multiple conventions: verb_noun (get_entity, search_entities, list_subscriptions), noun phrases (polymarket_edges, entity_profile, pipeworx_feedback), and inconsistent suffixes (_beta, _grounded). The verbs used are vague and not part of a coherent pattern (get, search, ask, discover, resolve, scan, validate, generate, remember, recall). The naming is readable but lacks a predictable system.

Tool Count2/5

34 tools is high for a server with a focused name like Wikidata, and nearly all tools belong to unrelated domains (Pipeworx data routing, Polymarket betting, memory management, subscriptions, AI visibility). The count appears bloated and scattered rather than well-scoped; most tools could be split into separate servers.

Completeness2/5

For a Wikidata server, the coverage is minimal: only search, get by ID, and human-readable facts are present, with no SPARQL query support or property-level access. The majority of tools address Pipeworx's broad data catalog, leaving the advertised Wikidata purpose severely under-served. The surface is complete for a different domain but incomplete for the stated one.

Resources