wikipedia-mcp-server

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

Annotations only provide readOnlyHint and openWorldHint. The description goes far beyond by disclosing behavior under size budget (truncated: true with a compact outline), omission of data tables and page furniture, retention of hatnotes, and automatic redirect following. This describes what the agent will actually receive and what gets discarded, providing rich behavioral context.

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 long but every sentence adds unique value. It is front-loaded with the core action and then systematically covers modes, truncation, table handling, furniture, and redirects without redundancy. The structure logically flows from general behavior to edge cases, and the length is justified by the tool's complexity.

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 (multiple modes, truncation, omission behaviors) and the availability of an output schema, the description covers all critical aspects: when truncation occurs, what the fallback is, what is omitted, what is kept, and how redirects are handled. It also ties into sibling tools, leaving no gap in an agent's ability to decide when and how to call it.

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 description coverage is 100%, so the schema already documents all parameters. The description adds extra nuance, especially for section_index (0 meaning lead, nested subsections behavior) and title character restrictions. While the description does not spell out the language parameter format beyond schema, it meaningfully enriches the two most behaviorally complex parameters, so it earns above the baseline of 3.

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 states a specific verb ('Fetch') and resource ('article content') as clean plain text, and clearly distinguishes between the full-article mode and the section-targeted mode. It also references sibling tools (wikipedia_get_sections, wikipedia_get_summary) with explicit contrasts, so an agent can tell them apart immediately.

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 gives explicit when-to-use guidance: it explains when section_index should be used ('faster and smaller when only part of the article is needed'), the truncation fallback to sections plus a section_index read, and clarifies that the summary tool returns only a truncated fragment of the lead, implying this tool is needed for full prose. No alternative tool is left ambiguous.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behaviors: redirects are followed automatically, source_title reports the resolved article, missing edition codes are returned under a missing field, and total_languages still reports the full count. This gives the agent a clear picture of edge-case behavior.

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 the core action and return value, then adds use-case context and behavioral details. Every sentence contributes useful information without fluff or repetition of the schema.

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?

With an output schema, read-only annotations, and detailed parameter documentation in the schema, the description is complete for an agent to select and invoke the tool correctly. It covers redirect handling, missing codes, total count, and the language edition behavior, leaving no material 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?

The schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics around editions, such as case-insensitive matching, the missing field behavior, and the fact that total_languages reflects the full count, going beyond the schema text.

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 states a specific verb and resource: "List the language editions available for a Wikipedia article," and enumerates the returned data (language codes, titles, URLs). This clearly distinguishes it from siblings like wikipedia_get_article and wikipedia_get_sections, which serve different purposes.

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?

It gives clear context: use it for cross-language research and for discovering the correct article title in a target language before fetching it. It explains when narrowing with editions is useful, but it does not explicitly state when not to use this tool or name the alternative sibling to prefer in other cases.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds substantive behavioral details: the exact fields returned (titles, levels, numbering, section_index), the inclusion of the lead section at index 0, and automatic redirect following. These go well beyond the annotations and inform the agent of edge-case behavior.

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 efficiently structured: it opens with the main action and return types, then clarifies the lead-section nuance, then provides a usage pointer, and finally a note on redirects. Each sentence earns its place, though it is slightly dense with detail.

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 presence of an output schema (indicated), the description covers all necessary operational context: what is returned, how the lead section is handled, how to retrieve a specific section, and redirect behavior. No critical gaps remain for an agent to call it 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?

The schema already describes both parameters (title and language) with 100% coverage, including examples and constraints. The description adds no additional parameter-specific semantics beyond referencing section_index, which is a return value rather than an input. Baseline of 3 is appropriate since the schema carries the load.

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 uses a specific verb 'Fetch' and a clear resource 'table of contents for a Wikipedia article'. It also names the sibling 'wikipedia_get_article' and explains how sections relate to it, making the tool's distinct role unambiguous.

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?

It explicitly states the tool is useful for enumerating article structure before a targeted section read, and directly instructs passing a section_index to wikipedia_get_article to retrieve that section. This gives clear when-to-use guidance and a pointer to the alternative.

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

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

Adds substantial behavior beyond the readOnlyHint/openWorldHint annotations: extract is a truncated fragment (as little as a tenth of the lead), redirects are followed automatically, and disambiguation page_type handling is explained. This gives the agent operational expectations not present in structured data.

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 earns its place: primary purpose first, then output-content detail, then sibling routing. The flow is logical and free of filler; even the longer sentence about returned fields packs necessary information.

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?

For a 2-parameter tool with a rich output schema, the description covers all an agent needs: what the extract is, redirect behavior, disambiguation handling, the full-lead alternative, and preference over siblings. Nothing required for correct invocation is missing.

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% and both parameters (title, language) are already fully described in the input schema. The description adds contextual usage (e.g., redirects, page_type) but no new parameter-level semantics, so the baseline of 3 applies.

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?

States a specific verb ('Fetch'), resource ('short article summary'), and purpose ('what is X?'). Explicitly distinguishes this from wikipedia_get_article, wikipedia_search_articles, and wikipedia_search_nearby, so an agent can tell them apart immediately.

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?

Gives explicit when-to-use vs alternatives: 'For the lead section in full, call wikipedia_get_article with section_index 0', 'When page_type is disambiguation... call wikipedia_search_articles', and 'Prefer this over wikipedia_get_article unless article depth is needed'. Also notes lat/long feeds wikipedia_search_nearby. Nothing is left to inference.

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

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.

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.

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.

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.

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.

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.

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the description's job is to add context beyond that. It discloses the geotag requirement (only articles with coordinates), which is a non-obvious behavior, and describes the sort order and return fields. This adds value without contradicting the 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?

Two sentences, front-loaded with the core purpose and return details, then a concise usage hint and caveat. Zero fluff; every clause earns its place.

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?

With a rich schema covering all parameters and an output schema present, the description covers the essential behavioral aspects: what it returns, sorting, and the geotag limitation. Annotations handle safety and open-world expectations. An agent has everything needed to call this tool 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?

Schema description coverage is 100% — every parameter (limit, language, latitude, longitude, radius_meters) has a detailed description with defaults, ranges, and constraints. The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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?

States a specific verb (Find) and resource (Wikipedia articles) with a clear scope (near a geographic coordinate), and explicitly describes the output (titles, page IDs, coordinates, distance in meters). This clearly distinguishes it from text-based search tools like wikipedia_search_articles and article retrieval like wikipedia_get_article.

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?

Provides a clear use case ('what is notable near X?' research workflows) and notes a key limitation (only articles with coordinates in Wikidata are returned). However, it does not explicitly name alternatives or state when not to use it, relying on the purpose to imply context.

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