WI
Search

Wikidata MCP Server: Identifier Search, Metadata & SPARQL

Query the Wikidata MCP server to search identifiers, extract metadata, and run SPARQL queries for fast, programmable data access.

View on GitHub
Quick Install
npx -y @zzaebok/mcp-wikidata

Overview

The Wikidata MCP Server implements a lightweight Model Context Protocol (MCP) front-end for Wikidata. It provides fast, programmatic access to three common developer needs: identifier search (find the best Wikidata Q-IDs for free-text input), entity metadata extraction (get labels, descriptions, aliases and key facts), and running SPARQL queries against Wikidata. The server is designed to be used by applications that need deterministic, low-latency knowledge retrieval to build prompts, fact-check outputs, or augment language models with structured context.

Because the server centralizes search, metadata normalization, and SPARQL execution behind a small HTTP API, it simplifies integrations for retrieval-augmented generation (RAG), tool-backed agents, and data pipelines that require canonical Wikidata identifiers and quick metadata snippets.

Features

  • Identifier search: fuzzy and language-aware lookup of Wikidata entities from free-text input.
  • Metadata extraction: normalized labels, descriptions, aliases, sitelinks, and a compact set of properties for an entity.
  • SPARQL proxy: run arbitrary SPARQL queries against Wikidata with JSON results and caching.
  • Simple HTTP API: JSON responses, pagination, and query parameters for language, limit, and format.
  • Caching layer: reduce load on Wikidata/SPARQL endpoint and improve latency for repeated queries.
  • Container-ready: can run locally or in production via Docker.

Installation / Configuration

Clone and run the server locally using Docker or Python. Example options are below.

Using Docker (recommended):

git clone https://github.com/zzaebok/mcp-wikidata.git
cd mcp-wikidata

# Build image
docker build -t mcp-wikidata .

# Run (example: port 8080)
docker run -p 8080:8080 \
  -e WD_SPARQL_ENDPOINT="https://query.wikidata.org/sparql" \
  -e CACHE_TTL=3600 \
  mcp-wikidata

Run from source (Python):

git clone https://github.com/zzaebok/mcp-wikidata.git
cd mcp-wikidata
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt

# Environment variables (example)
export WD_SPARQL_ENDPOINT="https://query.wikidata.org/sparql"
export PORT=8080
python app.py

Configuration options (typical):

  • WD_SPARQL_ENDPOINT — SPARQL endpoint URL (default: Wikidata public endpoint)
  • PORT — HTTP port to listen on (default: 8080)
  • CACHE_TTL — seconds to cache SPARQL and search responses
  • LOG_LEVEL — logging verbosity

Available Resources

The server exposes a few core HTTP endpoints. Example paths and query parameters:

MethodPathQuery paramsDescription
GET/searchq, lang, limitSearch identifiers by text; returns candidate entities with id, label, description, score
GET/metadataid, langFetch normalized metadata for a Wikidata id (e.g., Q42)
POST/sparql(none)Execute a SPARQL query; body contains query string (application/sparql-query or JSON)
GET/health(none)Health check and basic metrics

Example: search for “Alan Turing” (curl)

curl "http://localhost:8080/search?q=Alan%20Turing&limit=5&lang=en"

Example: retrieve metadata for Q42 (Douglas Adams)

curl "http://localhost:8080/metadata?id=Q42&lang=en"

Example: run a SPARQL query

curl -X POST http://localhost:8080/sparql \
  -H "Content-Type: application/sparql-query" \
  --data 'SELECT ?item ?itemLabel WHERE { ?item wdt:P31 wd:Q5 . } LIMIT 10'

Response formats are JSON and follow simple, predictable structures:

  • /search: list of { id, label, description, aliases, score }
  • /metadata: { id, labels, descriptions, aliases, claims, sitelinks }
  • /sparql: SPARQL JSON results (bindings)

Use Cases

  • Retrieval-augmented generation (RAG): Resolve ambiguous entity mentions into canonical Wikidata QIDs, fetch short metadata, and include as context to an LLM prompt.
  • Fact-checking & veracity checks: Map claims to entity IDs and run SPARQL to verify properties or provenance quickly.
  • Tooling for agents: Agents that need to call knowledge APIs can use the /search endpoint to choose the right entity and then fetch structured facts with /metadata or /sparql.
  • Data enrichment pipelines: Batch mapping of external identifiers or names to Wikidata QIDs and extracting key attributes (dates, types, identifiers) for downstream analytics.
  • Interactive discovery: Build small UI widgets that power autosuggest, entity inspectors, and detail panes using the API.

Tips & Best Practices

  • Cache aggressively at the application layer: while the server includes its own caching, client-side caching for frequently requested entities reduces latency and SPARQL load.
  • Use language hints (lang param) to get localized labels and descriptions.
  • Limit SPARQL queries and prefer concise queries to avoid hitting public endpoint rate limits; consider running a private Wikidata query service for heavy workloads.
  • Validate and sanitize user input before incorporating into SPARQL queries to avoid injection-style issues.

This server is a compact, developer-focused bridge between application code and Wikidata knowledge, optimized for predictable identifier resolution and fast retrieval of entity context.

Tags:search