SCRIPTMASTERLABS — Agent Verify

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds material context: no numeric score, the paid alternative, and that an empty list means absence of verified history rather than a negative finding.

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 short sentences, front-loaded with what is returned, then the paid-score distinction, then the empty-list caveat. No filler and every sentence contributes.

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

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

For a one-parameter read-only lookup with no output schema, the description supplies the return scope, the key empty-result interpretation, and the free-vs-paid boundary. No material omission remains for correct invocation.

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

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

The sole parameter is fully described in the schema, including address and DID formats, while the description adds only that records are for an agent. With 100% schema coverage, the baseline is 3 because the schema already carries the parameter semantics.

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

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

The description states the exact resource (All Proof Records for an agent) and the extra return (verified totals), and explicitly distinguishes the output from the paid Proof Check's numeric score. An agent can identify the tool's scope without opening the schema.

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

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

It routes the numeric-score use case to proof_check and signals free/read-only scope, but it does not state when to choose this over other free siblings such as proof_index or ledger_list. The primary alternative is clear, though not exhaustive.

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, idempotent, non-destructive, openWorld). The description adds context beyond them: cost-free access, escrow on Circle Arc, venue-published provenance, and the fact that posting/bidding requires using Bid-cast with EIP-191 signatures.

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 concise sentences with the key scoping and routing information front-loaded. There is little waste; even the parenthetical details earn their place by clarifying chain, provenance, and external-action requirements.

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 simple read-only search with rich annotations, the description is largely sufficient for tool selection. However, with no output schema and an undocumented optional parameter, it leaves invocation details incomplete.

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 has one optional parameter, `capability`, with 0% description coverage, and the description does not mention it at all. With low schema coverage, the description should compensate, but it provides no meaning for this parameter.

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 identifies the resource and scope: open, funded jobs on SML's Bid-cast board, with escrow on Circle Arc. It does not spell out an explicit verb like 'search' or 'list', but the combined name and description make the purpose unambiguous.

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 states the tool is free and read-only, and explicitly routes posting or bidding to Bid-cast itself, which is a useful when-not-to-use signal. It does not explicitly say 'use this when searching for open jobs', but that is strongly implied.

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, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuinely new context: the ordering ('newest first') and that results include the ledger head, plus the 'free' cost signal. However, it does not explain pagination behavior or what 'ledger head' means, leaving gaps for a listing tool.

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

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

A single tight sentence with the key facts front-loaded and no filler. It is efficient, though the terseness contributes to the under-specification captured in other dimensions.

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 simple two-parameter, zero-required listing tool with rich annotations and no output schema, the description covers cost, ordering, and a hint of return content. But with no output schema, the return value deserves more than the opaque 'ledger head', and before_seq pagination semantics remain unexplained.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. 'Newest first' implies the ordering that before_seq paginates against, but before_seq itself is never explained (cursor? sequence boundary? inclusive/exclusive?) and limit's maximum of 500 is only in the schema. Compensation is minimal.

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 largely restates the title ('Latest Proof Records') and adds ordering ('newest first') plus a vague return element ('with the ledger head'). No explicit verb like 'list' and no differentiation from siblings such as proof_index or agent_records, though the ordering detail gives it some substance beyond the name.

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?

'Free, read-only' signals that it is safe and costless to call, but there is no guidance on when to use this versus proof_index, proof_check, or proof_verify_record. The agent is left to infer the selection criteria from tool names alone.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds 'Free', a cost/licensing fact not present in annotations, but says nothing further about caching, versioning behavior, or response shape.

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 short sentences with zero waste; the core subject (methodology and version) is front-loaded and the operational caveat follows immediately. Nothing could be removed without losing 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 read-only, no-argument reference lookup with no output schema, the description covers what is being returned (methodology text plus version) and its access characteristics. It does not state the response format, but that gap is minor for a tool this simple.

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, which is the baseline-4 case. The description correctly implies a parameterless lookup by describing a single fixed document, so no parameter explanation is needed.

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 resource — the published Proof Score methodology plus its version — which is clearly distinct from the sibling tools proof_check, proof_index, and proof_verify_record. The verb is implied rather than stated ('returns'/'retrieves'), but an agent can tell this is a reference/documentation lookup rather than a data query or verification operation.

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?

'Free, read-only' hints that it can be called without side effects or cost, implying it is safe to consult at any point. However, there is no explicit statement of when to fetch the methodology (e.g., before interpreting proof scores) or how it relates to proof_index/proof_check, leaving usage 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?

Goes well beyond the annotations by disclosing the x402 v2 payment protocol (exact USDC on Base), that the first call is free, that settlement happens once per signature and replays return 409, that the report is only returned after settlement, and the meaning of 503/402/502 errors. This is exactly the behavioral context an agent needs for a paid mutation.

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?

Dense and front-loaded: report contents first, then payment flow, then settlement and error behavior. Every sentence carries operational information and 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?

For a two-parameter paid tool with no output schema, the description covers what the report contains, how to obtain and use the payment signature, settlement semantics, replay behavior, and error codes. 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: payment_signature must be the base64 PAYMENT-SIGNATURE corresponding to one of the accepts returned by the unpaid call. That flow semantics is not in the schema and materially improves correct invocation.

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: a signed proof report for an agent, enumerating its contents (Proof Score per category, record count, settled value, buyer diversity) and marking it paid. It does not explicitly differentiate itself from siblings such as proof_index or proof_verify_record, so it is clear but not sibling-differentiating.

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 call sequence: call without payment_signature to receive payment requirements with no charge, then call again with the signature from one of those accepts. It does not say when to prefer this over proof_index, proof_verify_record, or agent_records, so context is clear but alternatives are unaddressed.

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 and non-destructive behavior, so the safety profile is covered. The description adds context beyond that: the metric is verified-only, restricted to Proof Records, and carries no cost ('Free'), which is not encoded anywhere in the structured fields.

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

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

A single short sentence with the resource and breakdown dimensions front-loaded and zero filler. Every clause (verified, venue/category/day, Proof Records only, free) adds information an agent can act on.

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 parameters, no output schema and full annotation coverage, the description supplies what is needed: the metric, the segmentation dimensions and the data scope. A brief note on the aggregation granularity or response shape would close the remaining gap.

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 there is nothing for the description to disambiguate and the baseline is a 4. The description appropriately spends its words on the return dimensions instead.

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 concrete resource (aggregate agent-job volume) and its breakdown dimensions (venue, category, day), which is far more specific than the title alone. It does not, however, explicitly contrast itself with close siblings such as proof_check, proof_verify_record or agent_records, leaving the agent to infer that this is the aggregate/lookup index rather than the per-record verification path.

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

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

The 'Free, read-only' note and '(Proof Records only)' scope imply when this tool is appropriate (a cheap aggregate lookup restricted to Proof Records), but no alternative or exclusion is stated. An agent is left to guess whether volume figures should come from this tool or from ledger_list / agent_records.

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, so the safety bar is low; the description still adds real value by listing the concrete checks performed (signature against published key, hash-chain, Merkle anchor, mainnet re-read) and disclosing the 'record not found' error mode. The 'Free, read-only' phrasing largely repeats the annotations rather than extending them, keeping it out of the top band.

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 action and its scope, then compresses the five verification steps into one tight clause, closing with cost/safety and the error condition. No sentence is wasted.

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

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

With one required param and no output schema, the agent needs to know what the call inspects and how it fails, both of which are covered. It stops short of describing the verdict/result shape (pass/fail per check), which would fully close the loop.

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

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

Schema coverage is 100% and the single record_id parameter carries its own example (pr_000001), so the schema does the work. The description adds nothing about the identifier format or validity beyond the implicit 'record not found' failure case, which is the expected baseline-3 outcome.

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?

Names a specific verb (verify) and resource (proof record) and enumerates exactly what verification recomputes: hash, service signature, hash-chain link, Merkle anchor, Arc transaction. It is distinguishable from generic siblings like proof_index, but it never contrasts itself with the closely named proof_check, leaving ambiguity for that nearest sibling.

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?

'Verify a Proof Record yourself' implies independent/trustless verification as the use case, and 'Free, read-only' signals it is safe to call casually. However, there is no explicit when-not guidance and no mention of the obvious alternative, proof_check, so an agent must infer which tool to pick.

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 and destructiveHint=false, so the description earns credit for the extras it supplies: 'Live' signals a fresh, non-cached probe and 'Free' signals no cost or quota consumption. It does not say what happens on component failure or what the response looks like, which keeps it below 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?

Two short sentences with zero filler, and the scope (which components) is front-loaded ahead of the cost/safety note. Nothing repeats the title or wastes the agent's reading budget.

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 should tell the agent roughly what comes back (per-component status flags, overall health, timestamps). Instead it only names the components probed, leaving return shape and failure semantics unstated. Adequate for selecting the tool, incomplete for interpreting its 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly implies a no-argument, whole-system probe.

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?

Names a specific resource and enumerates exactly what is probed: ledger, verifier, Arc anchoring and SML components. It is clearly distinguishable from every sibling (records, search, listing, proofs, methodology), none of which report health, though 'status' alone leaves the shape of the answer implicit.

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?

Calling it 'Live' status and tying it to what 'the board probes' implies a health-check use case, but there is no explicit statement of when to call it versus other tools or whether it should be polled first before running other operations. Usage is inferable rather than stated.

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