Skavio USDC Payment Verification & Proof MCP

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

Annotations only declare safe/idempotent/open-world hints; the description adds substantial undisclosed context: a separate Bearer-authenticated relay, an enabled backend operation, an accepted payment mode, x402 quote vs prepaid credit billing, and "no anonymous execution." It also correctly frames admission as asynchronous ("admission is not delivery"), which the annotations cannot convey. It stops short of stating rate limits, timeouts or cost magnitudes.

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?

Purpose, exclusions and billing are front-loaded in the first three sentences, with the async polling workflow after. Information density is high and nearly every clause carries weight, though the auth/payment sentence packs four distinct constraints into one line and could be split for scanability.

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, and the description compensates by explaining that the call only enqueues work and that results come from skavio_agent_job_result with SHA256 verification. Combined with the payment-mode and idempotency guidance, an agent has everything needed to call this correctly and recover from failure.

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 data_base64, units and payment_mode; the baseline would be 3. The description earns above baseline by explaining the semantic role of idempotency_key ("retry with the SAME idempotency_key and inputs, not a new job") and the operational difference between x402 and prepaid, which the enum alone does not make actionable.

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 — transcribe a bounded base64 audio/video file to text — with the size constraint baked in. It also explicitly disclaims adjacent tasks (OCR, invoice parsing, PDF conversion), which separates it from siblings like document_ocr, invoice_extract and pdf_to_text without opening a schema.

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

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

Gives both the positive case ("use for spoken media") and the negative cases ("not for OCR, invoice parsing, or PDF content conversion"), which map directly to sibling tools. It goes further by prescribing the recovery path (retry with the same idempotency_key) and the follow-up sequence (job_status, job_result, SHA256 verify).

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

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

Beyond the annotations, the description discloses the full operational contract: separate Bearer auth, backend operation enablement, payment-mode tradeoffs (x402 quote vs prepaid credits), idempotent retry semantics, and the asynchronous admission/poll/retrieve/verify flow with SHA256 checking. Nothing here contradicts the annotations – readOnlyHint=false, idempotentHint=true and openWorldHint=true all align with a paid, idempotent job submission.

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 purpose and the sibling routing come first, and the operational details follow in a tight sequence. It is a bit long, and 'No anonymous execution' duplicates the payment_mode schema description, but every sentence carries real information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paid, asynchronous, authenticated job tool with no output schema, the description covers everything an agent needs: auth, payment modes, idempotent retry, admission vs delivery, polling via skavio_agent_job_status, retrieval via skavio_agent_job_result, and SHA256 verification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already documents payment_mode, idempotency_key, data_base64 and units in detail. The description largely restates the idempotency and payment semantics rather than adding syntax, size limits or defaults beyond what the schema provides, so it earns the baseline 3.

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 ('Apply optical character recognition to a scanned document supplied as base64') and states the output ('searchable extracted text'). It explicitly distinguishes itself from siblings pdf_to_text and invoice_extract by naming the conditions that select each alternative.

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 when-to-use guidance ('Use when the document lacks a usable text layer') and names two alternatives with their own selection criteria (pdf_to_text for selectable PDF text, invoice_extract for invoice fields). It also documents the authentication and payment prerequisites needed to invoke the tool at all.

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

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

With no annotations, the description carries the behavioral burden well: it discloses the bounded DNS/TLS mechanism, port 443, no HTTP request, returned fields, and the x402 v2 payment cost on Base or Solana. It does not cover failure modes, rate limits, or idempotency, but the cost/payment and safety profile are unusually well documented.

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, then scope/exclusions, then input format, then return values, then cost. Every sentence adds distinct information with no wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter audit tool with no output schema, the description covers purpose, boundaries, input type, return values, and payment requirements. Nothing an agent needs in order to select and invoke it 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 the single 'domain' parameter. The description adds only a restatement of the hostname-not-URL constraint already present in the schema; no additional syntax or formatting guidance beyond that.

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 — auditing public DNS records and TLS certificates of one hostname — plus the mechanism (bounded DNS resolution and TLS handshake to port 443). Explicitly distinguishes itself from sibling tools such as web_fetch and web_extract.

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 guidance ('basic hostname/certificate check') and clear exclusions naming the correct alternatives (web_fetch, web_extract) and out-of-scope activities (vulnerability scanning, port scanning, private IP networks). Also clarifies that the input must be a hostname, not a URL.

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

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

Annotations only carry readOnly=false, idempotent=true, openWorld=true, destructive=false. The description adds context the annotations do not: separate Bearer authentication, an enabled backend operation, accepted payment mode, x402 quote vs prepaid credit consumption, admission-is-not-delivery async semantics, SHA256 verification, and no anonymous execution.

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 sibling exclusion, then auth, payment, recovery, and retrieval semantics in a logical order. The middle section packs several clauses into long sentences, but each sentence carries operational information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description compensates by explaining that the call is asynchronous and how to obtain and verify the result. It stops short of saying which invoice fields are returned or what the quote contains, which leaves a small gap for a structured-extraction 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 arguments, units, data_base64 size limits, payment_mode enum, and idempotency_key pattern. The description reinforces the retry meaning of idempotency_key and the two payment modes but contributes no new parameter-level detail, which is the baseline-3 situation.

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 ('Extract structured invoice fields from one uploaded document') plus distinguishing scope (source page count verified, per-page cost quote). It explicitly separates itself from document_ocr and pdf_to_text, so an agent can route without opening a 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?

Names the two nearest alternatives and the condition that excludes them: invoice metadata rather than generic OCR or plain selectable text. It also gives the recovery rule (retry with the same idempotency_key and inputs, not a new job) and the required follow-up path (poll job status, retrieve result).

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

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

Adds substantial context beyond the annotations: chain-specific finality checks, an explicit 'does not send funds or create an invoice' side-effect disclaimer, and the x402 v2 cost of 0.03 USDC with the payment rail (native USDC on Base/Solana). The cost and payment mechanism are exactly the kind of behavior 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 tight sentences ordered purpose -> routing -> constraints/cost, with zero filler. The cost and non-mutation disclaimer are placed last where they belong, and no clause is redundant with another.

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, yet the description never states what a successful confirmation returns (a match verdict, extracted sender/amount, an evidence reference) or how a mismatch is reported. Everything an agent needs in order to call it correctly is present, but the result contract is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter, including the `network` enum and its default, is fully documented in the schema. The description restates the three required inputs ('Requires tx_hash, recipient and amount') and hints at the six-decimal precision, but adds little syntax or format detail beyond the schema — baseline 3.

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: 'Confirm an exact native Circle USDC recipient and six-decimal transfer amount for a completed transaction.' It scopes the chains (EVM or Solana) and explicitly names the two siblings it is not (verify_native_usdc, usdc_transfer_evidence_pdf), so an agent can route without opening any schema.

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

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

Gives an explicit when-to-use condition ('reconciling a payment with an expected wallet and amount') plus two named alternatives with the selection criteria that favor them (inspect without expected values -> verify_native_usdc; PDF output -> usdc_transfer_evidence_pdf). No inference required.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and the description is consistent with all three. It goes well beyond them by disclosing the auth model (Bearer API key, no anonymous execution), the payment semantics of x402 vs prepaid credits, the recovery rule (reuse the SAME idempotency_key and inputs rather than starting a new job), and the async admission-vs-delivery distinction with SHA256 verification. The only thing keeping it from a 5 is that failure/partial-success behavior and output location are stated only by reference to sibling tools.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and ordering guarantee, then alternatives, then auth/async mechanics. Every sentence carries information, though the payment-mode and idempotency sentences partially duplicate what the schema's own field descriptions already say, making the block slightly denser than strictly 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?

For a nested-input, async, authenticated mutation with no output schema, the definition covers everything an agent needs: the ordering contract, the alternative tools, auth and payment requirements, the retry protocol, and the exact follow-up tools (skavio_agent_job_status, skavio_agent_job_result) plus SHA256 verification for retrieving the result.

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 baseline is 3, but the description earns extra credit by adding real semantics: the inputs are ordered so concatenation order is caller-controlled, the 2-to-5 range is a hard contract rather than a convention, and retries must reuse the idempotency_key with identical inputs. It does not elaborate on the legacy 'units' field or the size limit, which the schema already covers.

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 concrete verb and resource ('Combine two to five uploaded base64-encoded PDF documents into one output document') plus a meaningful constraint ('preserving the supplied order'). It explicitly distinguishes itself from pdf_split and pdf_to_text, so an agent can route without opening any schema.

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

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

Names the exact condition for use ('Use to concatenate files') and the two alternatives with their distinct purposes ('pdf_split to select pages from one PDF', 'pdf_to_text to extract text'). It also supplies the operational precondition chain: authenticate, submit, then poll and retrieve rather than waiting for synchronous delivery.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=true, openWorld=true), and the description adds substantial non-redundant context: authentication requirements, payment modes, idempotency retry semantics ('SAME idempotency_key and inputs... not a new job'), and the admission-is-not-delivery polling/verification flow. Nothing here contradicts 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 the core action and sibling disambiguation, which is the right order. The middle section on relay authentication and x402/prepaid payment is boilerplate-heavy and could be tightened, but every clause is actionable information an agent needs before calling.

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 async, authenticated, paid job-launching tool with no output schema, the description supplies the full lifecycle: submit, poll skavio_agent_job_status, retrieve via skavio_agent_job_result, verify SHA256. The only gap is that the shape of the returned job/result payload is left entirely to siblings.

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 earns a bump by explaining the idempotency_key's recovery semantics in prose (same key + same inputs to recover rather than starting a new job), which is behavioral meaning the schema pattern alone doesn't convey. It adds nothing about `pages` or `units`, which the schema already documents well.

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 precise verb+resource+scope: 'Select one-based page numbers from an uploaded PDF and return a new document containing those pages.' It explicitly distinguishes itself from pdf_merge (concatenate whole PDFs) and pdf_to_text (read text), so an agent can route correctly without opening any schema.

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

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

Names both alternatives and the condition that selects each ('use pdf_merge to concatenate two to five whole PDFs or pdf_to_text for reading text'), which is exactly the when-to-use vs when-to-use-something-else guidance needed. It also flags prerequisites (Bearer API key, enabled backend operation, accepted payment mode) before invocation.

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

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

Goes well beyond the annotations: discloses that this is a separately authenticated relay requiring a Bearer key, an enabled backend operation and an accepted payment mode, and explains the x402 vs prepaid cost model. Crucially it states 'Admission is not delivery' and prescribes polling skavio_agent_job_status plus retrieval via skavio_agent_job_result and SHA256 verification — behavior an agent could not infer from readOnlyHint/idempotentHint alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and the sibling routing, which is exactly what an agent needs first. It is dense with auth/payment boilerplate in the middle, but every sentence carries actionable information; the slight redundancy with the schema's idempotency wording is the only waste.

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, and the description compensates fully by explaining that the result is not returned inline — you must poll job status, fetch the result, and verify SHA256. Given the async job pattern and payment/auth complexity, this is complete enough for an agent to call and consume the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents units, data_base64, payment_mode and idempotency_key, which sets a baseline of 3. The description adds operational meaning by tying idempotency_key to a recovery workflow ('Retry with the SAME idempotency_key and inputs to recover, not a new job') and by framing payment_mode as quote-vs-credits, which is more than a restatement. It adds nothing for the legacy units param, keeping it below a 5.

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 ('Extract embedded selectable text from a PDF supplied as base64') and immediately delimits scope with the 'embedded selectable text' qualifier. It names the sibling tools document_ocr and invoice_extract as the alternatives for other input types, so an agent can pick correctly without opening a schema.

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

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

Gives explicit when-to-use ('text-layer PDFs') and when-to-use-something-else ('document_ocr when pages are scanned images, invoice_extract for structured invoice fields'). It also covers operational guidance: retry with the SAME idempotency_key, no anonymous execution, and the poll/retrieve flow after admission.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world behavior, so the bar is lower. The description nonetheless adds real operational detail: the exact return shape (data_base64, sha256, delivered=true), the error path, the ownership constraint, and a checksum-verification instruction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the action and scope, and every clause carries information (cost, precondition, return shape, verification). It is dense and semicolon-heavy, but there is no filler.

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 annotations covering the safety profile and no output schema, the description fully compensates by stating the return fields, the delivered flag, the error behavior, and the checksum-verification step. Nothing needed to invoke it 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 coverage is 100%, and both param descriptions already state the manifest provenance and 'verify SHA256' guidance, so the description largely restates structured content. Baseline 3 is appropriate; no additional syntax or format meaning is contributed.

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 ('Download your owned completed processing result') plus the payload format (base64 with SHA256), which cleanly separates it from the status/manifest tool. It does not name a sibling tool explicitly, so an agent must infer the pairing with skavio_agent_job_status from the phrase 'completed owned manifest'.

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 a clear precondition: result_id must come from a completed, owned manifest, and notes 'no new payment,' which is useful routing context. It stops short of explicitly naming skavio_agent_job_status as the step that produces the manifest, leaving that inference to the agent.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety burden is covered. The description adds real value on top: it lists the returned fields (state, reservation, availability, owned result IDs) and states the download restriction, which is behavioral context the annotations do not 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?

Two dense sentences with no filler, front-loading what is read and the no-payment guarantee. It is packed tight but still readable; 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?

There is no output schema, so the description does the work of enumerating the returned state fields and the download constraint. For a single-parameter read tool with full annotations, this is nearly complete; only pagination or error/no-job-found behavior is 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?

With schema coverage at 100% and a single parameter, the schema already documents the idempotency key including its format and ownership scoping. The description only restates that the input is the original key, adding no syntax or format meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'Read your owned processing job and result manifest', and clarifies the keying by idempotency key. It implies a distinction from the result-download sibling ('only available results may be downloaded') without naming it, so it stops short of the explicit sibling differentiation a 5 requires.

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 establishes the calling context ('no new payment', 'input is your original idempotency key'), which tells an agent this is a safe polling/status check rather than job creation. However, it never explicitly says when to use this versus skavio_agent_job_result or what to do when no result is available yet.

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

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

Annotations already cover readOnly, idempotent and non-destructive, but the description adds real value: it names the returned fields (balance_credits, available_credits, reserved_credits, USD strings, ledger_source) and explicitly rules out funding/reserving/moving/spending. That negative scope is the key behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the action and scope, then the return shape, then the exclusions. No filler.

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-value burden and does so by enumerating the balance fields and ledger_source. Combined with the explicit mutation exclusions, an agent has everything needed to call it and interpret the result.

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?

Zero parameters, so there is nothing to disambiguate; baseline is 4. The description correctly avoids inventing argument semantics for a no-arg 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?

States a specific verb ("Read") and resource ("shared credit wallet") and clarifies scope with "authoritative" and "no new payment." It distinguishes itself from payment siblings implicitly via the negative clauses, but never names an alternative tool the way a 5 would.

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?

"Read your authoritative shared credit wallet; no new payment" plus "does not fund, reserve, move or spend credits" gives clear when-to-use and when-not-to-use context. It stops short of naming which sibling to use instead for funding or transferring.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds non-annotation context that matters: it is free, exposes no customer data, and critically 'No call submits a job or spends funds,' which reassures an agent about financial side effects.

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 compact sentences, front-loaded with the free-discovery scope. It is not padded, though the middle sentence ('separate processing authentication and activation limits') is slightly garbled and costs a little 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?

With no output schema, the description must convey returns, and it does: 'four paid prices in USDC, inspection networks, ... authentication and activation limits.' Combined with the no-funds/no-job guarantees and full annotation coverage, this is nearly complete for a zero-parameter discovery call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and schema coverage is 100%, so the baseline is 4. There are no arguments to describe, and the description correctly does not invent any.

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: 'Free discovery of Skavio paid MCP tools, prices, and networks.' This distinguishes it from the sibling tools (audio_transcribe, pdf_merge, etc.), which are the paid tools being catalogued, so an agent can tell it is the discovery entry point rather than a worker.

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

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

Usage is implied rather than stated: 'Free discovery' and 'No call submits a job or spends funds' hint that this should be called before committing to a paid tool, but there is no explicit 'use this when/not' or named alternative. The reader must infer the routing.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, but the description adds the important operational facts that the call is free and causes no execution or charge. It also discloses that payment journal evidence is returned separately from approved pricing and unverified profitability.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose, then states the no-charge behavior, then details the return categories. It is compact, though the return categories are expressed in dense domain jargon.

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 status tool with rich annotations but no output schema, the description supplies the key operational and return-content context. It could be clearer about what 'activation' and 'owner-funded historical payment journal evidence' concretely mean, but it is broadly complete enough to call.

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, so the baseline is 4 under the scoring rules. The description does not need to document parameter syntax, and it appropriately does not mention any input fields.

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 resource—production availability status—and clarifies it includes explicitly disabled processing functions, plus what evidence it returns. It is clear what the tool reports, though it does not explicitly distinguish itself from sibling status tools such as skavio_agent_job_status.

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 guidance on when to use this tool versus alternatives. 'Free' and 'No execution or charge' imply it is safe to call for status checks, but the description does not name a sibling tool or a condition that selects this one.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), and the description adds genuinely new context: the 0.05 USDC x402 v2 payment on Base or Solana, that the PDF is not an invoice/tax receipt/authorization, and that no custody or transfers occur. It does not disclose retry/idempotency behavior despite idempotentHint=false (a repeat call presumably re-charges), which keeps this 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?

Front-loads the purpose and the exclusions before the disclaimers and pricing, and every sentence carries real information. Slightly long with the trailing payment-settlement sentence, but dense rather than padded.

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 and does state it is a bounded base64-encoded PDF. It covers scope limits, pricing, and exclusions. The word 'bounded' is not quantified (no size/token ceiling stated), which is the main residual gap for an agent that must handle the returned payload.

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%, including the tx_hash format pattern and the network enum with its payment-vs-inspection note, so the schema already carries the parameter semantics. The description adds nothing about parameter format or defaults 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 (generate) and a specific artifact (base64-encoded PDF of native Circle USDC transaction evidence for an existing on-chain transfer). It explicitly names the two sibling tools it is not (match_native_usdc_payment, verify_native_usdc), so an agent can distinguish it without opening any schema.

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

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

Gives explicit when-to-use ('customer or accountant needs a downloadable blockchain proof') and when-not with named alternatives for each exclusion (machine-readable exact check -> match_native_usdc_payment; simple lookup -> verify_native_usdc). Nothing is left to inference.

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

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

Annotations already establish read-only/non-destructive status, but the description adds information the annotations cannot convey: a 0.02 USDC x402 v2 charge, accepted payment chains and wallet approval, and the caveat that RPC finality and availability vary. The 'does not initiate transfers' line is consistent with readOnlyHint=true.

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?

Purpose leads, then alternatives, then cost and caveats, which is the right front-loading. It is four dense sentences with almost no filler, though the pricing and wallet-approval clause is compressed enough that it may need a second read.

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 two-parameter, read-only inspection tool, most of what an agent needs is present: scope, routing, cost, and exclusions. The one gap is that no output schema exists, and 'use for transaction evidence' never says what evidence fields come back, so the agent must call it to learn the response shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the enum is fully documented, so the baseline is 3. The description earns one step above that by listing the chains and by pre-empting the confusing case where the inspected network differs from the chain the API fee settles on, which is the one place the schema note is easy to miss.

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 (inspect) and resource (a completed native Circle USDC transfer, identified by tx hash), then enumerates the supported chains. It clearly distinguishes this tool from the two sibling tools that touch the same data (match_native_usdc_payment, usdc_transfer_evidence_pdf).

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 names both alternatives and the conditions that select each: match when you need an exact recipient and six-decimal amount, and the PDF tool when you need a document. It also states the negative case ('does not initiate transfers or establish payment to a particular invoice'), which is exactly the misunderstanding an agent could have in this domain.

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

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

Goes well beyond the annotations: discloses the relay authentication model, that x402 issues a workload-specific quote while prepaid consumes shared company credits, and the retry contract ('retry with the SAME idempotency_key and inputs to recover, not a new job'). It also discloses the critical asynchronous semantic 'Admission is not delivery', telling the agent to poll status, retrieve via result, and verify SHA256 — none of which the readOnlyHint/openWorldHint/idempotentHint annotations convey.

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 then differentiation, followed by auth/payment/retry/job-flow blocks; every sentence carries operational weight with no filler. It is dense and near the upper bound of useful length for a single-page extractor, with a couple of clauses that could be tightened.

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 mutating, authenticated, asynchronous, paid tool with no output schema, the description covers everything an agent needs: access prerequisites, cost model, idempotent retry behavior, the admission-vs-completion distinction, the exact follow-up tools (skavio_agent_job_status, skavio_agent_job_result), and output verification via SHA256.

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 baseline is 3; the description adds meaning by pairing idempotency_key with retry recovery and contrasting x402 quoting against prepaid credit spend. It does not explain the nested `arguments` object or the URL constraints beyond what the schema already states, so it is above baseline but not exhaustive.

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 ('Extract human-visible text from one public HTTPS page') plus the operating envelope (robots and size limits). It then explicitly names the two sibling it is NOT — web_fetch for raw document fetching and web_monitor for SHA256 change detection — so an agent can route correctly without opening any schema.

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

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

Gives an explicit positive condition ('readable page text') and explicit exclusions mapped to named alternatives (web_fetch, web_monitor). It also states prerequisites ('requires a valid Bearer API key, an enabled backend operation and an accepted payment mode') and 'No anonymous execution', which prevents a whole class of mis-invocation.

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

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

Goes well beyond annotations: describes the authenticated relay, Bearer API key requirement, enabled-backend precondition, payment modes (x402 quote vs prepaid shared credits), and that 'admission is not delivery' with polling and SHA256 verification. This is consistent with openWorldHint=true, idempotentHint=true (retry with the SAME idempotency_key), and non-readOnly behavior (it spends credits and creates a job).

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 sibling routing, then the auth/payment and lifecycle facts. Dense and jargon-heavy ('x402', 'SSRF', 'admission is not delivery'), but nearly every sentence carries decision-relevant information; only the payment-mode sentence partly duplicates 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?

No output schema exists, and the description still covers the full lifecycle: job creation, polling via skavio_agent_job_status, retrieval via skavio_agent_job_result, and integrity verification. It stops short of describing the shape or size of the returned content, which is a minor but real gap for a fetching tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already defines url, payment_mode and idempotency_key with enum and pattern. The description adds operational meaning the schema only gestures at: that x402 yields a workload-specific quote, prepaid consumes shared credits, and recovery requires reusing the same key with identical inputs rather than starting a new job.

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 ('Retrieve content from a public HTTPS document') plus the constraint envelope (robots.txt, SSRF, byte limits). It then explicitly separates itself from web_extract (human-visible text) and web_monitor (change hashes), so an agent can route without opening schemas.

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

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

Names both alternatives and the exact condition that selects each ('choose web_extract when only human-visible text is needed', 'web_monitor for content change hashes'). It also states the admission/retrieval path and the retry rule, leaving no inference needed.

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

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

Goes well past the annotations: distinguishes admission from delivery, names the polling and retrieval siblings to use, warns to reuse the same idempotency_key rather than starting a new job, and explains how x402 (workload quote) differs from prepaid (shared credits). It also tells the caller to verify the returned SHA256, which the annotations cannot convey.

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?

Purpose and sibling routing are front-loaded, then auth/payment, then the async workflow — a sensible order with little filler. It is dense to the point of run-on in the authentication sentence, which packs three separate admission requirements into one clause.

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, authenticated, asynchronous job-creating tool with no output schema, the description covers authentication, payment modes, idempotent retry semantics, the poll-then-retrieve lifecycle, and result verification. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so url, previous_sha256, payment_mode and idempotency_key are already documented in structured fields. The description restates their intent (comparison against a prior SHA256, same key on retry) without adding format, bounds, or edge-case detail beyond the schema, 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 and resource (measure a public HTTPS page's content hash) plus an optional comparison against a caller-supplied SHA256, so the operation is unambiguous. It then explicitly contrasts itself with two named siblings, web_fetch and web_extract, so an agent can pick it without opening a schema.

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

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

Gives the positive trigger (detecting changes) and the alternatives with their selection conditions (web_fetch to retrieve the document, web_extract for visible text). It also states preconditions — valid Bearer key, enabled backend operation, accepted payment mode — and the no-anonymous-execution constraint.

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