Wikidata MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: execute_sparql runs queries, get_metadata retrieves labels/descriptions, get_properties lists properties, search_entity finds entities, and search_property finds properties. The descriptions reinforce these distinct roles, making misselection unlikely.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., execute_sparql, get_metadata, search_entity) with clear, descriptive names. There are no deviations in style or convention, making the set predictable and easy to understand.
Tool Count5/5
With 5 tools, this server is well-scoped for interacting with Wikidata. Each tool serves a specific, necessary function (querying, metadata retrieval, property listing, and searching for entities/properties), and none feel redundant or out of place for the domain.
Completeness4/5
The toolset covers core Wikidata operations well, including querying, metadata access, and searching. A minor gap is the lack of update/create/delete tools, but this is reasonable for a read-focused Wikidata interface, and agents can still perform comprehensive queries and retrievals without dead ends.
Average 3.6/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a Wikidata entity ID as a string, which is basic output information, but lacks details on error handling, rate limits, authentication needs, or what happens if no entity is found. For a search tool with zero annotation coverage, this is insufficient to inform safe and effective use.
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 appropriately sized and front-loaded, with the core purpose stated first, followed by structured sections for arguments and returns. Every sentence adds value, and there's no redundant information. It could be slightly more concise by integrating the sections more fluidly, but overall it's efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a single-parameter search function) and the absence of annotations and output schema, the description is minimally adequate. It covers the basic purpose, parameter semantics, and return type, but lacks behavioral details like error cases or performance constraints. This makes it functional but incomplete for robust agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that the 'query' parameter should be a string that is 'unambiguous enough to uniquely identify the entity,' providing context on how to formulate the query effectively. Since there's only one parameter, this compensates well for the schema's lack of documentation, though it could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for a Wikidata entity ID by its query.' It specifies the verb ('Search'), resource ('Wikidata entity ID'), and mechanism ('by its query'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_property' or 'get_metadata', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that the query should be 'unambiguous enough to uniquely identify the entity,' which hints at usage context but doesn't specify scenarios, prerequisites, or comparisons to siblings like 'search_property' or 'execute_sparql'. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches and returns a property ID, but lacks details on error handling, rate limits, authentication needs, or what happens if the query isn't unique. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
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 appropriately sized and front-loaded, with the core purpose stated first, followed by clear sections for Args and Returns. Every sentence adds value: the first defines the tool, the second clarifies the query requirement, and the third specifies the return type. There's no redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search operation with one parameter) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose, parameter intent, and return value, but doesn't address potential ambiguities, error cases, or how it differs from sibling tools. For a search function, more context on usage and behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that the 'query' parameter should be 'unambiguous enough to uniquely identify the property,' providing guidance on query formulation that isn't in the schema. With only one parameter and no schema descriptions, this compensates well, though it could elaborate on query format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for a Wikidata property ID by its query.' It specifies the verb ('search'), resource ('Wikidata property ID'), and mechanism ('by its query'). However, it doesn't explicitly differentiate from sibling tools like 'search_entity' or 'get_properties', which likely have related but distinct functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that the query should be 'unambiguous enough to uniquely identify the property,' which hints at a prerequisite but doesn't clarify scenarios where this tool is preferred over siblings like 'search_entity' or 'get_properties.' No explicit when/when-not statements or alternative recommendations are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('list of property IDs') and edge-case behavior ('empty list if no properties found'), which is useful. However, it lacks details on permissions, rate limits, or error handling, which are important for a read operation.
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 well-structured and front-loaded with the purpose, followed by clear sections for arguments and returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is mostly complete. It covers the purpose, parameter semantics, and return behavior. However, it lacks usage guidelines and some behavioral details like error cases, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'entity_id' is a 'valid Wikidata entity ID' and specifies its purpose. Since there is only one parameter, the description adequately compensates for the schema's lack of detail, though it could provide examples or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the properties associated with a given Wikidata entity ID.' It specifies the verb ('Get') and resource ('properties'), but does not explicitly differentiate it from sibling tools like 'get_metadata' or 'search_property', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'search_entity' or 'search_property', nor does it specify prerequisites or exclusions. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return format (JSON-formatted result) and edge case behavior (empty JSON object for no results), which is valuable. However, it doesn't mention rate limits, authentication requirements, timeout behavior, or query complexity constraints that would be important for a query execution tool.
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 efficiently structured with a clear purpose statement, helpful prefix information, and well-organized parameter/return documentation. Every sentence serves a distinct purpose with zero wasted words, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query execution tool with no annotations or output schema, the description provides good coverage of purpose, parameter meaning, and return behavior. It could be more complete by addressing authentication, rate limits, or error handling, but it covers the essential aspects well given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter, the description fully compensates by clearly explaining what the sparql_query parameter should contain. It provides context about assumed prefixes and specifies it's a SPARQL query for Wikidata, adding significant meaning beyond what the bare schema provides.
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 specific action ('Execute a SPARQL query') and target resource ('on Wikidata'), distinguishing it from sibling tools like get_metadata or search_entity. It provides a complete verb+resource+scope statement that leaves no ambiguity about 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by specifying the target (Wikidata) and listing assumed prefixes, which helps understand when this tool is appropriate. However, it doesn't explicitly state when to use this versus alternatives like search_entity or get_properties, nor does it mention any prerequisites or exclusions for SPARQL query execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool does (retrieves metadata) and mentions the return format (dictionary with label/description), but does not cover potential errors, rate limits, authentication needs, or what happens if data is unavailable. It adds basic context but lacks depth for a tool with no annotation support.
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 well-structured with a clear purpose statement, parameter details in an 'Args' section, and return information. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, parameters, and return format, but lacks details on error handling or edge cases (e.g., unavailable data). With no output schema, it appropriately explains the return value, though could be more comprehensive.
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?
The schema description coverage is 0%, so the description must fully compensate. It provides detailed semantics for both parameters: 'entity_id' is explained as 'the entity ID to retrieve metadata for', and 'language' includes its purpose, default value ('en'), and format specification ('ISO 639-1 codes'). This adds significant value beyond the bare schema.
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 specific action ('Retrieve'), resource ('English label and description'), and target ('Wikidata entity ID'). It distinguishes itself from sibling tools like 'search_entity' or 'get_properties' by focusing on metadata retrieval rather than searching or property fetching.
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 clear context for when to use this tool (to get label/description for a Wikidata entity ID) but does not explicitly mention when not to use it or name specific alternatives among the sibling tools. The context is well-defined but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-wikidata MCP server](https://glama.ai/mcp/servers/zzaebok/mcp-wikidata/badges/card.svg)](https://glama.ai/mcp/servers/zzaebok/mcp-wikidata)

Score Badge

Copy to your README.md:

[![mcp-wikidata MCP server](https://glama.ai/mcp/servers/zzaebok/mcp-wikidata/badges/score.svg)](https://glama.ai/mcp/servers/zzaebok/mcp-wikidata)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zzaebok/mcp-wikidata'

If you have feedback or need assistance with the MCP directory API, please join our Discord server