FiatDock

Wikipedia article summary (21 languages) ($0.0018)

wiki_summary

Read-onlyIdempotent

PAID ($0.0018 USDC via x402). Resolve a title or a few words to a Wikipedia article (en, ar, de, fr, es, it, ja, zh, ru, pt, nl, pl, tr, fa, he, ko, id, uk, sv, vi, hi) and return its summary: lead section as plain text (not the whole article), description, URL, last edit, image, coordinates, Wikidata id, how it was matched, other matches. Disambiguation pages are labelled. No fitting title answers 404 and is not charged. Text is CC BY-SA 4.0, attribution included. Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically. Any answer the tool cannot produce is >= 400 and is NOT charged.

Input Schema

Name	Required	Description
`lang`	No	Wikipedia language edition (default en): en, ar, de, fr, es, it, ja, zh, ru, pt, nl, pl, tr, fa, he, ko, id, uk, sv, vi, hi
`query`	No	An article title or a few words naming the subject (required; an empty body answers the published example)
`payment`	No	Base64 of a single x402 v2 PaymentPayload (EIP-3009 transferWithAuthorization on Base USDC). OMIT it on the first call: the 402 you get back carries `howToPay.payloadTemplate` — the exact envelope to fill in — plus the price and the EIP-712 domain. Send it on the second call to complete the purchase; it is forwarded as the PAYMENT-SIGNATURE header, never as body data. Nothing is charged for the 402 itself, and a call that fails after payment settles nothing.

Output Schema

Name	Required	Description
`url`	Yes	The article's canonical desktop URL
`asOf`	Yes	ISO time the search and the summary were read (the older of them)
`lang`	Yes	The Wikipedia language edition read
`note`	Yes	Whose text it is, how the article was chosen, and the limits
`type`	Yes	standard, disambiguation (a list of meanings, not an answer), mainpage, no-extract, or unknown
`query`	Yes	The query as searched (whitespace collapsed)
`title`	Yes	The article's title
`source`	Yes	Where the data came from
`extract`	Yes	The article's lead section as plain text (at most 4,000 characters) — Wikipedia contributors' text
`license`	Yes	The license of the text (CC BY-SA 4.0)
`defaulted`	No	Present only when the body was empty: which query the answer is for, and why
`matchedBy`	Yes	How the article was chosen: exact title, full-text search or title search
`thumbnail`	Yes	The article's lead image (https), or null
`wikidataId`	Yes	The Wikidata item (Q-id), or null
`attribution`	Yes	The credit to keep beside any reuse of the text, with the article's link
`coordinates`	Yes	The subject's coordinates when the article has them, or null
`description`	Yes	The short description (usually Wikidata's), or null
`lastModified`	Yes	ISO time of the article's last edit, or null
`matchedTitle`	Yes	The redirect or alias title that matched, when it differs from the article's title (e.g. HTTP 402 → List of HTTP status codes)
`otherMatches`	Yes	Up to 4 other titles the search returned

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses the exact price, the x402/402 challenge mechanics, that failed calls are never charged, that disambiguation pages are labelled, and the CC BY-SA licensing with attribution. This is exactly the operational context an agent needs for a paid endpoint.

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?

Front-loads cost and the core action, then layers payment and error semantics; every sentence is substantive. Minor waste in re-listing all 21 language codes already present in the schema enum.

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?

Despite an output schema existing, the description usefully names the returned fields and error/charging behavior, and covers payment, licensing, and disambiguation handling. Nothing an agent needs to call it correctly is missing.

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 spelling out the two-call payment protocol for the `payment` param (fill the returned payloadTemplate, send as PAYMENT-SIGNATURE, never as body data). The language list is restated redundantly from the enum, keeping it from a 5.

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?

States a specific verb and resource ('Resolve a title or a few words to a Wikipedia article and return its summary') and scopes the output precisely (lead section, not the whole article). It is clearly distinguishable from every sibling, none of which touch Wikipedia.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the invocation flow in detail: omit payment on the first call to get the 402 template, then send it on the second call, with fiatdock-mcp handling payment automatically. It also gives a clear when-not ('No fitting title answers 404 and is not charged'). It does not, however, compare itself to alternatives such as web_read or paper_search.

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

All FiatDock 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.