PriorSeal

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

Annotations cover the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds real value beyond them: it discloses credit consumption, service-state mutation, and an explicit boundary that it does not sign/submit/execute. One note of tension: annotations declare idempotentHint=false while the description urges an idempotency key, which reads as 'not idempotent unless you supply a key' rather than a direct contradiction.

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: purpose first, then the cost/state caveat, then the negative scope. Every sentence carries weight, though the idempotency-key advice is wedged mid-sentence in the cost warning rather than standing out as an instruction.

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?

An output schema exists, so return values need no explanation, and the description covers the mutation, cost, and non-execution boundaries an agent needs. The remaining gap is the placement/role of the idempotency key inside the opaque nested input object.

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 single top-level parameter has 100% schema description coverage ('The complete signed PriorSeal authorization request'), so the baseline is 3. The description adds only a hint about an idempotency key, and it does not say where that key belongs given the flat one-object input shape.

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 specific verbs and a resource ('Verify and persist a principal-signed authorization'), which cleanly distinguishes it from read-only siblings like priorseal_get_authorization and from priorseal_prepare_authorization. The closing negation ('never signs, submits, or executes a transaction') further separates it from execution-oriented siblings, though it doesn't name any sibling 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?

Usage is implied rather than stated: the agent learns this is the step that validates and durably records an already-signed authorization, and that it costs credits and mutates state. There is no explicit 'use this instead of X' routing or a stated precondition (e.g. that a prepare step must precede it).

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=false, so the safety profile is covered. The description adds the 'accepted' state qualifier, scoping the read to accepted authorizations, but does not describe error behavior, permissions, or handling of non-accepted or missing IDs.

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 a single sentence with no filler, front-loading the verb and resource. Every word earns its place.

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?

An output schema exists and annotations are rich, so the description need not explain return values or safety traits. The 'accepted' qualifier is useful context, though the description could clarify behavior for non-accepted or missing identifiers.

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% and the single required parameter authorizationId is fully documented in the schema. The description's phrase 'by its identifier' restates rather than enriches the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Read'), a specific resource ('accepted authorization'), and the lookup key ('by its identifier'). This clearly distinguishes it from mutation siblings like accept_authorization and prepare_authorization, as well as from other get_* tools for receipts, bundles, capabilities, and observation jobs.

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 guidance on when to use this tool versus alternatives such as get_receipt or accept_authorization, nor any preconditions or exclusions. Usage is only implied by the getter semantics and the 'accepted' qualifier.

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=false, so the safety profile is fully covered by structured data. The description adds only the word "live", hinting that capabilities are dynamic rather than static configuration; that is a small but real addition beyond the annotations, not enough to warrant a 4.

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 front-loaded sentence with the action first and the precondition second. No filler, no restatement of the tool name.

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

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

Zero parameters, an output schema that documents the return shape, and annotations that carry the safety profile. The description supplies the one thing structured data cannot: that this read should precede workflow construction. Nothing an agent needs to call it correctly is absent.

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; the baseline for a parameterless tool is 4. No parameter-related meaning is missing.

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 (live PriorSeal deployment capabilities), which is a distinct resource not covered by any sibling such as priorseal_get_authorization or priorseal_get_receipt. It does not explicitly contrast itself against those siblings, so it stops short of a 5.

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

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

"before constructing a workflow" gives a concrete sequencing condition for when to call this tool, which is genuinely useful context for an agent planning a multi-step flow. It does not name alternatives or state when not to use it, so it is clear context rather than full routing guidance.

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=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is fully covered structurally. The description adds the useful detail that the bundle is 'portable' and includes key-discovery metadata, but says nothing about size, format, or auth requirements for exporting.

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 front-loaded sentence with no filler; the resource and its companion metadata are stated up front. Nothing in the sentence is redundant with the name.

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

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

An output schema exists, so return values need not be described, and the parameter is fully specified. However, with nine sibling tools including several receipt-related ones, the absence of any routing guidance leaves a real gap in an otherwise simple definition.

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 single receiptId parameter is fully documented in the schema (100% coverage) as the 'PriorSeal receipt identifier'. The description adds no additional meaning about the identifier's format or provenance, 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?

States a specific verb ('Export') and two concrete resources ('portable receipt evidence bundle', 'issuer key-discovery metadata'), which tells an agent what it gets back. It does not explicitly differentiate itself from close siblings such as priorseal_get_receipt or priorseal_verify_receipt, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus the other receipt-related siblings (get_receipt, verify_receipt), nor any prerequisites or exclusions. The agent must infer the selection criteria from the name 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The phrase 'durable status' adds a hint that results are persisted across polls, but nothing is said about polling cadence, terminal states, or freshness, so added context is modest.

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, front-loaded sentence with no filler; the resource and its qualifier come first. It is minimal but every word carries meaning, though nothing beyond the core statement is offered.

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?

An output schema exists, so return values (job status) need not be described, and annotations carry the safety profile. For a one-parameter read getter this is nearly complete; only the polling/after-start usage context 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 the single jobId parameter is fully documented in the schema, so the description has no burden to explain parameters. Baseline 3 applies since the description adds no syntax or format meaning beyond the schema.

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

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

Specific verb ('Read') plus resource ('durable status of an automatic finality-observation job'), so an agent knows it fetches persisted job state. It does not explicitly differentiate itself from siblings like priorseal_observe_execution or priorseal_get_receipt, so sibling disambiguation is left to inference.

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

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

The description gives no when-to-use, prerequisites, or alternatives. Given the crowded sibling set of observation/authorization getters, an agent has to infer that this is the polling tool for a job started elsewhere.

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=false, so the safety profile is fully covered structurally. The description adds only that the receipt is 'signed' and tied to an 'execution', which hints at content authenticity but does not disclose any additional behavior (auth requirements, failure modes, or what signing guarantees).

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?

One sentence, zero waste, verb and lookup key front-loaded. Nothing extraneous and nothing structurally awkward.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. However, in a sibling set containing verify_receipt and get_evidence_bundle, the description leaves the retrieval-vs-verification routing question unanswered, which is the main thing an agent still needs.

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% with a single required receiptId that is already documented as the 'PriorSeal receipt identifier'. The description's 'by its identifier' merely restates the schema, so the baseline 3 applies.

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

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

States a specific verb ('Read') and resource ('a signed execution receipt') with the lookup key ('by its identifier'). It is clear on its own, but it does not differentiate from close siblings such as priorseal_verify_receipt or priorseal_get_evidence_bundle, which an agent must disambiguate on its own.

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?

No guidance on when to use this versus verify_receipt, get_evidence_bundle, or the other get_* siblings. The phrase 'by its identifier' implies a lookup precondition but does not state where a receiptId comes from or what makes retrieval the right action.

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 disclose the safety profile (readOnlyHint false, destructiveHint false, openWorldHint true). The description adds valuable behavioral context beyond annotations: it persists a request, issues evidence later, can consume configured Agent credits, recommends an idempotency key, and never broadcasts a transaction. It does not cover auth or rate limits beyond credits.

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 no filler. Purpose is front-loaded, and each sentence adds useful operational or safety information. Slightly more structure could separate the cost/idempotency advice, but overall it is efficient.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description fills important gaps by disclosing credit consumption, idempotency-key recommendation, and non-broadcast behavior. It could mention how to monitor observation completion via a sibling tool, but it is otherwise complete enough for the tool's complexity.

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% for the single required input parameter, so the schema already documents the parameter. The description adds only the idempotency-key advice and the already-submitted transaction context, without detailing the nested request fields. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: persist an observation request for an already-submitted EVM or Solana transaction, then issue evidence when observation completes. It also clarifies it never broadcasts a transaction, which helps differentiate it from execution tools. However, it does not explicitly name or contrast with sibling tools such as get_observation_job or get_evidence_bundle.

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

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

The description provides clear context for when to use the tool: for an already-submitted transaction, after submission, with an idempotency key. It does not state when not to use it or name alternative tools for checking observation status, but the triggering condition is clear.

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, so the first sentence is largely redundant, but 'never signs, submits, or executes a transaction' is a genuinely useful non-obvious guarantee for a tool named 'prepare' — an agent could otherwise reasonably assume prepare also broadcasts.

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, no filler, and the artifact being produced is front-loaded ahead of the safety qualifier. Nothing to cut.

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?

An output schema exists so return values need no explanation, which helps. However, the tool takes a nested object with additionalProperties:false and no documented subfields, and the description does not sketch what a valid request contains — a real gap for a single-param preparation 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% for the single top-level property, so baseline is 3. The description adds only the notion that the payload is a 'bounded authorization'; it does not illuminate the nested input object at all, leaving the agent to supply an opaque request body.

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 gives a specific verb pair (canonicalize, return) and a concrete output artifact (EIP-712 typed data or Solana message) tied to a bounded authorization. It clearly distinguishes itself from a signing tool, though it never names or contrasts the closest siblings (priorseal_accept_authorization, priorseal_prepare_controlled_execution).

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

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

It implies the scenario ('for a human-controlled principal to sign') so an agent can infer the prep-then-sign flow, but it gives no explicit when-to-use, no prerequisites, and no guidance on picking this over accept_authorization or get_authorization.

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=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is partly carried structurally. The description adds genuinely non-redundant context the annotations cannot express: a human principal must still sign, and the tool never accepts, signs, submits, or executes anything — a clear statement of the tool's safety boundary.

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

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

Two tightly written sentences with no filler. The positive capability statement is front-loaded and the negative safety boundary follows immediately, so an agent can read the essential contract in one pass.

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 an output schema present, return values need no explanation, and the description covers both capability and the critical safety boundary. The remaining gap is routing clarity against the closely named sibling priorseal_prepare_authorization, which an agent could easily confuse with this 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?

There is a single 'input' parameter with a nested object and 100% schema description coverage, so the schema already documents the parameter. The description adds no additional semantics about what the preparation request must contain, so the baseline 3 applies.

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

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

States a specific verb (prepare) and a composite resource (bounded authorization, deployment capabilities, handoff plan), so the agent knows this is a preparation step rather than execution. It does not, however, directly distinguish itself from the very similar sibling priorseal_prepare_authorization or explain how the two overlap.

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

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

Usage is only implied: the negation 'never accepts, signs, submits, or executes' steers the agent away from priorseal_accept_authorization and toward this pre-signing step, but there is no positive statement of when to call this versus priorseal_prepare_authorization or priorseal_get_capabilities, and no prerequisites given.

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/closed-world, so the description correctly focuses on adding the trust caveat that convenience verification is not authoritative for trust decisions. That is genuinely useful context beyond the annotation set, though it says nothing about rate limits or failure modes.

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, the core action front-loaded and the caveat second. Every clause earns its place with no redundancy.

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?

An output schema exists, so return values need not be explained, and the trust caveat covers the main judgment an agent needs. Missing only guidance on where a receipt to verify comes from relative to get_receipt.

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% for the single receipt parameter, so the schema already carries the semantics. The description adds no parameter-level detail (no expected receipt shape or source), making 3 the appropriate 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 specific verb+resource ("verify a PriorSeal receipt") and names the mechanism (deployment key registry), which cleanly separates it from the retrieval sibling get_receipt. It does not explicitly name that sibling, so differentiation is implied 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?

"Independent local verification remains required for trust decisions" gives a clear when-not-to-rely-on-this boundary, effectively routing authoritative trust checks elsewhere. It stops short of naming a concrete alternative tool or the exact precondition for calling it.

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