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

Discloses the 404 behavior, that the oracle runs as a separate service, that this route only answers where a deployment fronts it, and the exact checks performed plus the EIP-712 attestation output. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with a POST that produces an attestation, and the description adds meaningful context beyond them.

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-loading the 'not served by the gateway' caveat is the right call, but the first three sentences restate the same point (404, separate service, only served where fronted) with redundancy. The validation and attestation content is dense and useful, but the definition is longer than it needs to be.

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 route that is largely unreachable in the primary deployment, the description covers the important context: availability, the separate-service model, what it validates, and its signed output. No output schema exists, so explaining the attestation return is appropriate. It could go one step further and name the in-deployment alternative for 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 description coverage is 100%, so all five parameters (jobId, kernelId, evidenceHash, assuranceTier, escrowAddress) are already documented with their tiers and semantics. The description adds no parameter-level detail, 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 concrete verb+resource: it verifies evidence (hash match, tier, replay, operator identity) and returns a signed EIP-712 attestation. It also distinguishes itself from the settlement path (pcc_job_complete / pcc_job_settlement), which is the key sibling. The heavy 'not served here / 404' framing muddies the primary purpose, keeping it 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?

Explicitly states when NOT to use it: agents never call it to settle a job, and it returns 404 on the PCC gateway; the alternative for settlement is named. It stops short of telling the agent what (if anything) it should call instead for verification in this deployment, e.g. pcc_oracle_status or verify_evidence_zk.

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