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
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Tool Definition Quality
Average 4.6/5 across 7 of 7 tools scored.
Each tool targets a distinct operation: entity fetching, label resolution, sitelinks, statements, external ID lookup, search, and SPARQL queries. No overlap in functionality.
All tools follow the 'wikidata_verb_noun' pattern using snake_case. Verbs are consistently imperative (get, resolve, search, query) and nouns clearly describe the resource or action.
Seven tools provide comprehensive coverage of Wikidata's core querying capabilities without being excessive. Each tool serves a clear, non-redundant purpose.
The set covers all major read-only Wikidata operations: entity retrieval with field filtering, label resolution, sitelinks, statements with qualifiers, external ID resolution, text search, and SPARQL. No obvious gaps for a read-only surface.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description goes beyond annotations (readOnlyHint, openWorldHint) by explaining cost behavior of fields parameter, overflow mechanism ('outline' return), automatic Q/P endpoint selection, and fallback behavior for languages. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is informative, but the description is relatively long. It is well-structured with front-loaded purpose and subsequent details, though a few sentences could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no enums, output schema exists), the description covers purpose, usage guidelines, parameter details, behavioral transparency, and sibling differentiation. It addresses overflow, cost, endpoint selection, and provides actionable retrieval advice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds significant value: for 'fields', explains it narrows upstream fetch and cost implications; for 'id', notes case-insensitivity and normalization; for 'languages', explains fallback to 'mul' value. Each parameter gets concrete behavioral context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch a Wikidata entity (item or property) by QID or PID.' Specifies the resource (entity) and action (fetch). Distinguishes from siblings by noting that get_statements is 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs. alternatives: 'Use wikidata_get_statements for deep claim traversal with label resolution, and whenever an entity's statements are large.' Also provides guidance on handling oversized entities with retrieval_notice and fields parameter.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds beyond: 'lightweight', 'returns no claim data', 'supports up to 50 IDs per call (batched automatically)'. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and constraints, zero wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and the tool is simple, the description covers all necessary behavioral context: limits, batching, language fallback. No gaps for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds contextual value: clarifies ID range (1–50) and language fallback behavior (fallback to 'mul' under requested code).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves QIDs/PIDs to labels and descriptions, explicitly distinguishes from siblings by noting 'returns no claim data', and frames it within a common agent pattern (SPARQL query then humanize).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 ('receive QIDs from a SPARQL query, then humanize them') and implies when not to (if claim data is needed, use other tools). However, it does not explicitly name alternative sibling tools.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description adds behavioral context: major items can have 300+ sitelinks (performance hint) and the mapping between site codes and URLs. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, front-loaded with the action verb, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers purpose, data structure, filtering, and limitations. No gaps remain for an agent using this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds meaning by explaining the sitelink concept, clarifying that only Q-IDs work, and suggesting use of filtering parameters (sites, wikis_only).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches Wikipedia and Wikimedia project URLs for a Wikidata item, using specific verbs and distinguishing the resource (sitelinks) from siblings like wikidata_get_entity or wikidata_get_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to get article URLs) and explicitly states that properties (P-IDs) do not have sitelinks, guiding agents away from invalid inputs. It also describes filtering options but does not directly compare to sibling tools.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: value QIDs resolved to labels by default, oversized sets return as outline with byte sizes requiring re-call, preferred-rank statements as most current. No contradiction with annotations (readOnlyHint, openWorldHint, idempotentHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive. Critical information is front-loaded: first sentence gives core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given parameter count (4) and output schema existence, the description adequately covers behavior for all parameters, mentions edge cases (oversized outline), and provides usage context. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value: explains that omitting properties returns all statements (potentially large), and effects of resolve_labels (faster, smaller payload). However, language parameter default behavior is not elaborated beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches property claims for a Wikidata entity, with qualifier and reference detail. It distinguishes from sibling tools like wikidata_get_entity (entity metadata) and wikidata_get_labels (labels only) by focusing on statements and mentions QID-to-label resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Designed for fact verification: "what does Wikidata say about this entity's {property}?"'. Also explains when not to use (omitting properties may return huge outline) and how to handle oversized results (re-call with properties).
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses rich behavioral details beyond annotations: return formats (match=<entity>, match=null, multipleMatches), data integrity issues causing multiple matches, and known value normalization (whitespace trimming, URL stripping, case normalization). Annotations only provide readOnlyHint and openWorldHint, so the description carries the full burden and excels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: start with purpose, then return formats, use cases, constraints, and normalization. It is front-loaded with key info. However, it is slightly verbose; could be more concise without losing essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (edge cases: multiple matches, rejected properties, normalization), the description is complete. It covers return values despite having an output schema, and provides all necessary context for an AI to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description adds significant meaning beyond the schema: examples for each parameter, validation rules (e.g., value normalization, property type restriction), and default language. For instance, it explains that a resolver URL is accepted for DOI/PubMed/ORCID and that the property must be external-id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: look up a Wikidata entity by an external identifier such as DOI, PMID, ORCID, or OpenAlex ID. It distinguishes from sibling tools like wikidata_get_entity (which uses QID) and wikidata_search_entities (text search) by focusing on external ID resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists common use cases and explicitly states that properties must be of external-id data type; other types are rejected. It implicitly differentiates from alternatives like wikidata_get_entity for QIDs, but lacks an explicit 'when not to use' statement.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations, such as the lack of total count, offset-based pagination with no result ceiling, and the match metadata field. This complements the readOnlyHint and openWorldHint 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary purpose. Every sentence contributes essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the output format, pagination, and parameter usage adequately. Given the existence of an output schema and annotations, it is sufficiently complete, though it could mention authentication or rate limits if applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by explaining the use case for the 'type' parameter and clarifying pagination behavior (offset and limit). This provides meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 and returns QIDs/PIDs with labels, descriptions, and match metadata. It distinguishes itself from sibling tools like wikidata_get_entity by focusing on searching rather than retrieving specific entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on using the 'type' parameter for items vs. properties and explains pagination behavior (offset-based, no total count). However, it does not directly compare with siblings or specify when not to use this tool.
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.
| 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
| 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
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by disclosing auto-injection of prefixes, the label SERVICE injection behavior, 60s server timeout, and the SPARQL 1.1 JSON response format, going 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement, then provides relevant details in a structured manner. It is concise but thorough, avoiding redundancy while covering essential aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of SPARQL queries, the description covers query type, auto-injected features, timeout limits, response format, and post-processing. The presence of an output schema does not negate the need for this information, and the description is complete enough for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds meaning by explaining how the language parameter controls label SERVICE injection and how timeout is capped at 55s per server limits. It also notes that prefixes are auto-injected, which is not manifest from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes SPARQL SELECT queries against Wikidata Query Service, specifying supported operations and auto-injected features. It is differentiated from sibling tools like wikidata_get_labels and wikidata_search_entities by focusing on direct SPARQL execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies use for complex queries requiring full graph power, but does not mention alternatives or exclusionary criteria. A brief note about using wikidata_get_labels for humanizing results hints at complementary usage.
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!