wikipedia-mcp-server

Search Wikipedia

wikipedia_search_articles

Read-only

Search Wikipedia articles by full-text query. Returns ranked results with plain-text titles, snippets (HTML stripped), page IDs, and word counts. Best when the exact article title is unknown or when multiple articles on a topic are needed. Pass a result title to wikipedia_get_summary, wikipedia_get_article, or wikipedia_get_sections for follow-up reads. Use offset to page beyond the first result page. Supports all Wikipedia language editions.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results to return per page (default 10, max 50). Must be a positive integer.
`query`	Yes	Search query (e.g. "Python programming language"). Must not be empty.
`offset`	No	Result offset for pagination (default 0). Pass the nextOffset from a previous response to fetch the next page; limit still governs the per-page size. An offset past the total match count returns an empty result array, not an error. Wikipedia serves no result past 10,000, so an offset at or beyond that fails — narrow the query instead.
`language`	No	Wikipedia language edition code (default "en"). Examples: "fr", "de", "ja".	en

Output Schema

TableJSON Schema

Name	Required	Description
`cap`	No	The result ceiling that cut this page — the search window. Present only alongside truncated.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Number of results returned on this page.
`notice`	No	Guidance when no results matched, when the end of results was reached while paging, or when the page was cut at the search window. Absent on ordinary result pages.
`offset`	No	The result offset applied to this page (echo of the input).
`results`	No	Ranked search results.
`language`	No	Language edition queried.
`truncated`	No	True when this page was cut at Wikipedia's 10,000-result search window and totalCount matches remain that no offset can reach. Absent on every other page, including a genuine last page.
`nextOffset`	No	Offset to request the next page. Present only when more results remain — pass it back as offset to continue; absent at the end of results.
`totalCount`	No	Total matching results in Wikipedia.
`effectiveQuery`	No	The query sent to Wikipedia.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 17, 2026

changedInput schema / properties / limit / maximum

Previous value: -9007199254740991New value: +50

changedInput schema / properties / offset / description

Previous value: -"Result offset for pagination (default 0). Pass the nextOffset from a previous response to fetch the next page; limit still governs the per-page size. An offset past the total match count returns an empty result array, not an error."New value: +"Result offset for pagination (default 0). Pass the nextOffset from a previous response to fetch the next page; limit still governs the per-page size. An offset past the total match count returns an empty result array, not an error. Wikipedia serves no result past 10,000, so an offset at or beyond that fails — narrow the query instead."

changedInput schema / properties / query / description

Previous value: -"Search query (e.g. \"Python programming language\")."New value: +"Search query (e.g. \"Python programming language\"). Must not be empty."

addedOutput schema / properties / cap

Added value: +{
+  "description": "The result ceiling that cut this page — the search window. Present only alongside truncated.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

changedOutput schema / properties / error / properties / data / properties / reason / description

Previous value: -"Machine-readable failure mode. Declared by this tool: `invalid_language`: The language is not a valid BCP 47 code, or names a Wikipedia edition that does not exist. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `empty_query`: The query is an empty string, which Wikipedia reads as a missing parameter. `offset_too_large`: The offset is at or past the search window, which has no continuation. `invalid_language`: The language is not a valid BCP 47 code, or names a Wikipedia edition that does not exist. Other values are possible when a failure originates below the handler."

changedOutput schema / properties / error / properties / data / properties / reason / examples

Previous value: -[
-  "invalid_language"
-]New value: +[
+  "empty_query",
+  "offset_too_large",
+  "invalid_language"
+]

changedOutput schema / properties / notice / description

Previous value: -"Guidance when no results matched — e.g. try different keywords, or that the end of results was reached when paging. Absent on successful result pages."New value: +"Guidance when no results matched, when the end of results was reached while paging, or when the page was cut at the search window. Absent on ordinary result pages."

addedOutput schema / properties / truncated

Added value: +{
+  "description": "True when this page was cut at Wikipedia's 10,000-result search window and totalCount matches remain that no offset can reach. Absent on every other page, including a genuine last page.",
+  "type": "boolean"
+}

First observedSep 17, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and openness. The description adds value by specifying the exact output fields ('plain-text titles, snippets (HTML stripped), page IDs, and word counts') and the follow-up tool integration. It does not mention rate limits or error behavior beyond what the schema covers, but given the annotations, this is sufficient for a read-only search 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 three sentences with no filler. It front-loads the core purpose and output, then provides routing and pagination guidance. Every sentence earns its place—purpose, output, and usage context are all packed efficiently without redundancy.

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?

For a search tool with four parameters, an output schema, and read-only annotations, the description covers all critical aspects: what it does, what results look like, when to use it, how to follow up, and how to paginate. The only omission (the 10,000-result cap) is already documented in the offset parameter's schema description, so the description need not repeat it.

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 every parameter is already documented in the input schema. The description adds minimal new parameter meaning—it mentions the offset usage but essentially repeats what the schema's offset description states. The baseline of 3 applies because the schema does the heavy lifting; the description doesn't need to compensate.

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 states a specific verb-resource pair: 'Search Wikipedia articles by full-text query.' It clearly differentiates from siblings by explaining it is best when the exact article title is unknown or multiple articles are needed, which contrasts with the retrieval-oriented sibling tools (wikipedia_get_article, etc.). This leaves no ambiguity about the tool's role.

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?

It explicitly names the ideal conditions ('Best when the exact article title is unknown or when multiple articles on a topic are needed') and provides follow-up routing ('Pass a result title to wikipedia_get_summary, wikipedia_get_article, or wikipedia_get_sections'). It also gives pagination guidance ('Use offset to page beyond the first result page') and notes language support. This gives the agent clear when-to-use and how-to-chain instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All wikipedia-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.