What can you do with this server?

The Wikidata MCP Server enables interaction with Wikidata using the Model Context Protocol (MCP). With this server, you can: * Search for Wikidata entity IDs by querying entity names * Search for Wikidata property IDs by querying property names * Retrieve properties associated with a specific Wikidata entity ID * Execute SPARQL queries on Wikidata to fetch structured data * Extract metadata (label and description) for a given Wikidata entity ID in a specified language

Which integrations are available for this server?

Provides access to the project repository for installation via git clone from GitHub. Enables integration with LangChain through langchain-mcp-adapters, allowing AI agents to interact with Wikidata's knowledge graph through the Model Context Protocol. Provides tools for interacting with Wikidata, including searching for entity and property identifiers, retrieving entity metadata (labels and descriptions), accessing entity properties, and executing SPARQL queries against the Wikidata knowledge base.

How do I use Wikidata MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Wikidata MCP Server search for the entity ID of Albert Einstein" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

Wikidata MCP Server

by zzaebok

Overview Schema Related Servers Score Discussions

Python

Remote

Wikidata MCP Server

A server implementation for Wikidata API using the Model Context Protocol (MCP). This project provides tools to interact with Wikidata, such as searching identifiers (entity and property), extracting metadata (label and description) and executing sparql query.

Installation

Installing via Smithery

To install Wikidata MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @zzaebok/mcp-wikidata --client claude

Installing Manually

Install uv if it is not installed yet.

$ curl -LsSf https://astral.sh/uv/install.sh | sh

Then, install dependencies.

$ git clone https://github.com/zzaebok/mcp-wikidata.git
$ cd mcp-wikidata
$ uv sync
# if you want to run client example together
$ uv sync --extra example

Run

Run the server with:

$ uv run src/server.py

If you want to test it with a simple client code (with langchain-mcp-adapters), run the client with:

# in another shell
$ uv run src/client.py

The LLM extracts valid entity and property identifiers, executes a sparql query, and finally recommend a movie directed by Bong Joon-ho.

{
  "messages": [
      HumanMessage(
          content="Can you recommend me a movie directed by Bong Joonho?",
      ),
      AIMessage(
          tool_calls=[
              {
                  "name": "search_entity",
                  "args": {"query": "Bong Joon-ho"},
              }
          ],
      ),
      ToolMessage(
          content="Q495980",
          name="search_entity",
      ),
      AIMessage(
          tool_calls=[
              {
                  "name": "get_properties",
                  "args": {"entity_id": "Q495980"},
              }
          ],
      ),
      ToolMessage(
          content='["P345", "P244", "P214", "P227", ...]',
          name="get_properties",
      ),
      AIMessage(
          tool_calls=[
              {
                  "name": "search_property",
                  "args": {"query": "director"},
              }
          ],
      ),
      ToolMessage(
          content="P57",
          name="search_property",
      ),
      AIMessage(
          tool_calls=[
              {
                  "name": "execute_sparql",
                  "args": {
                      "sparql_query": 'SELECT ?film ?filmLabel WHERE {\n  ?film wdt:P57 wd:Q495980.\n  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }\n} LIMIT 1'
                  },
              }
          ],
      ),
      ToolMessage(
          content='[{"film": {"type": "uri", "value": "http://www.wikidata.org/entity/Q483761"}, "filmLabel": {"xml:lang": "en", "type": "literal", "value": "Mother"}}]',
          name="execute_sparql",
      ),
      AIMessage(
          content='I recommend the movie "Mother," which was directed by Bong Joon-ho.',
      ),
  ]
}

Wikidata MCP Tools

The following tools are implemented in the server:

Tool	Description
`search_entity(query: str)`	Search for a Wikidata entity ID by its query.
`search_property(query: str)`	Search for a Wikidata property ID by its query.
`get_properties(entity_id: str)`	Get the properties associated with a given Wikidata entity ID.
`execute_sparql(sparql_query: str)`	Execute a SPARQL query on Wikidata.
`get_metadata(entity_id: str, language: str = "en")`	Retrieve the English label and description for a given Wikidata entity ID.

License

MIT License

Available Tools

5 tools

execute_sparqlA

Execute a SPARQL query on Wikidata.

You may assume the following prefixes:
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX ps: <http://www.wikidata.org/prop/statement/>

Args:
    sparql_query (str): The SPARQL query to execute.

Returns:
    str: The JSON-formatted result of the SPARQL query execution. If there are no results, an empty JSON object will be returned.

ParametersJSON Schema

Name	Required	Description	Default
`sparql_query`	Yes

TDQS

A4/5.0

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.

get_metadataA

Retrieve the English label and description for a given Wikidata entity ID.

Args:
    entity_id (str): The entity ID to retrieve metadata for.
    language (str): The language code for the label and description (default is "en"). Use ISO 639-1 codes.

Returns:
    dict: A dictionary containing the label and description of the entity, if available.

ParametersJSON Schema

Name	Required	Description	Default
`entity_id`	Yes
`language`	No		en

TDQS

A4.3/5.0

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.

get_propertiesA

Get the properties associated with a given Wikidata entity ID.

Args:
    entity_id (str): The entity ID to retrieve properties for. This should be a valid Wikidata entity ID.

Returns:
    list: A list of property IDs associated with the given entity ID. If no properties are found, an empty list is returned.

ParametersJSON Schema

Name	Required	Description	Default
`entity_id`	Yes

TDQS

A3.5/5.0

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.

search_entityB

Search for a Wikidata entity ID by its query.

Args:
    query (str): The query to search for. The query should be unambiguous enough to uniquely identify the entity.

Returns:
    str: The Wikidata entity ID corresponding to the given query."

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

TDQS

B3.1/5.0

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.

search_propertyB

Search for a Wikidata property ID by its query.

Args:
    query (str): The query to search for. The query should be unambiguous enough to uniquely identify the property.

Returns:
    str: The Wikidata property ID corresponding to the given query."

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

TDQS

B3.2/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesAug 18, 2025
- First observedexecute_sparql
- First observedget_metadata
- First observedget_properties
- First observedsearch_entity
- First observedsearch_property

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.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.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

wikidata-mcp-server A
io.github.cyanheads
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
Knowledge & Memory Search Open Data
723
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Wikidata A
io.github.pipeworx-io
Wikidata MCP — wraps Wikidata API (wikidata.org/w/api.php)
Open Data Knowledge & Memory Search
352
Studex MCP ServerOAuth
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1

Related MCP Servers

Wikipedia MCP Server
Search Documentation Access RAG Systems
Rudra-ravi
A
license
B
quality
B
maintenance
A Model Context Protocol server that retrieves information from Wikipedia to provide context to LLMs, allowing users to search articles, get summaries, full content, sections, and links from Wikipedia.
Updated 4 months ago (2026-05-01 03:39 UTC)
22
291
MIT
MCP Boilerplate
RAG Systems Agent Orchestration Developer Tools
iamsrikanthnani
A
license
Not graded
quality
D
maintenance
A server that implements the Model Context Protocol, providing a standardized way to connect AI models to different data sources and tools.
Updated a year ago (2025-05-12 06:05 UTC)
15
11
MIT
MCP Wikidata Server
Search Knowledge & Memory Open Data
joelgombin
A
license
B
quality
D
maintenance
Provides access to Wikidata for Large Language Models through the Model Context Protocol, offering tools for entity search, detailed retrieval, SPARQL queries, relation exploration, and property-based searches.
Updated a year ago (2025-07-29 13:56 UTC)
5
4
MIT
MCP Wikipedia Server
Search Documentation Access
kaman05010
F
license
Not graded
quality
D
maintenance
A production-ready server that provides Wikipedia search and content retrieval tools through the Model Context Protocol, enabling AI assistants to search for articles, list sections, and retrieve specific content.
Updated a year ago (2025-08-01 10:33 UTC)
-

Appeared in Searches

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