A
license-
qualityC
maintenanceEnables querying Wikidata via SPARQL, with convenience tools for instances, subclasses, properties, and geo-spatial queries.
20
1
MIT
wikidata-mcp-server
Server Details
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/wikidata-mcp-server
- GitHub Stars
- 3
- Server Listing
- wikidata-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.5/5 across 7 of 7 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct Wikidata operation: entity retrieval, label resolution, sitelink fetching, statement extraction, external ID lookup, text search, and SPARQL querying. Descriptions clearly differentiate them with no functional overlap.
Naming Consistency5/5
All tools follow a consistent 'wikidata_verb_noun' snake_case pattern (e.g., wikidata_get_entity, wikidata_search_entities), making it easy to predict tool names.
Tool Count5/5
With 7 tools, the set is well-scoped for a Wikidata read-only interface. Each tool addresses a core need without extraneous or missing functionality.
Completeness5/5
The tool set covers all essential read operations: entity retrieval with granular field selection, label resolution, sitelinks, statements with filtering, external ID resolution, text search, and SPARQL queries. It even addresses edge cases like oversized entities and provides guidance for combining tools.
Available Tools
7 toolswikidata_get_entityGet Wikidata EntityARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Q-ID (e.g., "Q76") or P-ID (e.g., "P31"). Case-insensitive — normalized to uppercase. | |
| fields | No | Fields 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. | |
| languages | No | Language 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Normalized entity ID (e.g., "Q76" or "P31"). |
| kind | Yes | full — 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. |
| type | Yes | Entity type: "item" or "property". |
| labels | No | Map of language code to label string (e.g., {"en": "Barack Obama", "de": "Barack Obama"}). |
| aliases | No | Map of language code to list of alias strings (e.g., {"en": ["Barack H. Obama", "President Obama"]}). |
| sections | No | Present 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_type | No | Property data type (e.g., "wikibase-item", "external-id"). Present on properties only. |
| sitelinks | No | Map of site code (e.g., "enwiki") to sitelink metadata with title, url, and badges fields. |
| statements | No | Map 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. |
| descriptions | No | Map of language code to description string (e.g., {"en": "44th President of the United States"}). |
| fieldsReturned | Yes | Which fields were requested. In outline mode these are the categories the outline covers, not data returned. |
| retrieval_notice | No | Present 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. |
Tool Definition Quality
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond readOnlyHint annotation by explaining cost implications of the fields parameter, overflow behavior returning an outline, and automatic endpoint selection for P-IDs. 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?
Dense with information, but slightly lengthy. Structure is clear with key purpose upfront. Could be trimmed without losing context.
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?
Covers major behaviors: fields cost, overflow, language fallback, sibling usage. With output schema present, missing explicit mention of return structure is acceptable. Very comprehensive.
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?
Adds meaning beyond 100% schema coverage: clarifies case-insensitivity for id, cost implications for fields, and fallback behavior for languages. Enhances schema descriptions.
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 it fetches a Wikidata entity (item or property) by QID or PID. It distinguishes from sibling tools like wikidata_get_statements, which is used for deep claim traversal.
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?
Provides explicit alternatives (e.g., wikidata_get_statements for large statements) and context for when to use the fields parameter. Mentions overflow behavior. Could be more explicit about other siblings like wikidata_get_labels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wikidata_get_labelsGet Wikidata LabelsARead-onlyInspect
Resolve one or more QIDs or PIDs to their human-readable labels and descriptions. Lightweight — returns no claim data. Supports up to 50 IDs per call (batched automatically). Designed for the common agent pattern: receive QIDs from a SPARQL query, then humanize them.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Q-IDs (e.g., "Q76") or P-IDs (e.g., "P31") to resolve. 1–50 IDs per call. | |
| languages | No | BCP 47 language codes for returned labels and descriptions (e.g., ["en", "de", "fr"]). A language with no label of its own falls back to the entity's multilingual ("mul") value, returned under the requested code. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | Count of IDs that returned data. |
| entities | Yes | Map of entity ID to labels and descriptions. IDs that were not found are absent. |
| notFound | Yes | IDs from the request that did not return data (not found or invalid). |
| languages | Yes | The language codes that were requested. |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds valuable behavioral details: no claim data, automatic batching up to 50 IDs, and a typical use pattern. No contradictions.
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 very concise—three short sentences with no redundancy. Every sentence adds substantive information.
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 simple tool with a complete schema and output schema, the description covers purpose, usage pattern, and key constraints. It could mention the output format, but the output schema covers that.
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?
Schema description coverage is 100%, so the description adds limited value beyond the schema. It does note automatic batching and the 50-ID limit, which is helpful but not essential.
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 tool resolves QIDs or PIDs to human-readable labels and descriptions. It distinguishes from siblings by emphasizing its lightweight nature and focus on labels only.
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 a clear use case pattern: receiving QIDs from SPARQL and humanizing them. It implies this tool is for lightweight lookups without claim data, but does not explicitly name alternatives for other needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wikidata_get_sitelinksGet Wikidata SitelinksARead-onlyIdempotentInspect
Fetch Wikipedia and Wikimedia project article URLs for a Wikidata item. A sitelink maps a site code (e.g., "enwiki") to a Wikipedia article title and URL. Major items can have 300+ sitelinks across languages. Use sites to filter to specific language editions, or wikis_only to return only Wikipedia links. Only Q-IDs (items) have sitelinks — properties (P-IDs) do not.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Q-ID of the item (e.g., "Q76"). Only items have sitelinks; properties (P-IDs) are not supported. | |
| sites | No | Optional filter to specific site codes (e.g., ["enwiki", "frwiki", "dewiki"]). Omit to return all sitelinks. | |
| wikis_only | No | When true, return only Wikipedia sitelinks (site codes ending in "wiki", e.g., "enwiki", "dewiki"). Excludes Wikisource, Wiktionary, Wikiquote, etc. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | The Q-ID whose sitelinks were fetched. |
| count | Yes | Number of sitelinks returned. |
| message | No | Informational note when no sitelinks were found. Absent when sitelinks are present. |
| sitelinks | Yes | Map of site code to sitelink metadata. Empty when the entity has no matching sitelinks. |
Tool Definition Quality
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by noting that major items can have 300+ sitelinks, warning about large outputs. It also explains the sitelink structure (site code -> title/URL), which is beyond what annotations provide.
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 four sentences, each adding distinct value. It is front-loaded with the main purpose, then explains the sitelink concept, scale, filtering, and a key limitation. No redundant or irrelevant content.
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?
Given the simple tool with only 3 parameters, annotations covering safety, and an output schema present, the description is complete. It covers purpose, filtering, and the Q-ID requirement. No obvious gaps.
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?
Schema coverage is 100%, so baseline is 3. The description reinforces the usage of 'sites' and 'wikis_only' with examples, but adds minimal new information beyond the schema descriptions. The explanation of id restriction (Q vs P) is helpful but not extensive.
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 verb 'Fetch', the resource 'Wikipedia and Wikimedia project article URLs', and the target 'a Wikidata item'. It distinguishes from sibling tools like wikidata_get_entity or wikidata_get_labels by focusing specifically on sitelinks.
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 explains when to use the tool (for Q-IDs) and when not (P-IDs). It also describes filtering options ('sites', 'wikis_only'), providing context on usage without naming siblings. The limitation about items vs properties is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wikidata_get_statementsGet Wikidata StatementsARead-onlyIdempotentInspect
Fetch property claims for a Wikidata entity with qualifier and reference detail. Value QIDs are resolved to human-readable labels by default. Use the properties parameter to fetch only specific P-IDs — omitting it returns every statement, and a well-connected item (a country, a major city) carries hundreds of properties: more than fits inline. An oversized set comes back as kind: "outline" — every available P-ID with its byte size, largest first — instead of the statements; re-call with the same id plus properties:[...] naming the P-IDs you want. Designed for fact verification: "what does Wikidata say about this entity's {property}?". Preferred-rank statements are the most current values.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Q-ID (e.g., "Q76") or P-ID of the entity to fetch statements for. | |
| language | No | Language code for label resolution of QID values (e.g., "en", "de"). | en |
| properties | No | P-IDs to fetch (e.g., ["P31", "P569", "P27"]). Omit to return all properties (may be large for major items). | |
| resolve_labels | No | Resolve wikibase-item value QIDs to human-readable labels via a batched label call. Set to false to skip label resolution and return raw QIDs only (faster, smaller payload). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | The entity ID whose statements were fetched. |
| kind | Yes | full — statements carries the claims. outline — the statement set overflowed the inline byte budget, so sections lists the P-IDs available instead; re-call with properties:[...] to retrieve specific ones. The counts below are reported either way. |
| sections | No | Present when kind = outline: the P-IDs this entity carries statements for, largest first. Copy names into the properties input to retrieve them. |
| statements | No | Map of property ID to array of normalized statements. Each statement has id, rank, property, value (with type-specific fields), and optional qualifiers and references arrays. Present in full mode; omitted in outline mode. |
| propertyCount | Yes | Number of distinct properties — those returned in full mode, those offered as sections in outline mode. |
| labelsResolved | Yes | True when QID values were resolved to labels. False when resolve_labels was set to false. |
| statementCount | Yes | Total number of statement objects across all properties. Counted before any overflow, so it reports the entity's full statement volume in both modes. |
| retrieval_notice | No | Present when kind = outline: how to re-call for specific properties. |
Tool Definition Quality
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already note readOnlyHint, openWorldHint, idempotentHint. The description adds context: label resolution default, outline behavior for large sets, and preferred-rank statements being most current. No contradictions.
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?
All sentences are informative and logically flow from purpose to behavior to parameters. Could trim slightly, but every sentence earns its place.
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?
With output schema present, description need not detail return values. It covers the key nuance (outline) and default behaviors. Sufficient for a tool with moderate 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?
Schema covers 100% of parameters. Description adds meaning beyond schemas: explains properties parameter can lead to outline, language affects label resolution, resolve_labels toggles default behavior. This provides decision-making context.
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 'Fetch property claims for a Wikidata entity with qualifier and reference detail.' This verb+resource pair is specific and distinct from sibling tools like wikidata_get_entity (entity basics) and wikidata_get_labels (labels only).
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 positions the tool for fact verification and explains when to omit vs specify properties, including the outline fallback. It does not directly contrast with siblings but implies their distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wikidata_resolve_external_idResolve Wikidata External IDARead-onlyInspect
Look up a Wikidata entity by an external identifier such as a DOI, PubMed ID, ORCID iD, or OpenAlex ID. Returns match= on success, match=null when not found, and match=null with multipleMatches populated when a Wikidata data integrity issue causes more than one entity to claim the same external ID. Common cross-server join use cases: CrossRef DOI → Wikidata paper QID (P356), PubMed PMID → Wikidata paper QID (P698), ORCID → author QID (P496), OpenAlex ID → entity QID (P10283). The property must be one whose Wikidata data type is external-id — item-valued or media properties (e.g. P31 instance-of, P18 image) are rejected rather than returning an empty match. Known value normalization is applied automatically: surrounding whitespace is trimmed, identifier-resolver URL prefixes are stripped (https://doi.org/, https://pubmed.ncbi.nlm.nih.gov/, https://orcid.org/), DOIs are uppercased, PMID prefixes stripped, ORCID hyphens normalized.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The external identifier value to look up (e.g., "10.1038/nature01234" for a DOI, "32283226" for a PubMed ID, "0000-0002-1825-0097" for an ORCID). A resolver URL is accepted for DOI, PubMed, and ORCID — the prefix is stripped before lookup. | |
| language | No | Language code for label and description in the response (e.g., "en", "de"). | en |
| property | Yes | P-ID of the external identifier property, whose Wikidata data type must be external-id (e.g., "P356" for DOI, "P698" for PubMed ID, "P496" for ORCID, "P10283" for OpenAlex ID, "P345" for IMDb ID). Properties of any other data type are rejected — check an unfamiliar P-ID's data type with wikidata_get_entity. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| match | Yes | Matching entity, or null when no Wikidata entity claims this external identifier (including the case where multipleMatches is populated). A null match is not proof of absence — the Query Service backing this lookup lags the live wiki, so a recently added identifier may not be indexed yet. |
| value | Yes | The normalized value that was searched (may differ from input due to canonicalization). |
| property | Yes | The P-ID used for the lookup. |
| multipleMatches | No | Present when more than one Wikidata entity claims this external ID (data integrity issue). match is null when this field is present. Inspect the list and select the correct QID manually. |
Tool Definition Quality
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral details beyond annotations: return states (match=entity, null, multipleMatches), value normalization (trimming whitespace, stripping URL prefixes, uppercasing DOIs, normalizing ORCID hyphens), and handling of data integrity issues. This fully informs the agent of the tool's behavior.
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 a single coherent paragraph that packs significant detail without redundancy. It is front-loaded with the purpose and then covers return values, use cases, constraints, and normalization. It is comprehensive yet efficient.
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?
Given the tool's complexity (external ID resolution with normalization and integrity handling), the description covers all key aspects: input format, return states, property type constraints, normalization rules, and common use cases. With full schema coverage and an output schema present, no critical gaps remain.
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?
Schema coverage is 100%, but the description enriches each parameter with examples and normalization rules (e.g., value accepts resolver URLs, property must be external-id type, language defaults to 'en'). This adds value beyond the schema descriptions.
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 looks up Wikidata entities by external identifiers and lists concrete use cases (DOI, PubMed, ORCID, OpenAlex). It implicitly distinguishes from siblings by focusing on external-ID resolution rather than QID lookups or searches.
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 explicit when-to-use guidance through common use case examples and specifies that only external-id type properties are accepted (rejecting item-valued or media properties). It could be improved by explicitly contrasting with sibling tools like wikidata_get_entity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wikidata_search_entitiesSearch Wikidata EntitiesARead-onlyInspect
Search Wikidata for items or properties by text query. Returns QIDs or PIDs with labels, descriptions, and match metadata indicating whether the hit was on a label or alias. Use type="item" for real-world concepts (people, places, works) and type="property" to find predicate P-IDs. The API returns no total count — pagination is offset-based with no result ceiling indicator.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Entity type to search. Use "item" for Q-IDs (people, places, concepts) or "property" for P-IDs (predicates). | item |
| limit | No | Maximum number of results to return. Range: 1–50. | |
| query | Yes | Search terms to match against entity labels, aliases, and descriptions. | |
| offset | No | Pagination offset. Start at 0; increment by limit to page through results. | |
| language | No | BCP 47 language code for returned labels and descriptions (e.g., "en", "de", "zh"). | en |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| cap | Yes | The limit parameter in effect. |
| shown | Yes | Number of results returned on this page. |
| notice | No | Recovery hint when results are empty — echoes filters and suggests how to broaden. Absent when results are present. |
| results | Yes | Ranked list of matching entities. Empty when no results found. |
| language | Yes | The language used for label and description display. |
| truncated | No | True when results were capped at the limit. The Wikidata search API returns no total count — use offset pagination to retrieve more. |
| searchType | Yes | The entity type that was searched ("item" or "property"). |
| effectiveQuery | Yes | The search query that was executed. |
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) declare safety and non-exhaustive results. The description adds behavioral details: match metadata (label vs alias hits), no total count, offset-based pagination with no ceiling indicator. This complements annotations without contradiction.
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 concise (4 sentences), front-loaded with the action, and every sentence adds unique value: purpose, type distinction, pagination behavior. No redundancy or fluff.
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?
Given the availability of an output schema and comprehensive annotations, the description covers search functionality, type differentiation, result metadata, pagination, and language support. It is complete for a search tool.
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%, providing parameter descriptions. The description adds contextual semantics: clarifies `type` usage with real-world examples, explains `offset` pagination logic, and gives language code examples. This goes beyond schema basics.
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 tool searches Wikidata for items or properties by text query, specifies the return format (QIDs/PIDs with labels, descriptions, and match metadata), and distinguishes between item and property types. This specificity and action-resource pairing align with a high score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use `type="item"` vs `type="property"` with examples, and explains pagination behavior (offset-based, no total count). This directly tells the agent how to use the tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wikidata_sparql_queryWikidata SPARQL QueryARead-onlyInspect
Execute a SPARQL SELECT query against the Wikidata Query Service. Full graph power: multi-hop traversals, aggregations, subqueries, OPTIONAL, FILTER, UNION, BIND. Standard Wikidata prefixes (wd:, wdt:, p:, ps:, pq:, wikibase:, bd:) are auto-injected. The wikibase:label SERVICE is also auto-injected when language is set and the query includes ?Label variables — so you can use ?itemLabel without writing the boilerplate. Hard server timeout is 60s; use LIMIT to keep queries fast. Bindings use the SPARQL 1.1 JSON format: each value is { type, value, "xml:lang"? }. Use wikidata_get_labels to humanize QID results from this tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SPARQL SELECT query. Must be a SELECT query (not CONSTRUCT/DESCRIBE/ASK). Standard prefixes (wd:, wdt:, p:, ps:, pq:, wikibase:, bd:) are injected automatically. Example: SELECT ?item ?itemLabel WHERE { ?item wdt:P31 wd:Q146. } LIMIT 10 | |
| timeout | No | Client-side timeout in seconds (1–55). Capped at 55s — the Wikidata server hard limit is 60s. | |
| language | No | Language for the wikibase:label SERVICE (e.g., "en", "de"). Controls the language of ?<var>Label variables. Set to "" to suppress label SERVICE injection. | en |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Recovery hint when no results returned — suggests checking query logic or broadening filters. Absent on non-empty results. |
| results | Yes | Array of result bindings. Each row maps variable names to binding objects with { type, value, "xml:lang"?, datatype? } fields. |
| truncated | Yes | True when the row count equals 10,000 — the Wikidata/Blazegraph server-side cap — indicating the result set was likely truncated. False otherwise. Add a LIMIT clause to avoid hitting the cap. Note: the SPARQL endpoint does not expose an explicit truncation flag; this is an inferred signal. |
| variables | Yes | Variable names returned by the SELECT clause. |
| totalCount | Yes | Number of result rows returned. |
Tool Definition Quality
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description discloses the hard server timeout of 60s, auto-injection of prefixes and the label SERVICE, and the SPARQL 1.1 JSON response format with example structure. It also explains the client-side timeout cap and language parameter behavior.
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 purpose and well-structured, with each sentence adding relevant detail. It is slightly verbose but not wasteful.
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 complexity of a SPARQL query tool with 3 parameters and full schema coverage, the description covers response format, timeout behavior, and label injection. It is complete enough for effective 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?
Schema coverage is 100%, but the description adds significant value by explaining auto-injection of prefixes and label SERVICE, the timeout cap relative to server limit, and the language parameter's role in label SERVICE injection.
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 'Execute a SPARQL SELECT query against the Wikidata Query Service', specifying the verb (execute) and resource (SPARQL SELECT query). It distinguishes itself from sibling tools like wikidata_get_entity and wikidata_get_labels by focusing on arbitrary SPARQL queries.
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 context for when to use the tool (full graph power) and explicitly directs users to wikidata_get_labels for humanizing QID results. It advises using LIMIT for speed but does not explicitly exclude other cases or compare with siblings like wikidata_get_statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseBqualityDmaintenanceProvides 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.54MIT
- Flicense-qualityDmaintenanceConnects LLMs to Wikidata's structured knowledge base using a hybrid architecture that optimizes for both fast entity searches and complex relational queries. It provides tools for entity and property retrieval, metadata lookups, and direct SPARQL execution to ground AI responses in verified data.2
- Flicense-qualityDmaintenanceEnables searching and retrieving Wikipedia content across multiple languages, including article summaries, sections, coordinates, and related topics.
Try in Browser
Your Connectors
Sign in to create a connector for this server.