wikipedia-mcp-server

Get Wikipedia References

wikipedia_get_references

Read-only

List the footnotes an article cites — its reference lists, in document order — with each footnote's text, external links (archive copies included), and DOIs. wikipedia_get_article drops footnote markers and reference lists, so use this for the sources behind a claim. label is the in-text marker without brackets; group names a notes list such as "lower-alpha" and is absent for the main list. A short citation such as "Galinsky 2012, pp. 75–76" carries work_ids, and works on the same page holds the full citations they name, each once. Pages hold whole footnotes within 40,000 UTF-8 bytes on both surfaces; follow next_cursor as cursor with the same title and language to continue at the same revision. Bibliography and further-reading entries no footnote points to are not listed — read those sections with wikipedia_get_article. Redirects are followed; the revision_id and url cite the article read.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>"
    },
    "name": "wikipedia_get_references"
  }
}

Input Schema

Name	Required	Description	Default
`title`	Yes	Article title (e.g. "Seine"). A trailing #fragment is accepted and ignored; the characters < > [ ] { } and \| cannot appear in a Wikipedia page name.
`cursor`	No	Opaque next_cursor from the previous page. Keep title and language unchanged. Empty means the first page.
`language`	No	Wikipedia language edition code (default "en"). Examples: "fr", "de", "ja".	en

Output Schema

Name	Required	Description
`url`	No	Canonical desktop URL of the article (e.g. "https://en.wikipedia.org/wiki/Seine"), for citing the page.
`error`	No	Present when the call failed. Absent on success.
`title`	No	Resolved article title.
`works`	No	Full citations the work_ids on this page resolve to, each once. A work_id with no matching anchor in the article has no entry.
`notice`	No	Where to look instead when the article has no footnotes.
`pageid`	No	Wikipedia page ID. Absent on API parse responses that omit it.
`references`	No	Footnotes on this page, in document order. Empty when the article has none.
`next_cursor`	No	Pass unchanged as cursor with the same title and language for the next page. Absent on the last page.
`revision_id`	No	ID of the revision the footnotes were read from. Every page of one read carries the same revision.
`redirected_from`	No	Original alias followed to the resolved article.
`total_references`	No	Footnotes in the article across every reference list, on all pages.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses pagination mechanics (40,000 UTF-8 bytes per page on both surfaces, follow next_cursor with the same title and language to resume at the same revision), redirect handling, and that revision_id and url refer to the article actually read. It also discloses the notable exclusion (unreferenced bibliography entries) and the deduplication rule for works.

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?

Purpose is front-loaded and nearly every sentence adds a distinct operational fact (pagination, exclusions, redirects, citation linkage). The single dense paragraph, however, mixes input guidance, return-value semantics, and pagination, which makes it slower to scan than a short structured breakdown would be.

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?

An output schema exists, so return fields needn't be enumerated, yet the description still explains how to page through results, what is deliberately omitted, and how revision identity is reported. For a three-parameter read tool that is everything an agent needs to call it correctly.

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%, so the baseline is 3; the description still adds value by tying cursor to the returned next_cursor and requiring title/language to stay unchanged to continue at the same revision. It does not retread title fragment handling or language codes, which the schema already covers.

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 first clause gives a precise verb and resource (list the footnotes an article cites) plus scope (reference lists, document order) and the per-footnote content (text, external links, archive copies, DOIs). It explicitly distinguishes itself from wikipedia_get_article, which drops footnote markers and reference lists, so an agent can route between the two without opening a schema.

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 states the positive use case ("use this for the sources behind a claim") and explicitly names the alternative for the cases this tool excludes: bibliography and further-reading entries no footnote points to must be read with wikipedia_get_article. Both when-to-use and when-not-to-use are covered, with the sibling named.

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.