Skip to main content
Glama

wikipedia

by io.github.pipeworx-io

Get Article Extract

get_article_extract
Read-onlyIdempotent

Full text of a Wikipedia article by title — the ACTUAL prose AND its tables, not just the lead paragraph. This is how you read a competition schedule, fixture list, medal table, results grid or roster: get_article_extract({title: "Table tennis at the 2026 Asian Games"}) returns the venue, the dates and the day-by-day event schedule. Answers "when is at ", "what are the dates", "who won ", "explain X in detail", "what does the article say about ", reading the history/methods/etc. CALL IT DIRECTLY when the title is predictable from the question — Wikipedia titles are regular, so "when is table tennis at the Asian Games" is the article "Table tennis at the 2026 Asian Games", and the same pattern gives "Athletics at the 2028 Summer Olympics", "India at the 2026 Asian Games", "2026 FIFA World Cup". Constructing the title and reading the article beats searching first, because the search snippet is one truncated line and this returns the whole thing. Titles are exact: on a miss you get a user_error naming search_wikipedia as the recovery. PREFER OVER get_article_summary whenever the lead paragraph is not enough. Omit section for the whole article (capped by max_chars); pass a section number (from get_article_sections) for just that one. Returns plain text with headings marked == like this == and table rows one per line, cells separated by | .

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesWikipedia article title (e.g. "CRISPR", "Albert Einstein").
sectionNoOPTIONAL section number (from get_article_sections) to return just that section. Omit for the full article.
max_charsNoCap on characters returned (1000-100000, default 40000).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "title": "CRISPR"
-  },
-  {
-    "max_chars": 50000,
-    "section": 2,
-    "title": "Albert Einstein"
-  }
-]New value: +[
+  {
+    "title": "CRISPR"
+  },
+  {
+    "max_chars": 50000,
+    "section": 2,
+    "title": "Albert Einstein"
+  },
+  {
+    "section": 1,
+    "title": "Table tennis at the 2026 Asian Games"
+  }
+]
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "title": "CRISPR"
+  },
+  {
+    "max_chars": 50000,
+    "section": 2,
+    "title": "Albert Einstein"
+  }
+]
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only, open-world, idempotent, and non-destructive hints, so the bar is for added context. The description contributes exact-match failure behavior ('on a miss you get a user_error naming search_wikipedia as the recovery'), truncation by max_chars, and — critically, since there is no output schema — the exact return format (plain text, '== headings ==' markers, table rows one per line with | separators). This goes well beyond what annotations convey.

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 verb and core distinction are front-loaded in the first sentence, and the body follows a logical structure: use cases → answer types → direct-call strategy → miss handling → alternative routing → parameter interplay → output format. It is long and slightly repetitive in places (the question-phrasing list and title-pattern examples overlap with earlier use cases), so it is not maximally lean, but every sentence does carry routing or formatting value.

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?

There is no output schema, so the description must cover return semantics by itself — and it does: plain text, heading markers, table cell separators, max_chars capping, and exact-match failure behavior. Combined with schema documentation for all three params and annotations for the safety profile, nothing an agent needs to invoke this tool correctly is missing.

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% and the schema already documents title, section, and max_chars with ranges and defaults. The description adds marginal value for parameters: restating the section/max_chars interplay ('Omit section for the whole article (capped by max_chars); pass a section number...') and giving concrete title-pattern examples, but those largely mirror or barely extend the schema. Baseline 3 is appropriate; no extra meaning is truly necessary at 100% coverage.

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 opens with a concrete verb+resource: 'Full text of a Wikipedia article by title — the ACTUAL prose AND its tables, not just the lead paragraph.' It explicitly distinguishes itself from get_article_summary (lead paragraph only) in the first sentence, and later names the miss behavior for searches. An agent can tell exactly what this tool returns and how it differs from close siblings.

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?

Gives explicit when-to-use and when-not-to-use guidance: 'CALL IT DIRECTLY when the title is predictable from the question', 'constructing the title and reading the article beats searching first', 'PREFER OVER get_article_summary whenever the lead paragraph is not enough', and names search_wikipedia as the recovery path on a miss. It even states the condition for using sections from get_article_sections — 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.

All wikipedia toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation2/5

The server is named 'wikipedia' but most tools are unrelated Pipeworx/Polymarket tools, so an agent asked to use Wikipedia tools will face a large misleading option set. Even within families there is blurriness: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, and deep_research overlap, and the five polymarket_* tools have closely related purposes that require reading very long descriptions to disambiguate.

Naming Consistency2/5

Naming conventions are mixed: some tools use clean verb_noun patterns (search_wikipedia, resolve_entity, validate_claim) while others use product prefixes (ask_pipeworx, pipeworx_trending, polymarket_edges) or noun-phrase names (entity_profile, recent_changes, bet_research). There is no single consistent pattern across the set.

Tool Count2/5

36 tools is already heavy, but it is especially inappropriate for a server named 'wikipedia' — only a handful are actually Wikipedia tools, while the rest belong to unrelated domains (Pipeworx data, Polymarket betting, memory, subscriptions, npm scanning). The count reflects a kitchen-sink scope rather than a focused purpose.

Completeness3/5

The Wikipedia-reading subset (search, summary, sections, extract, random) is decent but lacks editing, category, or link features. The broader Pipeworx/Polymarket surface is quite comprehensive, so completeness depends entirely on which implicit domain you judge it against; as a 'wikipedia' server it is incomplete, and as a unified data platform the scope is still incoherent.

Resources