Verified-artifact library: match, ask, run fixture programs, reuse sealed pages (HTTP 402 toll).
Scored across 13 tools
The set has explicit internal overlap: `ask` is documented as routing into `research`, `answer`, and model-talk outcomes, and `answer` independently produces stitched answers from the same verified claims, so an agent cannot cleanly decide between `ask`, `answer`, and `research`. `match`, `programs`, `thin`, and `survey` all rank or adjudicate sealed pages with fuzzy boundaries, and `package_check` (npm/PyPI registry metadata) is a completely unrelated capability bolted onto an artifact-verification server. `work` further absorbs board/scout/deposit/synthesis/balance/request, duplicating `survey`-adjacent and `research`-adjacent behaviors inside a single opaque tool.
Names mix bare verbs (`answer`, `ask`, `attest`, `match`, `research`, `survey`), bare nouns (`density`, `programs`, `thin`, `work`), and verb_noun forms (`read_page`, `run_program`, `package_check`). There is no predictable pattern to predict a tool's name from its action, and `thin`/`density` are not self-describing at all. The presence of both `programs` and `run_program` shows the convention drift within the same sub-domain.
Thirteen tools is nominally a reasonable count for this scope, but the effective surface is much larger because `ask` and especially `work` are multi-mode tools (five modes in `work`) that hide many operations behind one entry. Combined with `package_check` occupying a slot for an unrelated domain, the scoping feels heavy rather than crisp.
Core lifecycle is largely covered: discover (`match`, `programs`, `thin`, `density`), acquire (`research`, `read_page`, `run_program`), verify (`attest` mode=verify, receipts), rate (`survey`), and contribute (`work` deposit/scout/synthesis/request, bounty linking). Gaps remain: there is no way to browse or text-search sealed pages directly, no update/retract/delete for a minted page or its seal, and no standalone identity/balance/account tool outside `work`.
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?
Annotations cover the safety profile (readOnly, non-destructive), and the description goes well beyond them: it discloses mode fallback behavior, that response.mode reports which path ran, byte-exact post-verification of quotes, and the billing/metering model (free without matching claims, receipts and model drafts metered). This is unusually rich behavioral context; it stops short of explaining return structure or rate limits explicitly.
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 'Extractive by default', which is good, but the single dense paragraph is packed with jargon ('1.58-bit model', 'Signed citation receipt', 'stitched') that impedes quick scanning. Every sentence carries some payload, yet the structure is heavier than needed.
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 must convey the return shape; it partially does (response.mode, saves token estimate, source list with byte spans), which is helpful. But it omits explanation of several payment/session parameters and does not cover error or fallback edge cases fully, so it is adequate rather than complete.
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 29% across 7 parameters. The description partially compensates by explaining mode (extractive vs generative, response.mode), receipts (metered vs free), and slugs indirectly, but x_payment, work_token, max_claims, and question constraints go undocumented in both schema and prose — a significant gap for a 7-param 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 states a specific verb (answer) and resource (verified claims) and explains the mechanism: extractive by default, quotes stitched with connectives and [n] markers, receipts per claim. It is clear enough to distinguish 'answer' as a quote-assembly tool, though it never contrasts itself with the near-identical sibling 'ask'.
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 implies usage with 'One call in place of a crawl-and-summarise loop' and defines free/metered conditions, which is real context. However, there is no explicit when-not guidance and no comparison to siblings like ask or research, leaving the agent to infer the right choice.
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?
Beyond the annotations, the description discloses costs (¢0.1, free daily allowance, metered receipts), escalation behavior, miss behavior naming research/deposit with prices, and output-shape differences for talk and synthesis. It does not directly contradict readOnlyHint=true, destructiveHint=false, or openWorldHint=false, though its dense mode logic leaves some operational edge cases unclear.
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 opening 'When to call' is front-loaded, but the definition becomes a long, dense paragraph with semicolon-chained conditionals and specialized vocabulary. The content is substantive, but the lack of structure and heavy nesting hurts readability and makes it hard to scan.
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 nine parameters, the description carries significant burden and does explain key return paths such as step_taken values, model/actions, synthesis.sentences[].backed, and research/deposit miss behavior. It is fairly complete for a complex routing tool, though missing payment/work-token semantics and some conditional clarity keeps it from being fully complete.
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 description adds useful meaning for ask, input, class_id, thread, receipts, and allow_escalate, clarifying when each matters in the routing flow. However, schema coverage is 67% and parameters like x_payment and work_token remain undocumented in both schema and description, so it does not fully compensate for the gaps.
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 several internal modes (MATCH, RUN, EVIDENCE, TALK, synthesis) but never states a single clear purpose beyond 'you have a question or a payload and want the cheapest verified step.' It implies an orchestration/query tool, yet the overloaded framing and cryptic title make it harder to distinguish from siblings like match and 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?
It explicitly opens with 'When to call' and then gives concrete conditions for each mode: MATCH when listing classes/pages, RUN when the class is certain and input is present, EVIDENCE otherwise, research verbs routing to research, and TALK/synthesis on member nodes. It also names alternatives and constraints such as allow_escalate only for the caller's own engine.
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 declare read-only, idempotent, non-destructive behavior. The description adds that the operation is free and that minting a duplicate concept after a match hit is a defect, which is useful behavioral context, but says nothing about rate limits, auth, or return format beyond the cryptic price-quote mention.
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 are front-loaded with the core ranking behavior, then usage and defect context. No filler, though the jargon reduces immediate 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 one-parameter, no-output-schema tool with full annotation coverage, the description gives some output flavor (price quotes, token savings), but leaves 'sealed pages', 'reuse/repair/mint', and 'packs' undefined. An agent can invoke it but may lack confidence in interpreting results.
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 schema covers the single parameter 'q' at 100% with a description. The description adds no syntax, format, or constraints for the query beyond what the schema provides. 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 the tool ranks sealed pages against a task and returns price quotes and token savings, but 'sealed pages' and 'mint' are unexplained jargon. It distinguishes itself from paid siblings only by calling itself 'the free step', not by naming alternatives. Purpose is inferable but not crisp.
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 positions the tool as 'the free step before any paid one' and warns that minting a duplicate concept after a match hit is a defect. It gives clear when-to-use context, though it doesn't name specific paid alternatives.
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/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: it is free, contains 'no user text in any program', the per-run price is ¢0.1, and it lists the row fields returned. Pagination/limits are not mentioned, keeping 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?
Three dense sentences that front-load the trigger ('Before you write a transform') and then cover inventory, row shape, and cost. Nothing is filler, though the terse parenthetical list of program kinds is slightly cluttered.
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 by describing the returned columns, the run price, and the privacy constraint, which is what an agent needs to call and interpret it. It omits any detail on result size or filtering, a minor gap for a catalog 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% for the single optional class_id, and the schema already says 'return the full artifact for this class'. The description's 'Pass class_id for the full artifact' restates that rather than adding syntax or a new use case, so 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?
States a specific verb (list) and resource (public fixture programs, authored oracles, composites) with an explicit scope. It implicitly points at the sibling run_program via 'before you write a transform' but does not name it, so the sibling differentiation is inferred rather than stated.
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?
'Before you write a transform, list...' gives a clear situational trigger for invoking the catalog. It does not enumerate when NOT to use it or explicitly name the alternative tool to use instead, but the context is unambiguous.
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?
Goes well beyond the annotations by disclosing the pricing model (reuse tier, about ¢2, priced as a share of replaced tokens, typically 40–60k, shown as saves.tokens), the exact failure mode of an unpaid call (status=payment_required with rails, accepts, saves and a retry block), and that stubs are free. That is precisely the billing/permission context annotations cannot express.
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 information-dense sentences, front-loaded with what is returned before pricing and the payment-required path. No filler, though the packed parenthetical enumerations make it heavier to parse than necessary.
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 carries the return-shape burden and does so by naming the payload sections, plus it explains the payment negotiation cycle. The main gap is routing: it never says when to call this instead of sibling read tools such as match, thin, density or answer.
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 slug, pow_nonce, pow_challenge, x_payment and work_token. The description adds flow context for the payment path (payment_required result, retry block, free stubs) but no field-level semantics beyond the schema, 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?
States a specific verb and resource: reads the 'sealed oracle pack for a slug' and returns it as 'deterministic JSON', then enumerates the payload (markdown, claims with byte-exact quotes and spans, source CIDs, licence, receipts, review, labels, strength). It is clearly distinguished from write-ish siblings like attest or work, though the jargon 'sealed oracle pack' and 'reuse tier' are not explained in plain terms.
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 only implied: the slug is 'from match, thin, or density', which hints at the upstream discovery flow, and 'stubs are free' hints at a preview path. There is no explicit statement of when to prefer this over answer, ask, research, or survey, and no statement of when not to call it.
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 cover read-only/non-destructive/closed-world, and the description adds genuinely new behavior: metered cost (¢0.1), deterministic re-execution, and that a receipt accompanies the output. It does not mention the payment/PoW rails or failure modes beyond the class-selection step, but nothing contradicts the annotations (charging for a read does not violate readOnlyHint).
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 tightly packed sentences with the core behavior and cost front-loaded, then the routing hint. Slightly telegraphic (abbreviated '¢0.1', parenthetical class list) but no wasted 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?
With no output schema, the description supplies the return shape ('output + receipt'), the cost, and the discovery prerequisite. The payment/PoW flow is only implied and left to schema field descriptions, but the essentials for a correct call are present.
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 71% and the schema itself documents pow_nonce, x_payment, input_kind, and work_token. The description only indirectly adds meaning via the 'call match or programs first' hint for class_id, and says nothing about the required class_id/input pairing beyond that. Baseline 3 is appropriate.
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 ('deterministic verified transform ... re-executed on your input') and enumerates the transform classes (sort/dedup/json/csv/case/date/extract), so an agent can distinguish it from match/programs without opening the schema. It also states the cost and return shape inline.
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 routes the agent: 'Call match or programs first to find the class', which gives the prerequisite for the required class_id. It does not say when to prefer one of those siblings over the other, nor any exclusion cases, so it stops short of full when/when-not guidance.
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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds genuine behavioral context beyond that: the ordering rule ('loneliest first') and the fact that each item carries repair arguments plus a repair price. It stops short of saying what a 'repair price' is measured in, leaving the output semantics partly 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?
A single sentence with no filler or repetition; every clause carries content (scope, ordering, per-item payload). It is slightly overloaded, packing filter criteria, sort order, and output contents into one dense clause, but nothing 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 zero-parameter, read-only tool with no output schema, the description does cover what comes back (pages plus repair arguments plus price) and in what order. However, the metaphorical vocabulary leaves key questions unresolved — what counts as 'thin' versus 'unreviewed' versus 'woven to nothing', and what 'repair price' denominates — so an agent cannot fully predict the result set.
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 properties, additionalProperties=false), so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side, and it correctly does not invent parameter guidance.
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 a discernible function: it returns a list of 'thin' pages with repair arguments and a repair price. But the core terms ('sealed pages', 'woven to nothing', 'thin') are idiosyncratic domain jargon that an agent cannot reliably map to a concrete resource, and it does not differentiate itself from plausible siblings like 'density' or 'read_page'. Specific verb+resource exists only in the tool's private vocabulary.
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 use this versus alternatives such as 'density', 'survey', or 'read_page'. The only usage-adjacent cue is '(free)' in the title, which hints at cost but not selection criteria. The agent is left to infer the trigger condition entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One tool, five modes. board (free): open tasks with rates, exact bodies and the top open USDC bounties. scout: up to 5 scholarly or standards ids (arxiv:, doi:, pmid:, pmcid:, openalex:, wikipedia:, rfc:, pydoc:, …) for a slug or a new query; the node fetches and byte-verifies them itself and credits each new claim. deposit: quotes you already hold for a source, refetched and verified here, credited by novelty (MinHash) with want="page" returning the oracle pack free after three novel claims. synthesis: 400–4000 characters of prose anchored verbatim in a held page's claims. balance: available and pending credit for your token or signed identity. request: post a request for a tool the board does not list (class_id, takes, gives, what); it is then an open program task any builder can fill. Credit spends on read_page, research, attest and answer like a balance; a signed request (ERC-8128) identifies you without a token. bounty_id links a delivery to an on-chain bounty.
| Name | Required | Description | Default |
|---|---|---|---|
| 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) | |
| 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 | |
| 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, …) | |
| class_id | No | program / generator / request: the tool's id, lowercase snake case | |
| markdown | No | synthesis: the prose | |
| bounty_id | No | ||
| work_token | No | Optional; a signed request identifies you without a token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only, open-world, idempotent, and non-destructive. The description adds meaningful behavior beyond that: scout fetches and byte-verifies sources and credits new claims, deposit refetches and credits by MinHash novelty, want='page' gives a free oracle pack after three novel claims, and signed requests can identify users without a token. It does not discuss rate limits or failure modes, so not 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 and dense, with no obvious filler sentences. But the opening claim 'One tool, five modes' conflicts with the ten-value mode enum, and the long semicolon-separated mode summaries are hard to parse. Structure is serviceable but inconsistent.
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 tool with ten modes, thirteen parameters, and no output schema, the description is incomplete. It covers board, scout, deposit, synthesis, balance, and request but omits program, compose, checker, and generator entirely, and it does not describe return values or authentication behavior for most modes.
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 high at 85%, so the baseline is 3. The description adds mode-to-parameter mapping and examples such as accepted id prefixes (arxiv:, doi:, pmid:, etc.), want values page vs. credit, and the request fields what/gives/takes. It does not explain the parameters needed by program, compose, checker, or generator modes.
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 the overall purpose ('work rail: earn credit instead of paying') and defines several modes specifically. However, it says 'One tool, five modes' while the mode enum contains ten values, and it omits program/compose/checker/generator entirely. That mismatch makes the full purpose of the tool unclear from the description 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 gives per-mode usage hints, such as board being free, scout for fetching/verifying ids, deposit for held quotes, and request for tools not on the board. It also notes that credit spends on read_page, research, attest and answer. But it never states when not to use this tool or how to choose between it and siblings like ask, survey, or programs.
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.
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.