SCRIPTMASTERLABS — Verdict Protocol

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

Annotations carry the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), but the description adds genuinely non-redundant behavior: statelessness, no persistence, and that the timestamp changes on every compilation — which explains and reinforces idempotentHint=false. It also discloses the SHA256 hashing mechanism. It does not state what the returned capsule looks like beyond 'timestamped SHA256', which is minor.

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 core action and followed by the exclusion list. 'using the production compiler' is the only phrase of questionable weight, but it does distinguish the real compiler from a test one.

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 does at least characterize the return as a timestamped SHA256 capsule. But for a tool whose entire input is a six-field structured object with zero schema documentation, the description leaves the semantics of the research state — and of the numeric support/contradiction fields — entirely 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?

One nested object parameter with six required subfields and 0% schema description coverage — no property has any description in the schema. The description only frames it as 'caller-supplied research state' and never explains what regime, support, contradiction, or execution mean or what units the numeric fields take, so the agent cannot construct a valid capsule from the description alone.

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 pair: freeze caller-supplied research state into a timestamped SHA256 capsule. The word 'capsule' plus 'compile' separates it from verdict_decide and verdict_review_jury, though no sibling is named explicitly.

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

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

The negative scoping list ('no persistence, Jev call, signature, paid receipt, trade approval or settlement') implicitly tells the agent this is not the signing/settlement path, which is useful routing context. However it never names the alternative tool to use for those operations (presumably verdict_contract or verdict_decide), so the agent 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 readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds value beyond them by disclosing the security boundary that it cannot authorize payments or forward keys and does not touch the /decide or /seal endpoints. It stops short of describing what the contract read returns or how large/fresh it is.

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

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

Two sentences, both front-loaded: the positive capability first, the safety boundary second. Every clause carries information an agent would otherwise have to guess.

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 discovery tool with no output schema, the description says enough to call it correctly and to know what it will not do. A brief indication of what the 'contract' response looks like (endpoint list, pricing terms) would make it fully self-contained.

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 (additionalProperties: false), so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter 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?

Specific verb and resource: 'Read the live Verdict Protocol OpenAPI contract'. The second clause carves out a distinct negative scope ('never calls /decide or /seal'), which cleanly separates it from sibling verdict_decide without requiring the agent to open either 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?

Explicit when-not guidance is present ('never calls /decide or /seal and cannot authorize payments or forward keys'), so the agent knows this is a discovery/inspection tool rather than an action tool. It does not, however, name a positive condition or an alternative sibling for the cases it excludes, leaving some 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?

Goes well beyond annotations by disclosing the payment protocol: an unpaid call returns a fresh x402 challenge, the caller must supply X-JEV-API-KEY and a caller-created PAYMENT-SIGNATURE header or payment_signature argument, and model_spend_authorized=true is required before paid execution. It also plainly bounds side effects ('Never creates a wallet signature or submits trades'), which is valuable given openWorldHint=true and idempotentHint=false.

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?

Four dense sentences that front-load the core action and then layer auth, payment, and side-effect limits. Domain jargon (x402, BYOK, Jev jurors) is heavy but each clause contributes operative information; nothing is redundant.

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-object, auth-gated, paid mutation with no output schema and no annotation detail, the description covers the payment lifecycle and side-effect boundary well. The remaining gap is the capsule payload's required structure, which an agent must infer from the schema or the compile sibling.

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 0% schema description coverage the description must carry the parameter burden, and it does explain payment_signature (alternative to the PAYMENT-SIGNATURE header), model_spend_authorized (must be true), and the auth header. However, the required capsule object and its six sub-fields (regime, thesis, support, contradiction, execution, metadata) are left completely unexplained beyond the word 'frozen'.

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: invoke the /decide service to run five Jev jurors over a frozen capsule, producing a persisted signed receipt. The 'frozen capsule' framing and receipt output cleanly separate it from verdict_compile_capsule and verdict_review_jury, though the sibling distinction is only 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?

Usage context is implied rather than stated: the capsule must already exist ('existing /decide service', 'frozen capsule') and payment must be arranged. There is no explicit when-to-use/when-not-to-use guidance naming an alternative sibling such as verdict_compile_capsule or verdict_status.

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 safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: the report is untrusted input and aggregation does not authenticate issuance, correctness, independence, trade approval or payment. That trust caveat is exactly the kind of context structured fields cannot express. It stops short of describing what the recomputed report contains.

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 with the core action front-loaded and the caveats following. No filler, though the third sentence is dense enough that it could be split for readability.

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

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

Safety behavior is well covered via annotations, and the trust disclaimer is valuable, but with no output schema and a deeply nested input the description should say what the recomputed aggregation report looks like and what the capsule supplies. The total silence on `capsule` is the main completeness 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?

Schema description coverage is 0%, so the description must carry the parameter burden. It does add real information about votes ('five uniquely identified'), conveying the count and juror-uniqueness constraint the schema cannot express, but the required `capsule` object (nine required fields) is never mentioned at all, leaving half the input undocumented.

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 specific verbs (validate, recompute) and resources (juror votes, jury aggregation), and clarifies that no new evaluation happens, which implicitly separates it from verdict_decide. It does not name a sibling explicitly, so the differentiation is inferential rather than stated.

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

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

The negative guidance ('No new Jev evaluation occurs') implies this is for replaying/validating supplied votes rather than producing fresh verdicts, but there is no explicit when-to-use or when-not-to-use versus verdict_decide or verdict_verify_capsule. The agent 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that: it scopes the read to readiness/identity only, explicitly disclaims side effects ('No model, wallet or trade call'), and warns that a config-ready result is not evidence of a fresh evaluation or settlement — a substantive caveat about how to trust the output.

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 the read action, followed by two caveats that each carry information. Slight deduction because 'decision-only service identity' is compressed to the point of ambiguity and reads as jargon rather than precision.

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

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

With no parameters and rich annotations, most of the burden is already handled, and the negative-capability and trust caveats help. But there is no output schema and the description never indicates what the readiness/identity response contains, which is the main thing an agent lacks when deciding what to do after calling it.

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 the call is argument-free.

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 verb 'Read' is present and the object is 'current readiness and decision-only service identity', which places it as a status/inspection tool rather than a decision or evaluation tool among the verdict_* siblings. However, 'decision-only service identity' is opaque jargon and 'readiness' of what is never defined, so an agent still has to guess what the tool actually surfaces.

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 when-to-use statement and none of the sibling tools (verdict_decide, verdict_compile_capsule, verdict_verify_capsule) are named as alternatives. The line 'Configuration readiness is not proof of a fresh Jev evaluation or settlement' is an interpretation caveat, not routing guidance, so it only weakly implies when this tool is appropriate.

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/non-destructive/closed-world, so the bar is lower, and the description still adds real value: it bounds what a match actually proves and rules out external calls. What's missing is the mismatch behavior (error vs. a boolean result) and the hashing basis, which matter for a verification tool with no output schema.

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: action first, then the guarantee boundary, then the cost/side-effect note. Every sentence earns its place and nothing is repeated from 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 hash check with a nested capsule object and no output schema, an agent still can't predict the return shape on success or failure, nor how the hash is computed. The scope caveats are excellent, but the operational contract is 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?

One nested parameter, schema description coverage 0%, so the description carries the burden. It only characterizes the capsule as 'frozen' and hash-bearing; it does not tell the agent which fields are hashed, whether metadata participates, or which canonicalization is assumed — exactly the details that determine whether a supplied capsule should pass. The schema's types, enums and const hash pattern do structural work, keeping this at baseline.

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: 'Recompute the hash of a supplied frozen capsule.' An agent immediately knows this is a verification/checksum operation. It doesn't explicitly name verdict_compile_capsule as the counterpart, so sibling differentiation is only implicit through the word 'frozen'.

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 scope disclaimer ('proves internal integrity only, not source truth, SML issuance, receipt authenticity, Jev execution or payment') implies this is a narrow integrity check to run before trusting downstream claims, but it never says when to call it versus verdict_compile_capsule or verdict_status. 'No model or wallet call' hints it is a cheap, safe pre-check, but the trigger condition 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.