Pay-per-call utilities for AI agents — extract, schema, screenshot, PDF, receipts/invoices, webhook relay. Prepaid credits or x402 USDC on Base.
Score is being calculated.
Render a public URL to a PNG/JPEG screenshot for vision, QA, or audit evidence. Call when you need pixels — not structured text (use extract.webpage) and not PDF bytes (use extract.pdf). Inputs: required url; optional viewport {width,height}, fullPage, format=png|jpeg. Viewport capped; SSRF/robots fail-closed. Outputs image metadata + base64. Paid (~10 credits / $0.10) via prepaid key or x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to screenshot. Example: https://example.com | |
| format | No | Image format. Example: png | |
| fullPage | No | If true, capture full scrollable page. Example: false | |
| viewport | No | Viewport size within caps (width 320–1920, height 320–1080). Example: {"width":1280,"height":800} |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, idempotent, open-world operation. The description adds meaningful context beyond that: viewport caps, fail-closed SSRF/robots handling, output shape (metadata + base64), and paid credit cost.
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 tight and front-loaded: purpose, usage decision, inputs, constraints, outputs, and cost all appear in a few dense sentences. No wasted words.
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 screenshot capture tool with an output schema and clear annotations, the description covers the essential operational context: when to call it, what it returns, cost, and failure behavior. Nothing critical 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?
Schema description coverage is 100%, so parameters are already well documented. The description simply lists required and optional inputs without adding new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear verb and resource: render a public URL to a PNG/JPEG screenshot. It also distinguishes itself from sibling tools by stating it produces pixels, not structured text or PDF bytes.
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 says when to use it ('when you need pixels') and when not to, naming extract.webpage and extract.pdf as alternatives. It also adds practical context such as cost and SSRF/robots fail-closed behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract page text and heuristic tables from a base64-encoded PDF for downstream reasoning. Call for general PDF text hops — receipt/invoice field extraction belongs to parse.receipt / parse.invoice. Inputs: file_base64 (or pdf/base64 aliases); optional options.includeTables / maxPages. Decoded size ≤ 10 MiB. Outputs pages[].text and optional tables. Paid (~10 credits / $0.10) via prepaid key or x402.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Alias for file_base64 | ||
| base64 | No | Alias for file_base64 | |
| options | No | includeTables (bool), maxPages (1–100). Example: {"includeTables":true,"maxPages":10} | |
| file_base64 | No | Base64 PDF bytes; decoded ≤ 10 MiB. Example: JVBERi0xLjQK... |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the decoded size limit (≤ 10 MiB), the paid nature (~10 credits / $0.10), the payment method (prepaid key or x402), and the output shape (pages[].text and optional tables). It does not contradict annotations. A small gap is that it doesn't mention failure behavior for oversized PDFs, but the size limit is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core action and resource appear in the first sentence, followed by routing guidance, input format, options, size limit, output shape, and cost. Every sentence earns its place, and the structure moves from what → when → how → constraints → output → cost. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, nested options, aliases, size limit, cost, output schema), the description covers all the essential context: what it does, when to use it, what inputs to provide, the size constraint, the cost, and the output shape. The output schema exists, so the description needn't detail return values beyond naming pages[].text and optional tables. An agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters and aliases. The description adds value by clarifying the alias relationship ('file_base64 (or pdf/base64 aliases)') and the meaning of the options (includeTables / maxPages) in plain language. It also states the decoded size limit, which is a semantic constraint on file_base64. This goes beyond the schema's per-parameter descriptions, though the schema already does most of 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 states a specific verb ('Extract'), a specific resource ('page text and heuristic tables from a base64-encoded PDF'), and the downstream purpose ('for downstream reasoning'). It also explicitly distinguishes itself from parse.receipt / parse.invoice, which are the closest siblings. An agent can tell this apart from extract.structured_data and extract.webpage without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call for general PDF text hops' and explicitly excludes receipt/invoice field extraction by naming the alternatives parse.receipt / parse.invoice. It also states the input format (base64), size limit (≤ 10 MiB), and optional options. This is clear context with explicit exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured JSON (emails, phones, URLs, key-values, or schema-shaped fields) from messy plain text or HTML. Call when the agent already has document text/HTML and needs machine-readable fields for the next step — not for fetching a live URL (use extract.webpage). Inputs: exactly one of text or html; optional instruction, schema, require_llm. Outputs structured JSON; fail-closed on invalid input. Paid (~5 credits / $0.05) via prepaid key or x402.
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | HTML fragment/document to structure. Example: '<p>Email us at hello@acme.io</p>' | |
| text | No | Plain text to structure. Do not pass a URL here — use extract.webpage. Example: 'Contact Jane at jane@acme.io or +1-415-555-0100.' | |
| schema | No | Optional JSON Schema the extract should satisfy | |
| instruction | No | Optional focus hint (max 500 chars). Example: 'Extract contact fields only' | |
| require_llm | No | If true and enrichment LLM unavailable → processing failure (no charge on fail-closed). Example: false |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it states the tool 'fail-closed on invalid input', mentions the paid nature (~5 credits / $0.05) via prepaid key or x402, and notes that require_llm=true can cause processing failure if the LLM is unavailable. This is useful operational transparency that the annotations do not provide.
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 compact and front-loaded: the first sentence states the core purpose, the second gives the when-to-use condition and sibling distinction, and the remaining sentences cover inputs, outputs, and cost/failure behavior. Every sentence earns its place, and the total length is appropriate for a tool with 5 parameters.
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?
The description is complete for an extraction tool with a rich schema and output schema. It covers the input constraint, the alternative tool, the output type, the fail-closed behavior, and the cost model. The output schema exists, so the description need not explain return values. Nothing an agent needs to call this 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?
Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds a small amount of extra meaning by summarizing the input constraint ('exactly one of text or html') and the optional nature of instruction/schema/require_llm, but it does not add significant detail beyond what the schema provides. 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?
The description states a specific verb ('Extract structured JSON') and resource ('messy plain text or HTML'), and explicitly distinguishes itself from extract.webpage by noting it is not for fetching a live URL. It also lists the kinds of fields it can extract (emails, phones, URLs, key-values, schema-shaped fields), making the tool's purpose immediately clear.
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 description gives explicit when-to-use guidance: 'Call when the agent already has document text/HTML and needs machine-readable fields for the next step.' It also names the alternative (extract.webpage) and the condition that selects it ('not for fetching a live URL'). The input constraint 'exactly one of text or html' is also stated, which is critical for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public http(s) URL and return structured page facts as JSON (SSRF/robots fail-closed). Call when the agent has a page URL to understand — not when text/HTML is already in hand (use extract.structured_data) and not for a visual capture (use capture.screenshot). Inputs: required url; optional instruction, schema, require_llm. Outputs structured JSON about the page. Paid (~5 credits / $0.05) via prepaid key or x402.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public http(s) URL to fetch and structure. Example: https://example.com/about | |
| schema | No | Optional JSON Schema the page extract should satisfy | |
| instruction | No | Optional focus hint for extraction. Example: 'Extract company name and contact emails' | |
| require_llm | No | If true and enrichment LLM unavailable → processing failure. Example: false |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description adds useful operational context: SSRF/robots fail-closed, paid cost (~5 credits / $0.05), and x402/prepaid key payment. No contradiction with annotations is present.
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 compact and front-loaded with the core purpose, then usage guidance, inputs, outputs, and cost. It is slightly listy in the inputs/outputs sentence, but every sentence contributes useful 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?
Given the rich input schema, output schema, and annotations, the description covers the essential decision-making context: when to use, what it returns, failure behavior, and cost. Minor details such as redirect or timeout handling are not mentioned, but nothing critical is missing for selecting and invoking the 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 description coverage is 100%, so the schema already documents url, instruction, schema, and require_llm. The description only lists parameter names and required/optional status, adding no deeper meaning 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?
Description opens with a specific verb and resource: 'Fetch a public http(s) URL and return structured page facts as JSON.' It also distinguishes itself from siblings by explicitly naming extract.structured_data and capture.screenshot as alternatives for different situations.
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?
Provides explicit when-to-use and when-not-to-use guidance: 'Call when the agent has a page URL to understand — not when text/HTML is already in hand' and 'not for a visual capture.' The alternatives are named, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a tax invoice or commercial invoice into the AfricaInvoiceReceipt contract: seller (TIN / KRA PIN / VAT no), issued date, currency, line items, VAT rate/amount, subtotal, total, payment refs, confidence, and warnings (including vat_total_mismatch). Built for NG/KE/GH/ZA AP automation and multi-line SKU invoices — not a thin keyword grep. Use when the document is an invoice rather than a till slip; still accept OCR text or image/PDF base64. Nulls mean unknown; do not treat low-confidence totals as ledger truth without checking confidence and warnings. Costs $0.15 (15 credits) per successful response; fail-closed prepaid or x402.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | OCR or plain-text dump of the tax invoice. Example: 'TAX INVOICE\nDANGOTE CEMENT PLC\nTIN: 01012345-0001' | |
| tier | No | Processing tier. Example: auto | auto |
| filename | No | Original filename hint. Example: invoice.pdf | |
| file_base64 | No | PDF or image bytes as base64 | |
| content_type | No | MIME type of file_base64. Example: application/pdf |
| Name | Required | Description |
|---|---|---|
| tax | Yes | |
| buyer | No | |
| total | Yes | |
| payment | No | |
| currency | Yes | |
| doc_type | Yes | |
| merchant | Yes | |
| subtotal | Yes | |
| warnings | Yes | |
| issued_at | Yes | YYYY-MM-DD or null |
| confidence | Yes | |
| line_items | Yes | |
| amount_paid | No | |
| balance_due | No | |
| document_id | No | |
| locale_hints | No | |
| raw_text_excerpt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds substantial behavioral context: it is 'not a thin keyword grep', nulls mean unknown, low-confidence totals should not be treated as ledger truth, and it fails closed with cost per successful response. No contradiction with annotations.
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?
Description is dense but purposeful: front-loaded output contract, then usage rule, input formats, and key behavioral caveats. Every sentence contributes, though a few details (e.g., 'still accept OCR text or image/PDF base64') overlap with the schema.
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 extraction tool with an output schema, this description is remarkably complete: it names the extracted fields, the warning type, the country scope, the input modes, the confidence/null semantics, and even the cost/failure behavior. Nothing required to select or call the tool 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?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that text OR file_base64 is accepted and maps to the oneOf, but does not add meaningfully deeper semantics for tier, filename, or content_type beyond the schema's own descriptions.
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?
Description states a specific verb ('Parse') and resource ('tax invoice or commercial invoice') and enumerates the concrete output contract (seller, dates, VAT, totals, warnings). It also explicitly distinguishes from till slips/receipts, helping differentiate from sibling parse.receipt.
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 condition: 'Use when the document is an invoice rather than a till slip.' It also mentions the input forms it accepts and the target geographies/AP automation context. It doesn't explicitly name sibling tools or exclusions beyond the till-slip case, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a till slip, POS printout, supermarket receipt, or mobile-money payment confirmation into stable merchant / date / currency / subtotal / tax / total / line_items / confidence / warnings JSON. Tuned for ugly Africa documents (NGN ₦/kobo, KES M-Pesa, GHS MTN MoMo, ZAR VAT, OPay, PalmPay, Paystack, Verve POS) including blurry OCR and WhatsApp forwards. Send text (OCR dump) or file_base64. Unknown fields are null or empty arrays — totals and line items are never invented from garbage. Prefer this over manual spreadsheet entry or a generic LLM scrape when the document is a receipt or MoMo/M-Pesa slip. Costs $0.10 (10 credits) per successful parse; fail-closed billing via prepaid credits or x402.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | OCR or plain-text dump of the receipt. Example: 'MAMA CHIKA\nRice 50kg NGN 48000\nTotal 61812.50' | |
| tier | No | Processing tier. Example: auto | auto |
| filename | No | Original filename hint. Example: receipt.jpg | |
| file_base64 | No | PDF or image bytes (jpeg/png/webp/pdf) as base64 | |
| content_type | No | MIME type of file_base64. Example: image/jpeg |
| Name | Required | Description |
|---|---|---|
| tax | Yes | |
| buyer | No | |
| total | Yes | |
| payment | No | |
| currency | Yes | |
| doc_type | Yes | |
| merchant | Yes | |
| subtotal | Yes | |
| warnings | Yes | |
| issued_at | Yes | YYYY-MM-DD or null |
| confidence | Yes | |
| line_items | Yes | |
| amount_paid | No | |
| balance_due | No | |
| document_id | No | |
| locale_hints | No | |
| raw_text_excerpt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations (read-only, idempotent, no side effects), the description adds meaningful behavior: unknown fields become null/empty arrays, totals and line items are never invented, and billing is fail-closed ($0.10 only on success). No contradiction with the annotations.
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 a concrete verb and precise input scope, then covers geography, input modes, failure semantics, and pricing in four tight sentences. No repetition of schema boilerplate.
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?
Covers input selection (text vs file_base64), document scope, output shape, failure behavior, billing, and geographic tuning. With an output schema present, this is more than sufficient for an agent to decide when to call the tool and what to pass.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces that input can be either text or file_base64 but does not add meaningfully beyond the schema's own descriptions. No penalty, but no extra semantic value either.
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?
Opens with 'Parse...' plus an explicit list of document types (till slip, POS printout, supermarket receipt, M-Pesa slip) and names the stabilized output fields. This clearly separates parse.receipt from generic extract.* siblings by domain and result shape.
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 explicit when-to-use guidance ('when the document is a receipt or MoMo/M-Pesa slip') and tells the agent to prefer it over manual parsing or a generic LLM scrape. It does not explicitly contrast with the sibling parse.invoice, but the document-type framing is sufficient for most routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relay a third-party webhook into CallMeter: verify HMAC or shared secret, dedupe by delivery id, store the payload, and forward to the endpoint's destinations with retries. Charges 0.01 credits ($0.0001) only per successful forward — not on receive. SIDE EFFECTS: contacts external destination URLs you configured; may retry on failure. Prefer when an agent must accept provider callbacks without running its own queue. Fail-closed on billing/ceiling errors. Inputs: required id (endpoint id) plus upstream JSON body.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | CallMeter webhook endpoint id (ep_…). Example: ep_live_abc123 | |
| deliveryId | No | Optional idempotent delivery id (maps to X-Webhook-Delivery-Id). Same id within 24h dedupes — no second charge. |
| Name | Required | Description |
|---|---|---|
| status | No | accepted | duplicate | forwarded |
| accepted | No | True when ingress accepted for forward pipeline |
| duplicate | No | True when same delivery id within 24h dedupe window (no re-charge) |
| delivery_id | No | Stored delivery id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important side effects and operational behavior beyond annotations: 'SIDE EFFECTS: contacts external destination URLs you configured; may retry on failure,' the pay-per-success billing model, dedupe by delivery id, and fail-closed on billing/ceiling errors. This is detailed and honest about external calls, retries, and charging, which an AI agent needs before invoking a side-effecting webhook relay.
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?
Every sentence carries distinct information: purpose, billing, side effects, usage context, and input requirements. It is front-loaded with the main verb and resource, and it avoids filler or redundant restatement of the tool name.
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?
The description covers what the tool does, when to prefer it, side effects, retry behavior, billing, deduplication, and fail-closed behavior. Combined with the detailed input schema, an agent has enough context to select and invoke the tool correctly without guessing about external consequences.
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 high (id and deliveryId both documented), so the baseline is 3. The description adds genuine value by saying the upstream JSON body is an input and clarifying that 'id' is the endpoint id, plus framing deliveryId's dedupe behavior. It doesn't independently document parameters but reinforces the core calling convention.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Relay a third-party webhook into CallMeter') and unpacks the exact pipeline: verify HMAC/shared secret, dedupe by delivery id, store payload, forward to destinations with retries. This clearly distinguishes it from the sibling tools, especially since the 'relay' action of receiving callbacks is distinct from replaying or extracting.
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?
Provides an explicit usage directive: 'Prefer when an agent must accept provider callbacks without running its own queue.' This tells the agent when to choose the tool, but it does not explicitly say when not to use it or name an alternative tool for resending/retrying events. Still, the use case is clear and specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replay a stored webhook delivery through the same forward/retry pipeline after your consumer was down. Requires API key. Charges 0.01 credits ($0.0001) per successful forward. SIDE EFFECTS / DESTRUCTIVE: re-POSTs the original payload to destinations and may bill again — do not call casually. Prefer after confirmed consumer recovery. Fail-closed on billing errors. Inputs: required id (delivery id).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Delivery id to replay. Example: dlv_01HXYZ |
| Name | Required | Description |
|---|---|---|
| error | No | Present on 409-style conflict |
| status | No | forwarded | conflict | failed |
| replayed | No | |
| delivery_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: it discloses that the action re-POSTs the payload, may bill again, charges 0.01 credits per successful forward, requires an API key, and fails closed on billing errors. This is exactly the kind of destructive and financial side-effect context an agent needs.
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 compact and front-loaded with the primary purpose, followed by auth, cost, side effects, and usage caution. Every sentence contributes essential information, and the destructive warning is prominently placed. No filler or repetition.
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 destructive, non-idempotent, billing-sensitive tool, the description covers purpose, prerequisites, cost, side effects, failure behavior, and when it is appropriate to call. The output schema exists, so omitting return-value details is acceptable. The description is complete for safe 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?
The schema covers 100% of the single parameter with a clear description and example. The description merely restates 'required id (delivery id),' which adds no meaning beyond the schema. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Replay a stored webhook delivery through the same forward/retry pipeline.' It also states the intended context ('after your consumer was down'), which distinguishes it from a generic send tool like relay.webhook. This is clear, specific, and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: use after the consumer was down and 'Prefer after confirmed consumer recovery.' It warns not to call casually. However, it does not explicitly name alternatives or state when not to use it versus relay.webhook, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a JSON Schema from a sample object, or validate an instance against a schema, in one call. Call before writes when you need a deterministic schema or a cheap validity check — cheaper and more predictable than asking an LLM to invent types. Inputs: mode=draft|validate|both; sample for draft; schema+instance for validate. Outputs schema and/or validation result. Paid (~2 credits / $0.02) via prepaid key or x402.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | draft | validate | both. Example: draft | |
| draft | No | Legacy boolean alias to request drafting. Example: true | |
| sample | No | Sample value to draft a schema from. Example: {"orderId":"A1","total":12.5} | |
| schema | No | JSON Schema document (required for validate/both). Example: {"type":"object"} | |
| instance | No | Value to validate. Example: {"a":1} |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful cost information (paid, ~2 credits / $0.02), the batch capability, and the output shape. This is useful context beyond the structured metadata.
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 sentences cover purpose, usage context, mode/input mapping, output, and cost with no filler. The most important information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (5 parameters, mode enum, output schema), the description covers the overall workflow, parameter selection, output, and cost in a compact way. The output schema and input schema take care of the remaining structural detail.
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 already covers all 5 parameters, and the description adds a useful mode-to-parameter mapping: 'sample for draft; schema+instance for validate'. It doesn't explain the legacy 'draft' boolean or the 'both' combination in depth, but the schema fills those details.
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 clearly states both actions ('Draft a JSON Schema from a sample object', 'validate an instance against a schema') and says they can happen in one call. It is immediately distinguishable from the sibling tools, none of which cover JSON Schema generation or validation.
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 'Call before writes' guidance gives an explicit use case, and the comparison to LLM inference tells an agent when this tool is a better fit. It does not explicitly cover exclusion cases or name alternatives, so it misses the top criterion.
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.
capture.screenshotextract.pdfextract.structured_dataextract.webpageparse.invoiceparse.receiptrelay.webhookreplay.webhooktransform.json_schema
