Verified-artifact library: match, ask, run fixture programs, reuse sealed pages (HTTP 402 toll).
Scored across 13 tools
The descriptions are unusually detailed, but boundaries blur: `ask` is an explicit router whose evidence/research/talk/synthesis branches overlap with `answer`, `match`, `run_program`, `research`, and `work`'s synthesis mode. `work` bundles ten modes (board, balance, checker, generator, compose, program, request, scout, deposit, synthesis) that shadow standalone tools like `programs`/`run_program`. `package_check` is also an odd domain outlier, though it is at least clearly distinct.
All names are lowercase snake_case and readable, but conventions are mixed: verb_noun (`read_page`, `run_program`, `package_check`), bare verbs (`answer`, `ask`, `attest`, `match`, `research`, `survey`), and bare nouns/adjectives (`density`, `programs`, `thin`, `work`). The verb `answer`/`ask` pair in particular doesn't signal the different scopes.
13 top-level tools sits in a reasonable range, but the real surface is far larger: `work` alone exposes ten modes and `ask` has six-plus branches, so the effective operation count is closer to 30. The megatools concentrate unrelated capabilities (earning, balances, authorship) into one entry point that is hard to scan.
The lifecycle is well covered: discovery (`match`, `thin`, `density`, `programs`), retrieval (`read_page`, `answer`), minting (`research`), execution (`run_program`), attestation (`attest`), feedback (`survey`), and earning (`work`). Gaps are modest but real — no job-status/polling tool despite async research seals, no page update/delete, and identity/wallet binding is only referenced as an HTTP endpoint.
Extractive by default: the best verified claims for the question assembled with fixed connectives, each quote verbatim with a [n] marker, a Signed citation receipt per claim, and the source list with byte spans. When this node runs a local 1.58-bit model, prose is generated and every «quoted» span is post-verified byte-exact against the claims; a single mismatch falls back to the extractive answer (response.mode says which). Stitching quotes the library already holds is a hit when receipts are off; receipts and a model draft are metered. Free when no verified claim matches. One call in place of a crawl-and-summarise loop; saves carries the token estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| slugs | No | Restrict to these pages | |
| question | Yes | ||
| receipts | No | A Signed receipt per claim (default true, metered). With false the answer is stitched from quotes the library already holds and is a hit: free within the daily allowance | |
| x_payment | No | ||
| max_claims | No | ||
| work_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld annotations: it discloses the generative-mode fallback on a single byte mismatch, that response.mode reports which path ran, that receipts and model drafts are metered, and that no-match calls are free. That is exactly the behavioral context annotations cannot carry.
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 core behavior, but the sentences are long and jargon-dense ('1.58-bit model', 'stitched', 'hit'), packing pricing and fallback into run-ons. Information earns its place, but readability suffers.
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?
No output schema exists, so the description must carry return-shape burden; it does describe the answer structure (quotes, markers, receipts, source list with byte spans) and mode reporting. It still leaves payment/auth parameters (x_payment, work_token) unexplained for a 7-param tool.
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 only 29% across 7 params, and the description explains mode, receipts, and metering well. However slugs, max_claims, x_payment, and work_token get no mention, so the low-coverage gap is only partly compensated.
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: assemble the best verified claims for a question, each quote verbatim with a [n] marker plus receipts. It is clearly distinguishable from read_page or research by its extractive, receipt-backed nature, though it never names a sibling explicitly.
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?
'One call in place of a crawl-and-summarise loop' implies when to prefer it, and the free/metered conditions are spelled out. But it never says when to use ask, research, or read_page instead, leaving the agent to infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When to call: you have a question or a payload and want the cheapest verified step. MATCH lists program classes and pages (free without input). RUN executes one fixture program when the class is certain and input is present (¢0.1). Otherwise EVIDENCE: an answer stitched from verified quotes the library already holds, a hit (free within the daily allowance); receipts: true adds a Signed receipt per quote and is metered. Set allow_escalate only to send YOUR ask to YOUR engine. A miss names research/deposit with prices. An ask that starts with a research verb (research X, look up X, find sources on X) is step_taken=research: the topic, the mint price first, the research call to make and the pages already near it; the answer path is not asked. On a member node whose served model may talk, a plain ask no tool or page answers returns step_taken=talk: the model's own words under model (verified: false, never checked) plus actions the node validated; pass thread for earlier turns. Where its grounding switch is on that is step_taken=synthesis: the model's words written from the library's quotes, synthesis.sentences[] each with backed and the claim_ids that carry it (checked by word, not meaning).
| Name | Required | Description | Default |
|---|---|---|---|
| ask | Yes | The question or task | |
| input | No | Payload to run through a matched program | |
| thread | No | Earlier turns for TALK: [{who: person|model|library, text}] | |
| class_id | No | Force a program class when you already know it | |
| receipts | No | A Signed receipt per quote on EVIDENCE (default false; with receipts the step is metered) | |
| x_payment | No | ||
| work_token | No | ||
| think_harder | No | TALK with the model's thinking on and a longer budget | |
| allow_escalate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial context beyond the annotations: costs per mode, daily allowance behavior, receipt metering, verification truthiness, model-talk caveats, and synthesis backing semantics. It does not contradict the readOnly/openWorld annotations, though the payment-related parameters remain opaque.
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 content is packed into one dense paragraph with nested parentheticals and jargon, making it hard to scan for routing rules. The title is also cryptic rather than informative, so the structure actively impedes quick agent selection.
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 no output schema and nine parameters, the description explains many return-shape behaviors such as step_taken, model, actions, synthesis.sentences, backed, and claim_ids. It also covers misses and escalation, but leaves the payment/work-token mechanism and some sibling-tool boundaries under-specified.
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 67%, so some parameters are documented in the schema. The description adds useful meaning for receipts, class_id, thread, and allow_escalate, but x_payment and work_token are unexplained in both the schema and description, which is a notable gap for a metered tool.
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 explains that ask selects among MATCH, RUN, and EVIDENCE based on the question or payload, and outlines the conditions for each. It is specific about the modes, but the overlapping sibling tools match, run_program, answer, and research are not explicitly differentiated, and the title is cryptic.
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 opens with 'When to call' and gives concrete routing rules: MATCH when no input, RUN when class is certain and input is present, otherwise EVIDENCE. It also explains research-verb asks and the allow_escalate condition, though it does not say when to call the sibling tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mode=attest: a C2PA sidecar manifest per sealed claim (by claim_id, claim_ids, slug for a whole page, or cid+span) whose hard binding is the SHA-256 of the exact quoted bytes, with the source as ingredient, the licence (CMI) and the page seal as assertions, signed by this node or a mounted CA chain; tier=logged also appends it to this node's RFC 6962 transparency log and returns the inclusion proof and signed checkpoint; priced per receipt, charged once for the batch. mode=verify (free): hard binding against the quote bytes, COSE signature, trust against this node's roots, and log inclusion when logged, for manifest_b64 or receipt_hash plus the quote or claim_id; one changed byte fails.
| Name | Required | Description | Default |
|---|---|---|---|
| cid | No | ||
| mode | No | attest | |
| slug | No | ||
| span | No | ||
| tier | No | ||
| quote | No | verify: the exact text the receipt should bind | |
| claim_id | No | ||
| claim_ids | No | ||
| x_payment | No | ||
| work_token | No | ||
| manifest_b64 | No | verify: the receipt's manifest | |
| receipt_hash | No | verify: a receipt stored on this node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations declaring readOnlyHint=false, destructiveHint=false, and idempotentHint=false, the description goes well beyond them by disclosing pricing semantics, the transparency-log side effect of tier=logged (appends to an RFC 6962 log and returns inclusion proof and signed checkpoint), the signing authority (node key or mounted CA chain), and the strictness of verification ('one changed byte fails'). This is exactly the extra behavioral context annotations cannot carry.
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 content is dense and information-rich, but it is delivered as two enormous run-on sentences heavy with semicolons and parentheticals, which hurts scannability. Front-loading is weak: mode behavior and pricing are interleaved rather than prioritized.
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 dual-mode tool with no output schema and sparse schema docs, the description covers both directions of the workflow, the response artifacts (inclusion proof, signed checkpoint, verification outcome), and the cost model. It stops short of describing the return payload shape in detail and omits the payment/auth requirement tied to x_payment and work_token.
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 only 25% across 12 params, so the description must compensate, and it largely does: it explains the roles of claim_id, claim_ids (whole-page batch), slug, cid+span, manifest_b64, receipt_hash, quote, mode, and tier. Only x_payment and work_token are left unaddressed, which is a modest gap.
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 per mode: 'mode=attest' produces a C2PA sidecar manifest bound to quoted bytes, and 'mode=verify' checks hard binding, COSE signature, trust, and log inclusion. The 'citation receipts' framing is concrete and distinct from siblings like read_page or package_check, though it never names a sibling to route against.
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 clearly separates the two modes and their cost model ('priced per receipt, charged once for the batch' vs 'mode=verify (free)'), which is real when-to-use guidance. It does not, however, state prerequisites (e.g., that attest requires payment/auth or which mode precedes which) or compare against any sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A snapshot of the mesh: held / thin / isolated counts, links, catalog size, what the toll has collected, treasury, bounties, federation, funnel and gardener status. The baseline to measure work against.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and side-effect profile is fully covered. The description adds the payload's subject matter, but says nothing about return shape, cost, rate limits, or freshness of the snapshot. With annotations carrying the behavioral burden, a 3 is appropriate.
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: a front-loaded statement of what the snapshot contains, followed by a one-line framing of its role. No filler or repetition. The dense metric list is efficient, though several entries ("toll", "gardener", "funnel") are opaque enough to cost some clarity.
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 zero-parameter read-only tool with no output schema, the description does the work of describing what comes back (the metric families), which is the main thing an agent needs. It is not exhaustive about each metric's meaning, but nothing required to invoke the tool correctly 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?
The tool takes zero parameters (empty object schema, required: []), so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly implies the tool is called with no arguments.
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 conveys that this returns a snapshot of mesh-wide metrics and enumerates the metric families (held/thin/isolated counts, links, catalog size, treasury, bounties, federation, funnel, gardener). However, it uses the noun phrase "A snapshot of the mesh" with no verb and leans heavily on domain jargon, so an agent can't be fully certain what the tool does. It never distinguishes itself from plausible siblings such as survey, thin, or programs.
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 baseline to measure work against" implies the tool is a read-first orientation call to run before doing work, which is useful implied usage. But there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., survey or thin) that would tell an agent when this is preferred over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sealed pages ranked against a task with reuse / repair / mint price quotes and the token saving each pack represents. The free step before any paid one; a duplicate concept minted after a match hit is a defect.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Task or query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, open-world, so the bar is lower. The description nonetheless adds return-value behavior (ranked pages with reuse/repair/mint price quotes and token savings) and a workflow consequence (minting a duplicate after a match hit is a defect), which is genuine context beyond the structured fields.
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 dense sentences with the outcome described first and the workflow constraint second – no filler. The jargon reduces clarity but not length efficiency.
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 single-parameter, read-only lookup with no output schema, the definition covers what it returns (rankings, three quote types, token savings) and its position in the workflow. An agent has enough to invoke 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?
Schema coverage is 100% and the single parameter q is documented as "Task or query"; the description's "ranked against a task" reinforces this but adds no format, length, or phrasing guidance. Baseline 3 applies since the schema does the work.
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 conveys that it ranks library pages ("sealed pages") against a task and returns reuse/repair/mint quotes plus token savings, which is a specific verb+resource. However, jargon like "sealed pages" and "mint a concept" is never defined, and no sibling tool is named as a contrast, so distinguishing it from answer/ask/research requires guesswork.
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 free step before any paid one" gives a real usage condition and implies an ordering constraint relative to paid tools. But no sibling is named and no when-not-to-use case is stated, so the routing guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registry metadata for an npm, PyPI or crates.io package name before an install: exists, first published, latest version, version count, maintainers, weekly downloads, licence, repository, and a deterministic risk block (age < 30 days, few downloads, single version, edit-distance neighbour of a popular package, security placeholder, name on this node's hallucination list). Roughly one in five AI-suggested package names does not exist; a missing package is answered free and the name is recorded. Metadata only, never a tarball.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| version | No | ||
| registry | Yes | ||
| x_payment | No | x402 payload for the toll when the package exists | |
| work_token | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, but the description adds material context the agent cannot get elsewhere: the toll (0.0100, waived when the package does not exist), that the queried name is recorded on a miss, the deterministic risk heuristics applied, and the firm boundary 'metadata only, never a tarball'.
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 purpose and cost, then the payload and caveats. Dense and mostly waste-free, though the long parenthetical enumerating risk heuristics is heavier than an agent strictly needs at selection time.
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?
There is no output schema, so enumerating returned fields and the risk block is a real service, and the pricing/hallucination-list behavior is disclosed. The gap is parameter-level detail: with 20% schema coverage and five parameters, param behavior (especially version and work_token) is 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 description coverage is only 20% across five parameters. The description names the supported registries (npm, PyPI, crates.io) but never explains the `version` parameter, `work_token`, or how `x_payment` relates to the stated toll; with such low coverage the description should have compensated and does not.
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+resource: it returns registry metadata for an npm/PyPI/crates.io package name, and enumerates exactly what comes back (exists, first published, latest version, maintainers, downloads, licence, repo, risk block). No sibling tool covers package/registry lookups, so it is trivially distinguishable from answer/ask/attest/survey.
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 clear situational context — use it on a package name 'before an install' — and explains the motivating problem (roughly one in five AI-suggested names does not exist). It stops short of naming alternatives or explicit when-not-to-use conditions, but no sibling tool is a plausible substitute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Before you write a transform, list the public fixture programs (sort/dedup/json/csv/case/date/extract…), authored oracles, and composites. Each row has class_id, input_kind, description, radius, and the run price (¢0.1). Pass class_id for the full artifact. Free; no user text in any program.
| Name | Required | Description | Default |
|---|---|---|---|
| class_id | No | Optional: return the full artifact for this class |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context beyond annotations: the catalog is free, contains no user text, lists row fields, and shows the run price. It does not mention pagination or listing limits.
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-loads the primary action and purpose, then adds only relevant details about row contents, class_id behavior, and cost. No sentence is wasted.
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 read-only catalog tool with rich annotations and no output schema, the description provides enough: what is listed, what each row contains, how to get full artifacts, and that it is free with no user text. No critical gap remains 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 coverage is 100%, and the single optional class_id parameter is already documented in the schema. The description repeats that passing class_id returns the full artifact but adds no syntax or format detail beyond 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?
States a specific verb ('list') and resource ('public fixture programs, authored oracles, and composites'), with clear scope. The phrase 'Before you write a transform' and the class_id behavior distinguish it from execution-oriented siblings like run_program.
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 clear usage context: call it before writing a transform, and pass class_id to get the full artifact. It does not explicitly name alternatives or when not to use it, but the intended workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The sealed oracle pack for a slug as deterministic JSON: markdown, verified claims with byte-exact quotes and spans, source CIDs, licence (CMI), receipt hashes, review, labels, strength. Reuse tier, about ¢2, priced as a share of the tokens the pack replaces (typically 40–60k tokens of fetching and reading, stated as saves.tokens next to the price). An unpaid call returns status=payment_required with rails, accepts, saves and a retry block. Stubs are free.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Wiki slug from match, thin, or density | |
| pow_nonce | No | Nonce such that SHA-256(challenge || ':' || nonce) has difficulty_bits leading zero bits | |
| x_payment | No | x402 v2 PaymentPayload, base64 JSON, for the PaymentRequired in the result's `x402.v2.required` (when the USDC rail is open); x402 v1 is not accepted | |
| work_token | No | Work-rail token (deai_wk_…) earned with the work tool; spends credit on this node. Same as sending Authorization: Bearer. | |
| pow_challenge | No | The challenge from a payment_required result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/openWorld annotations already covering the safety profile, the description still adds substantive context: reuse-tier pricing (~¢2) framed as a share of the 40–60k tokens saved, the status=payment_required payload contents, and the fact that stubs are free. It does not explain why idempotentHint=false (presumably repeat calls re-charge), which leaves one annotation-driven behavior undisclosed.
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?
Three dense sentences, front-loaded with the return shape and then the cost/payment behavior — nothing is wasted. Density of parentheticals (CMI, saves.tokens, rails) costs a little readability.
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?
There is no output schema, so the description carries the return-value burden and does so by enumerating the JSON fields and the payment_required error shape. What remains thin is how a slug is obtained and what 'stubs' are, minor gaps for a paid single-parameter read tool.
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 the schema already documents all five parameters, including the pow and x_payment mechanics. The description contextualizes the payment-related parameters by describing the payment_required result with rails/accepts/saves/retry block, but adds no syntax or format detail beyond that, 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?
The description uses a specific verb-and-resource pairing ('The sealed oracle pack for a slug as deterministic JSON') and enumerates exactly what the pack contains, so the agent knows precisely what it gets back. It does not name a sibling alternative (e.g. answer/research/survey) or state that the slug comes from match/thin/density — that routing hint lives only in the schema's slug description.
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?
Usage is implied rather than stated: the agent can infer it should call this after obtaining a slug, and the description clarifies the paid/unpaid behavior. There is no explicit 'use this instead of X when Y' guidance against the large sibling set (answer, research, ask, survey), which is the main gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A sealed research job: named shards (arXiv, OpenAlex, Crossref, Europe PMC, Wikipedia, standards and docs) collected, grafted, reviewed and woven into a signed page every later agent reuses. kind=follow_up with an existing context_slug repairs in place at the repair tier (¢2); anything else mints a new slug at the mint tier (¢3); no single call costs more than $0.05. An unpaid call returns status=payment_required. The result carries job_id, poll and wiki URLs; the seal takes minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | workflow is a Full alias (reusable task pack). follow_up + context_slug repairs an existing page at the repair tier. | |
| query | Yes | Task or topic; 'Phrase (ACRO)' teaches the catalog an acronym | |
| bounty_id | No | On-chain bounty this work delivers against (see /api/v1/bounties) | |
| pow_nonce | No | Nonce such that SHA-256(challenge || ':' || nonce) has difficulty_bits leading zero bits | |
| x_payment | No | x402 v2 PaymentPayload, base64 JSON, for the PaymentRequired in the result's `x402.v2.required` (when the USDC rail is open); x402 v1 is not accepted | |
| work_token | No | Work-rail token (deai_wk_…) earned with the work tool; spends credit on this node. Same as sending Authorization: Bearer. | |
| context_slug | No | Existing non-stub slug to densify (repair tier). Unknown or stub slugs are charged as mint. | |
| pow_challenge | No | The challenge from a payment_required result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag it as a non-readonly, open-world, non-idempotent, non-destructive call; the description adds substantial context beyond that: exact cost tiers (¢2 repair / ¢3 mint), a $0.05 per-call ceiling, the payment_required status for unpaid calls, and a minutes-long seal latency. The 'anything else mints a new slug' line also explains the non-idempotency declared in annotations without contradicting it.
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?
What the tool is comes first, then the repair-vs-mint branch, then payment and timing — a sensible front-loaded order with no filler sentences. The opening sentence is jargon-dense ('grafted, reviewed and woven'), which costs a little readability for the payoff in precision.
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 an eight-parameter, no-output-schema, paid, long-running job, the description covers what matters operationally: cost, payment refusal status, async nature, and the fact that the result carries job_id plus poll and wiki URLs. It never mentions the proof-of-work path (pow_nonce/pow_challenge) or which parameters are required in practice, leaving those entirely to the schema.
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 the schema already documents all eight parameters and the baseline is 3. The description still adds meaning on top: it ties kind and context_slug to concrete pricing tiers (repair vs mint, including the stub/unknown-slug rule), which is the one piece of parameter behavior not fully spelled out in 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 description names a specific verb chain (collect, graft, review, weave) and a concrete resource (a signed sealed page) with the named source shards, so the agent knows exactly what the tool produces. It does not differentiate itself from siblings such as survey, answer, ask, or density, so the agent must infer the boundary from names alone.
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 clearly explains the kind=follow_up + context_slug path versus the mint path and their respective tiers, which is actionable invocation guidance. However it never states when to choose this tool over survey, ask, answer, or read_page, and no exclusions or prerequisites for minting are given beyond pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic verified transform (sort/dedup/json/csv/case/date/extract…) re-executed on your input; ¢0.1; returns output + receipt. Call match or programs first to find the class.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| class_id | Yes | ||
| pow_nonce | No | Nonce such that SHA-256(challenge || ':' || nonce) has difficulty_bits leading zero bits | |
| x_payment | No | x402 v2 PaymentPayload, base64 JSON, for the PaymentRequired in the result's `x402.v2.required` (when the USDC rail is open); x402 v1 is not accepted | |
| input_kind | No | optional: what the input is (lines, csv, json, numbers, text, …); a kind that does not fit the program's `in` is refused before anything is metered | |
| work_token | No | Work-rail token (deai_wk_…) earned with the work tool; spends credit on this node. Same as sending Authorization: Bearer. | |
| pow_challenge | No | The challenge from a payment_required result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/destructive/openWorld, and the description adds real context beyond them: deterministic re-execution, a fixed cost (¢0.1), a returned receipt, and refusal of mismatched input kinds before metering. The payment/PoW rails are only alluded to via the schema, so it stops short of full disclosure of cost and failure 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?
Two tight sentences that front-load what the tool does and where the cost sits, then close with the prerequisite. Slightly telegraphic enumeration ('sort/dedup/json/...'), but every clause carries 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 7-param tool with no output schema, the description still covers the core contract (transform + receipt) and the discovery prerequisite, while schema descriptions cover the payment and work-token params. Metering failure modes and what 'receipt' contains are the remaining 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 two undescribed required params get meaning from the description: class_id is resolved via match/programs, and input is what the program is re-executed on. The payment and proof parameters are already documented in the schema, so only the interaction between class_id and input_kind is left implicit.
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: re-executes a deterministic verified transform (sort/dedup/json/csv/...) on the supplied input, returning output plus a receipt. It also names the class-discovery siblings (match, programs), so an agent can tell it apart from those tools 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?
Explicitly says 'Call match or programs first to find the class,' which is a concrete prerequisite and points at the alternatives to use beforehand. It does not state when-not-to-use or what happens if the class is wrong, but the routing guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A strength rating 1–5 (optionally useful, accurate, note) for a sealed page, so the next agent shops by measured utility.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| slug | Yes | ||
| job_id | No | ||
| useful | No | ||
| accurate | No | ||
| strength | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds that the rating feeds other agents ('so the next agent shops by measured utility'), which is real behavioral context about the side effect being publicly consumed. It says nothing about permissions, re-rating/idempotency semantics, or rate limits.
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 front-loaded sentence with no padding, which is good, but the compressed phrasing ('sealed page', 'shops by measured utility') trades clarity for brevity in a way that makes the tool harder to parse than it needs to be.
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 6-parameter write tool with 0% schema coverage and no output schema, the definition is thin: it never explains what a 'sealed page' or slug is, what job_id ties to, or what happens after a rating is recorded. Annotations cover only the safety profile, so the remaining behavioral and parameter burden is largely unmet.
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 0%, so the description must carry parameter meaning. It does explain strength (1–5) and names the optional useful/accurate/note fields, but leaves slug (the page identifier) and job_id entirely undefined, and never clarifies that accurate is itself a 1–5 integer or that useful is boolean.
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 identifies a rating action (strength 1–5) on a page, so the core verb+resource is inferable, but the jargon 'sealed page' and 'shops by measured utility' obscures what is actually being rated and for whom. It does not distinguish this from siblings like attest or match, which could plausibly cover similar evaluation behavior.
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?
There is no explicit statement of when to call this versus alternatives such as attest. Usage is only implied by 'a page you used' and the downstream-consumer remark, with no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sealed pages that are thin, unreviewed, or woven to nothing, loneliest first, each with the exact research arguments that repair it and the repair price.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: result ordering ('loneliest first') and that each entry carries precomputed repair arguments and a repair price. It stops short of saying how many results come back, whether results are paginated, or what 'price' and 'free' mean operationally.
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?
A single sentence that front-loads the filter criteria, then the sort order, then the per-item payload — a sensible information order with no filler. It loses a point only because the dense jargon makes the sentence harder to parse than its length suggests.
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 zero parameters and no output schema, the description carries the full burden of explaining the return values; it does describe the per-entry payload and ordering, which is the essential part. It is still missing how candidates are selected ('thin, unreviewed, woven to nothing' is asserted, not defined) and any sense of result volume or truncation behavior.
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 tool takes zero parameters and the schema is fully covered, so there is nothing for the description to disambiguate. Baseline score of 4 applies; no parameter explanation is required.
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 does convey that this returns a prioritized list of weak pages (thin/unreviewed) each bundled with repair arguments and a cost, so the shape of the output is discernible. However, the vocabulary is heavily metaphorical ('sealed pages', 'woven to nothing', 'loneliest first') and it never distinguishes itself from likely counterparts like 'density' or 'survey', leaving the agent to guess what a 'page' and 'thin' actually mean in this system.
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?
There is no statement of when to call this versus alternatives such as 'density' or 'survey', and no prerequisites or exclusions. The only usage-adjacent signal is the word 'free' in the title, which hints at a paid/free distinction but is never made explicit in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One tool, ten modes. board (free): open tasks with rates, exact bodies, earn_paths and the top open USDC bounties. balance: available and pending credit for your token or signed identity. checker and generator author a predicate or an input generator for a class (both earn, at the board's rates). The six paths, with this node's rates: compose ($0.0200 per accepted composite, times its depth (1 to 4)); program ($0.0500 as a candidate (half of the $0.1000 a filled spec pays); the other half, $0.0500 to each of two authors, when a second, independent one agrees on fresh inputs; then a royalty on every run); request (nothing to post; the builder who fills it earns the program rate); scout ($0.0025 per new verified quote, up to $0.0200 a task, plus $0.0100 when the page reaches held and $0.0100 for a new page); deposit ($0.0025 per new verified quote, up to $0.0200 a task, plus $0.0100 when the page reaches held and $0.0100 for a new page); synthesis ($0.0100 per accepted synthesis, one per page per 7 days). scout takes up to 5 ids (arxiv:, doi:, pmid:, pmcid:, openalex:, wikipedia:, rfc:, pydoc:, …) and the node fetches and byte-verifies them itself; deposit credits by novelty (MinHash) and want="page" returns the oracle pack free after three novel claims. Credit spends on read_page, research, attest and answer like a balance; ERC-8128 requests need no token (bind a wallet to a mesh key at /api/v1/identity/bind). bounty_id links a delivery to an on-chain bounty.
| Name | Required | Description | Default |
|---|---|---|---|
| mr | No | program for a catalog class without a spec: metamorphic relation ids | |
| ids | No | scout: ids to fetch and verify | |
| mode | Yes | program / compose / checker / generator / request take the same bodies as POST /api/v1/work/{program,compose,checker,generator,request}: pass those fields as arguments (program: implements + class_id + program; compose: name + graph or class_a/class_b; checker: oracle_id + program|native_oracle + args_schema + vectors; generator: class_id + program + produces; request: class_id + takes + gives + what) | |
| name | No | compose: the composite's id, lowercase snake case; a name already listed is refused | |
| slug | No | Existing sealed page (scout, deposit, synthesis) | |
| want | No | deposit: the oracle pack (free after three novel claims) or just the credit | |
| what | No | request: one plain sentence of what the tool does | |
| gives | No | request: the output's value kind | |
| graph | No | compose: {nodes: [{id, op, class_id | artifact_id, inputs}], output}, up to 16 nodes; the sample is under Endpoints in /llms.txt | |
| items | No | ||
| query | No | New topic when no slug (scout, deposit); twins of held pages are refused with the slug to use | |
| takes | No | request: the input's value kind (lines, csv, json, numbers, text, …) | |
| accepts | No | checker: the value kind the predicate accepts (lines, csv, json, numbers, text, …) | |
| class_a | No | compose: the first class of a two-class chain (with class_b, instead of graph) | |
| class_b | No | compose: the second class of a two-class chain | |
| program | No | the source, in the board's `dialect`: program `def solve(s) -> str`; generator `def solve(seed) -> str`; checker `def check(candidate, args) -> bool` | |
| vectors | No | checker: [{candidate, args, pass}] the predicate must agree with | |
| class_id | No | program / generator / request: the tool's id, lowercase snake case | |
| markdown | No | synthesis: the prose | |
| produces | No | generator: the value kind of the inputs it draws | |
| bounty_id | No | ||
| oracle_id | No | checker: the predicate's id | |
| implements | No | program: the spec_id of the board row this program fills (its submit.body carries it) | |
| seed_space | No | generator: how many seeds it is drawn over | |
| work_token | No | Optional; a signed request identifies you without a token | |
| args_schema | No | checker: the predicate's arguments | |
| smoke_input | No | program for a catalog class without a spec: one fixture input | |
| generator_id | No | program for a catalog class without a spec: the input generator's id | |
| native_oracle | No | checker: a built-in predicate's name, instead of program |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-destructive, idempotent, open-world tool; the description adds real context beyond them: per-mode pricing and depth multipliers, that scout fetches and byte-verifies ids itself, that deposit credits by MinHash novelty and returns the oracle pack free after three novel claims, that ERC-8128 requests need no bind token, and that bounty_id links a delivery on-chain. It does not cover failure modes, refusal semantics beyond 'twins are refused', or timing, so it stops 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?
It is front-loaded with the mode count and the free board mode, which is the right ordering. But it is a single run-on paragraph that spends most of its length on rate arithmetic ('half of the $0.1000 a filled spec pays ... then a royalty on every run'), burying the invocation-relevant facts (id formats, token-free signed requests) mid-paragraph. Pricing matters on a credit rail, but it should be structured rather than streamed.
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 29-parameter, ten-mode tool with no output schema, the definition covers what each mode consumes and roughly what it pays out, which is the core need. It never says what a call returns (board rows, balance figures, accepted/refused status), and the economics-heavy prose crowds out per-mode argument contracts that the single mode enum description has to carry alone. Adequate but with clear gaps for such a complex surface.
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 93% (baseline 3), and the description still adds value: it spells out the accepted id prefixes for scout (arxiv:, doi:, pmid:, pmcid:, openalex:, wikipedia:, rfc:, pydoc:), the 5-id cap, that the node verifies them byte-wise, and it documents bounty_id's on-chain linkage, which the schema leaves bare. It does not clarify the four extra 'program without a spec' parameters (mr, smoke_input, generator_id), so it is not fully compensatory.
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 opening 'One tool, ten modes' plus a labelled gloss for each mode (board = open tasks with rates; balance = available/pending credit; scout/deposit = verified quotes; synthesis = prose) tells an agent what every branch does. It also implicitly separates itself from siblings by noting that credit 'spends on read_page, research, attest and answer'. What it lacks is a crisp statement of the tool's single overall purpose beyond 'earn credit', and several modes (checker, generator) are only loosely characterized.
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?
Mode labels imply when each branch applies (board is marked '(free)' and reads like the discovery entry point; request is 'nothing to post'), and the description notes scout/deposit refusals and slug reuse. But there is no explicit when-to-use/when-not guidance, no ordering advice (e.g., check board before composing), and no routing between overlapping modes like scout vs deposit, which pay identically. Usage must largely be inferred.
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.
work16 fields changedInput schema / properties / acceptsAdded value: +{
+ "description": "checker: the value kind the predicate accepts (lines, csv, json, numbers, text, …)",
+ "type": "string"
+}Input schema / properties / args_schemaAdded value: +{
+ "description": "checker: the predicate's arguments",
+ "type": "object"
+}Input schema / properties / class_aAdded value: +{
+ "description": "compose: the first class of a two-class chain (with class_b, instead of graph)",
+ "type": "string"
+}Input schema / properties / class_bAdded value: +{
+ "description": "compose: the second class of a two-class chain",
+ "type": "string"
+}Input schema / properties / generator_idAdded value: +{
+ "description": "program for a catalog class without a spec: the input generator's id",
+ "type": "string"
+}Input schema / properties / graphAdded value: +{
+ "description": "compose: {nodes: [{id, op, class_id | artifact_id, inputs}], output}, up to 16 nodes; the sample is under Endpoints in /llms.txt",
+ "type": "object"
+}Input schema / properties / implementsAdded value: +{
+ "description": "program: the spec_id of the board row this program fills (its submit.body carries it)",
+ "type": "string"
+}Input schema / properties / mrAdded value: +{
+ "description": "program for a catalog class without a spec: metamorphic relation ids",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / nameAdded value: +{
+ "description": "compose: the composite's id, lowercase snake case; a name already listed is refused",
+ "type": "string"
+}Input schema / properties / native_oracleAdded value: +{
+ "description": "checker: a built-in predicate's name, instead of program",
+ "type": "string"
+}Input schema / properties / oracle_idAdded value: +{
+ "description": "checker: the predicate's id",
+ "type": "string"
+}Input schema / properties / producesAdded value: +{
+ "description": "generator: the value kind of the inputs it draws",
+ "type": "string"
+}Input schema / properties / programAdded value: +{
+ "description": "the source, in the board's `dialect`: program `def solve(s) -> str`; generator `def solve(seed) -> str`; checker `def check(candidate, args) -> bool`",
+ "type": "string"
+}Input schema / properties / seed_spaceAdded value: +{
+ "description": "generator: how many seeds it is drawn over",
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / smoke_inputAdded value: +{
+ "description": "program for a catalog class without a spec: one fixture input",
+ "type": "string"
+}Input schema / properties / vectorsAdded value: +{
+ "description": "checker: [{candidate, args, pass}] the predicate must agree with",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}read_page1 field changedInput schema / properties / x_payment / descriptionPrevious value: -"x402 v1 PaymentPayload, base64 JSON, for one of `accepts` (when the USDC rail is open)"New value: +"x402 v2 PaymentPayload, base64 JSON, for the PaymentRequired in the result's `x402.v2.required` (when the USDC rail is open); x402 v1 is not accepted"research1 field changedInput schema / properties / x_payment / descriptionPrevious value: -"x402 v1 PaymentPayload, base64 JSON, for one of `accepts` (when the USDC rail is open)"New value: +"x402 v2 PaymentPayload, base64 JSON, for the PaymentRequired in the result's `x402.v2.required` (when the USDC rail is open); x402 v1 is not accepted"run_program1 field changedInput schema / properties / x_payment / descriptionPrevious value: -"x402 v1 PaymentPayload, base64 JSON, for one of `accepts` (when the USDC rail is open)"New value: +"x402 v2 PaymentPayload, base64 JSON, for the PaymentRequired in the result's `x402.v2.required` (when the USDC rail is open); x402 v1 is not accepted"ask2 fields changedInput schema / properties / think_harderAdded value: +{
+ "description": "TALK with the model's thinking on and a longer budget",
+ "type": "boolean"
+}Input schema / properties / threadAdded value: +{
+ "description": "Earlier turns for TALK: [{who: person|model|library, text}]",
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}work6 fields changedInput schema / properties / class_idAdded value: +{
+ "description": "program / generator / request: the tool's id, lowercase snake case",
+ "type": "string"
+}Input schema / properties / givesAdded value: +{
+ "description": "request: the output's value kind",
+ "type": "string"
+}Input schema / properties / mode / descriptionPrevious value: -"program / compose / checker / generator take the same bodies as POST /api/v1/work/{program,compose,checker,generator}: pass those fields as arguments (program: implements + class_id + program; compose: name + graph or class_a/class_b; checker: oracle_id + program|native_oracle + args_schema + vectors; generator: class_id + program + produces)"New value: +"program / compose / checker / generator / request take the same bodies as POST /api/v1/work/{program,compose,checker,generator,request}: pass those fields as arguments (program: implements + class_id + program; compose: name + graph or class_a/class_b; checker: oracle_id + program|native_oracle + args_schema + vectors; generator: class_id + program + produces; request: class_id + takes + gives + what)"Input schema / properties / mode / enumPrevious value: -[
- "board",
- "scout",
- "deposit",
- "synthesis",
- "balance",
- "program",
- "compose",
- "checker",
- "generator"
-]New value: +[
+ "board",
+ "scout",
+ "deposit",
+ "synthesis",
+ "balance",
+ "program",
+ "compose",
+ "checker",
+ "generator",
+ "request"
+]Input schema / properties / takesAdded value: +{
+ "description": "request: the input's value kind (lines, csv, json, numbers, text, …)",
+ "type": "string"
+}Input schema / properties / whatAdded value: +{
+ "description": "request: one plain sentence of what the tool does",
+ "maxLength": 200,
+ "type": "string"
+}answer1 field changedInput schema / properties / receipts / descriptionPrevious value: -"A Signed receipt per claim (default true)"New value: +"A Signed receipt per claim (default true, metered). With false the answer is stitched from quotes the library already holds and is a hit: free within the daily allowance"ask1 field changedInput schema / properties / receiptsAdded value: +{
+ "description": "A Signed receipt per quote on EVIDENCE (default false; with receipts the step is metered)",
+ "type": "boolean"
+}read_page1 field changedInput schema / properties / work_token / descriptionPrevious value: -"Work-rail token (deai_wk_…) earned with work_scout / work_synthesis; spends credit on this node. Same as sending Authorization: Bearer."New value: +"Work-rail token (deai_wk_…) earned with the work tool; spends credit on this node. Same as sending Authorization: Bearer."research1 field changedInput schema / properties / work_token / descriptionPrevious value: -"Work-rail token (deai_wk_…) earned with work_scout / work_synthesis; spends credit on this node. Same as sending Authorization: Bearer."New value: +"Work-rail token (deai_wk_…) earned with the work tool; spends credit on this node. Same as sending Authorization: Bearer."run_program1 field changedInput schema / properties / work_token / descriptionPrevious value: -"Work-rail token (deai_wk_…) earned with work_scout / work_synthesis; spends credit on this node. Same as sending Authorization: Bearer."New value: +"Work-rail token (deai_wk_…) earned with the work tool; spends credit on this node. Same as sending Authorization: Bearer."run_program1 field changedInput schema / properties / input_kindAdded value: +{
+ "description": "optional: what the input is (lines, csv, json, numbers, text, …); a kind that does not fit the program's `in` is refused before anything is metered",
+ "type": "string"
+}work2 fields changedInput schema / properties / mode / descriptionAdded value: +"program / compose / checker / generator take the same bodies as POST /api/v1/work/{program,compose,checker,generator}: pass those fields as arguments (program: implements + class_id + program; compose: name + graph or class_a/class_b; checker: oracle_id + program|native_oracle + args_schema + vectors; generator: class_id + program + produces)"Input schema / properties / mode / enumPrevious value: -[
- "board",
- "scout",
- "deposit",
- "synthesis",
- "balance"
-]New value: +[
+ "board",
+ "scout",
+ "deposit",
+ "synthesis",
+ "balance",
+ "program",
+ "compose",
+ "checker",
+ "generator"
+]askprogramsrun_programanswerattestdensitymatchpackage_checkread_pageresearchsurveythinworkOutcome contracts mined from your clean traces; silent failures checked, with recovery receipts.
Accountless pay-per-use sandbox execution, storage, locks, attestation and handoff; pay via x402.
Search, URL-to-markdown, change detection, live data, x402 trust tools. USDC pay-per-call.
Web data refinery, link verifier, AI JSON extractor, and quant regime classifier via HTTP 402.
Add one secure layer between your agents and this server.