Opens Wikipedia sentences against their cited sources; builds sourced knowledge objects into /non.
Scored across 6 tools
The tools mostly map to distinct stages of a quote/order workflow: lookup, pricing, payment, status, result retrieval, and sentence checking. There is some overlap between find_entry and get_quote around object existence versus commissioning work, and the dense cross-references make selection less immediate than ideal.
Most names follow a clear snake_case verb_noun pattern such as find_entry, get_quote, get_result, and open_sentence. card_checkout and order_status are noun-oriented deviations, but the overall convention remains readable and predictable.
Six tools is well-scoped for the workflow: discovery, quoting, payment handling, status checking, result retrieval, and sentence verification each have a clear role. No tool appears redundant, and the surface is compact enough for an agent to navigate.
The tool set covers the main lifecycle from finding an entry through quoting, payment, status, and retrieving results. The notable gap is that agent-side x402 payment is described as an HTTP route rather than an MCP tool, and there are no explicit cancellation or order-listing tools, but core workflows are workable.
Use when a person, not the agent, will pay a quote by card: returns a Stripe Checkout link (url) for the quote's maximum, at least $0.50. The work runs when the payment completes; the charge follows the work delivered, never above the quote, the rest refunded, and an order that delivers nothing is refunded in full (a card order quoted under $0.50 keeps the $0.50 minimum). An agent paying itself uses x402 at POST /v1/openings/{quote_id} instead.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | the quote_id from get_quote |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations exist, the description must carry the burden. It does so perfectly by detailing the complex financial behavior: charge follows delivery, refund mechanisms, and the $0.50 minimum constraint.
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 dense and covers a lot of ground, leading to a slightly long format. However, every sentence provides high-value information regarding constraints, alternatives, and core logic.
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 zero annotations and the complex nature of Stripe transactions, the definition is remarkably complete. It explains not just the successful path, but also the refund behavior and edge cases.
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?
While the schema coverage is high (100%), the description adds critical semantics to the 'quote_id' by linking it to the complex transactional logic and financial constraints of the checkout process.
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?
It clearly states the function: generating a Stripe Checkout link for a quote. It differentiates itself from other tools by defining the specific payment flow logic rather than just 'paying'.
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 provides explicit instructions on who should use the tool (a person paying) and a highly specific alternative for agents paying themselves, including the required endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use first when a person, work, concept, institution or operator needs a sourced knowledge object: looks the name up in the Negative of the Negative (/non), free. Returns the entry (its page, data and status) when one exists; the candidates and what tells them apart when the name is ambiguous; or, when none exists, the request for a free construction quote to pass to get_quote. Does not check a sentence (use open_sentence) and charges nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | the object's name as you have it, e.g. "Sophistical Refutations" or "Attributization" | |
| context | No | optional: a URL, a description or the kind of object, to choose among candidates with the same name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does a good job: it explains the three return modes (existing entry, ambiguous candidates, free construction quote request) and emphasizes that the lookup is free. It does not mention authentication, rate limits, or whether the lookup has any side effects, which keeps it short of a 5.
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 primary use case and then compactly covers return behavior, exclusions, and cost. It is dense with useful signals and contains no filler sentences.
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 absence of an output schema, the description appropriately explains the possible return shapes an agent needs to handle: a found entry, ambiguous candidates, or a quote request. It also clarifies the boundary with open_sentence and get_quote, so nothing critical is missing for correct invocation.
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 both the required name and optional context parameters are already documented in the schema. The description adds only indirect context by mentioning ambiguous-name candidates, not additional syntax or selection guidance beyond what the schema provides.
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: it looks up a name in the Negative of the Negative (/non) to retrieve a sourced knowledge object. It clearly distinguishes itself from siblings by naming open_sentence and get_quote, so an agent can identify its role without ambiguity.
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 explicit triggering conditions ('Use first when a person, work, concept, institution or operator needs a sourced knowledge object') and names alternatives: use open_sentence instead for sentence checking, and pass the construction quote request to get_quote when no entry exists. This is strong routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use to price work before paying: a whole Wikipedia article (article: its link or title, or oldid), read sentence by sentence at a tier, or a commission on an object (object with kind entity or operator, name, and for an operator its strings; commission construct or open): construct gives an entity the encyclopedia holds an alternative to its article, and one it lacks its first account. Or random open (a random article's cited sentence, read at tier check or opening) or random construct (a random Wikipedia article as an alternative, or an object the archive names with no /non entry); the quote says what was picked. Free; returns a quote_id with each deliverable, its line and the maximum, or, for a commission, a quote_id whose price appears at order_status within minutes. Pay a quote over x402 at POST /v1/openings/{quote_id}, or have a person pay with card_checkout. For one sentence use open_sentence; to see whether an object already exists use find_entry first.
| Name | Required | Description | Default |
|---|---|---|---|
| pool | No | for random construct: a random Wikipedia article, constructed as an alternative from the sources it cites, or an object the archive names with no /non entry; omitted, chosen at random | |
| tier | No | check: two passes on the small model; opening (default): two separately generated readings; commission: opened, then the archive consulted and a public /non row composed; portable: the commission and its knowledge object as a package | |
| oldid | No | a Wikipedia revision id, in place of article | |
| object | No | for a commission on an object: {kind: "entity" | "operator", name, description?, strings? (an operator's phrases), sources? (links)} | |
| random | No | let the service pick: open, a random Wikipedia article's cited sentence; construct, a random object (see pool). The quote carries the pick as random | |
| article | No | an English Wikipedia article's link or title; its current revision is pinned | |
| commission | No | construct: compose the object from the archive and its sources, an alternative where an account exists; open: read an AI answer seated in the Capture Registry for the name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and adds substantial behavior: the tool is free, returns a quote_id with each deliverable and its line/maximum, and for commissions returns a quote_id whose price appears at order_status within minutes. It also explains payment paths via x402 or card_checkout. It does not discuss authentication or rate limits, but the core operational behavior is well disclosed.
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 a single dense run-on paragraph with deeply nested clauses, making it hard to parse despite front-loading the purpose. Much of the content is relevant, but the structure is poor and the phrasing forces the reader to untangle multiple modes in one sentence.
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 complex, seven-parameter tool with no annotations and no output schema, the description covers the main modes, return shape, payment flow, and sibling alternatives. It leaves some gaps around required parameter combinations and authentication, but it is substantially complete for an agent to invoke the 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%, so the schema already documents all seven parameters, including enum meanings and the nested object shape. The description reiterates many of these meanings and shows how modes combine, but it adds little parameter-level detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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 opens with a specific verb and resource: "Use to price work before paying: a whole Wikipedia article ... or a commission on an object ... Or random open ... or random construct." It clearly distinguishes the main pricing modes and later differentiates from open_sentence and find_entry, so an agent can identify what the tool does without opening the schema.
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 primary use case (price work before paying) and names alternatives: "For one sentence use open_sentence; to see whether an object already exists use find_entry first." It also describes when a commission quote's price appears at order_status and how payment occurs, covering both selection and follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use once order_status names a result_id: returns the delivered work. part composition (default): the usable result, each sentence's reading or the knowledge object; evidence: the full record behind it (quoted spans, source hashes, both readings, breaches, model cost); publication: whether the /non row is composed, checked, landed and public. Free to read.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | which part of the result (default composition) | |
| result_id | Yes | the result_id order_status returns, e.g. R-d744378a9776dfdb |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does meaningful work: 'Free to read' signals a non-mutating, no-cost operation, and each part's payload is characterized (quoted spans, source hashes, breaches, model cost, publication checks). It does not disclose error conditions or whether reads are eventually consistent against order_status.
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?
Front-loaded with the call trigger before the part breakdown, and every clause carries information. The semicolon-dense part list is efficient though slightly compressed, bordering on terse for a first-time reader.
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 no output schema, the description compensates well by describing the return shape for each part, including the default. For a simple two-parameter read tool this is nearly sufficient; only error and readiness semantics are left unaddressed.
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%, so baseline would be 3, but the description goes beyond the schema's thin 'which part of the result (default composition)' by explaining what each enum value actually contains. That materially helps an agent choose between composition, evidence, and publication.
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 and resource ('Read a delivered result' / 'returns the delivered work') and immediately scopes it against the sibling that produces the identifier ('Use once order_status names a result_id'). An agent can distinguish get_result from order_status, get_quote, and the other siblings without opening any schema.
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 an explicit sequencing prerequisite: only call after order_status has supplied a result_id. It also guides the part choice by labeling composition as the 'usable result' and default. It stops short of stating failure behavior (e.g., what happens if the result is not yet delivered), which is the remaining gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when one sentence from an English Wikipedia page must be checked against the sources it cites before it is quoted or relied on. Send the sentence exactly as it stands and the page's URL. Free when the sentence has already been read at the same state; otherwise returns its price (typically 22¢ opened) and the paid HTTP route (x402) that reads it. A text that is not the page's sentence exactly is answered with the page's closest sentences, nothing charged. For a whole article use get_quote with the article instead.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | the English Wikipedia page, by title URL or revision URL | |
| mode | No | opening (default): two separately generated readings; preliminary: one pass on the small model; grounded: with the archive's claims, where a commissioned row holds the sentence | |
| text | Yes | the sentence exactly as it stands on the page (footnote markers may be left in) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does it well: it discloses that repeat reads at the same state are free, that a miss returns a price (~22¢) plus the x402 paid route, and that non-matching text costs nothing and returns nearest sentences. It stops short of saying what a successful paid read actually returns or what 'same state' means, which is the main remaining gap.
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?
Four sentences, front-loaded with the trigger, and each carries distinct information (trigger, inputs, cost model, error path, alternative). Minor slack in the phrasing around 'already been read at the same state', which is dense and slightly ambiguous.
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 paid, no-annotation tool, the description covers cost, caching, payment route, and the mismatch path, but does not describe the substance of a successful result (what the check actually returns about the sentence and its sources). With no output schema, that omission leaves a real gap in what an agent needs to interpret the response.
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 the enum on mode is fully documented in the schema, so the baseline is 3. The description reinforces the exact-text requirement and adds the consequence of a mismatch, but says nothing about mode choices, leaving that entirely to the schema.
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 definition states a specific verb and resource: check one sentence from an English Wikipedia page against the sources it cites. It also scopes the tool to a single sentence and explicitly routes whole-article work to get_quote, so an agent can distinguish it from its siblings without opening schemas.
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 opening clause gives an explicit trigger ('Use when one sentence ... must be checked ... before it is quoted or relied on'), and the final sentence names the alternative (get_quote) for the whole-article case. When-to-use and when-to-use-something-else are both present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use after get_quote or a payment, with the quote_id: returns the state (estimating, quoted, paid and running, delivered, refunded), the quote with its lines and expiry, the order's progress, its receipt and refund, and, once delivered, the result_id to pass to get_result. Charges nothing and starts nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | the quote_id from get_quote, e.g. Q-0123456789abcdef |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key safety facts: 'Charges nothing and starts nothing,' which tells the agent this is a free, non-initiating read that won't spawn work. It also enumerates what is returned (state, quote lines, expiry, order progress, receipt, refund, result_id). It omits error behavior for an invalid/unknown quote_id and whether polling is expected, which keeps it below 5.
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?
It is a single sentence that front-loads the usage trigger and cost/side-effect guarantee before the return inventory. Despite being clause-dense, every clause carries information an agent needs for chaining, since there is no output schema to offload the return description to.
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 no output schema and no annotations, the description must describe both safety and returns, and it does so concretely, including the result_id needed to continue the workflow. The remaining gap is failure/polling behavior — what happens if the quote_id is unknown or still 'estimating' — which matters for an agent driving a state machine.
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?
There is a single parameter with 100% schema description coverage ('the quote_id from get_quote, e.g. Q-0123456789abcdef'), so the schema already does the work. The description only reinforces the same provenance ('with the quote_id') and adds no format or edge-case guidance beyond it, so the baseline 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?
The description states a specific verb and resource (returns the state of a quote/order) and enumerates the actual state values (estimating, quoted, paid and running, delivered, refunded), so the agent knows exactly what domain concept is being reported. It also names the sibling tools it relates to (get_quote upstream, get_result downstream), making it distinguishable without opening any schema.
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 an explicit trigger: 'Use after get_quote or a payment,' which tells the agent precisely when in the workflow to call it. It also states the downstream handoff ('once delivered, the result_id to pass to get_result'), effectively routing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_quote3 fields changedInput schema / properties / commission / descriptionPrevious value: -"construct: compose the object from the archive and its sources; open: read an AI answer seated in the Capture Registry for the name"New value: +"construct: compose the object from the archive and its sources, an alternative where an account exists; open: read an AI answer seated in the Capture Registry for the name"Input schema / properties / poolAdded value: +{
+ "description": "for random construct: a random Wikipedia article, constructed as an alternative from the sources it cites, or an object the archive names with no /non entry; omitted, chosen at random",
+ "enum": [
+ "wikipedia",
+ "archive"
+ ],
+ "type": "string"
+}Input schema / properties / randomAdded value: +{
+ "description": "let the service pick: open, a random Wikipedia article's cited sentence; construct, a random object (see pool). The quote carries the pick as random",
+ "enum": [
+ "open",
+ "construct"
+ ],
+ "type": "string"
+}card_checkout1 field changedInput schema / properties / quote_id / descriptionAdded value: +"the quote_id from get_quote"find_entry2 fields changedInput schema / properties / context / descriptionPrevious value: -"a URL, a description or the kind of object, to tell candidates apart"New value: +"optional: a URL, a description or the kind of object, to choose among candidates with the same name"Input schema / properties / name / descriptionAdded value: +"the object's name as you have it, e.g. \"Sophistical Refutations\" or \"Attributization\""get_quote5 fields changedInput schema / properties / articleAdded value: +{
+ "description": "an English Wikipedia article's link or title; its current revision is pinned",
+ "type": "string"
+}Input schema / properties / commission / descriptionAdded value: +"construct: compose the object from the archive and its sources; open: read an AI answer seated in the Capture Registry for the name"Input schema / properties / object / descriptionAdded value: +"for a commission on an object: {kind: \"entity\" | \"operator\", name, description?, strings? (an operator's phrases), sources? (links)}"Input schema / properties / oldid / descriptionAdded value: +"a Wikipedia revision id, in place of article"Input schema / properties / tier / descriptionAdded value: +"check: two passes on the small model; opening (default): two separately generated readings; commission: opened, then the archive consulted and a public /non row composed; portable: the commission and its knowledge object as a package"get_result2 fields changedInput schema / properties / part / descriptionAdded value: +"which part of the result (default composition)"Input schema / properties / result_id / descriptionAdded value: +"the result_id order_status returns, e.g. R-d744378a9776dfdb"open_sentence2 fields changedInput schema / properties / mode / descriptionAdded value: +"opening (default): two separately generated readings; preliminary: one pass on the small model; grounded: with the archive's claims, where a commissioned row holds the sentence"Input schema / properties / text / descriptionAdded value: +"the sentence exactly as it stands on the page (footnote markers may be left in)"order_status1 field changedInput schema / properties / quote_id / descriptionAdded value: +"the quote_id from get_quote, e.g. Q-0123456789abcdef"card_checkoutfind_entryget_quoteget_resultopen_sentenceorder_statusCited, versioned knowledge for agents: retrieve sourced passages and propose owner-approved fixes.
Exact source text, not summaries: check citations and quotes in one call; read pages and PDFs.
Cite the claim, not the paper: 5,033 assertions, each hash-verifiable against its source PDF
Read and search exact public source URLs with stable paragraph citations.
Add one secure layer between your agents and this server.
