PRG Risk Oracle

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

With no annotations provided, the description must carry the full burden. It transparently discloses that neither tier pays the endpoint (live unpaid probe), describes the data returned (challenge parse, scheme, latency, pass/fail, grade, settlement history), and states the tool's own cost ($0.50 USDC). This is substantive and honest, though it could explicitly state read-only nature or any side effects, which is a minor gap.

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 dense but efficient: one sentence states the purpose, a second breaks down the two tiers with parenthetical detail, and a bracketed note covers pricing. Every clause earns its place; no filler. It is front-loaded with the core task before elaborating.

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, so the description must explain both return values and usage context. It does so thoroughly: it lists the specific outputs of each tier, clarifies that the probe is unpaid, and states the cost. For a tool with a single parameter and a fifth of the description, this is fully sufficient for an agent to call it 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?

The schema covers the single parameter 'url' at 100%, so the baseline is 3. The description adds only contextual framing ('payment-gated endpoint') rather than deeper semantic information about the parameter itself, such as format or constraints, so it does not exceed the 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?

The description opens with a specific verb ('Pre-audit') and a concrete resource ('a payment-gated endpoint'), immediately distinguishing it from siblings like get_risk_snapshot or get_alerts. It then enumerates the two tiers of output (live probe and on-chain settlement history), making its function 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 clearly states when to use the tool ('before you buy from it'), giving a concrete trigger condition. However, it does not explicitly contrast with alternatives or state when not to use it, so it falls short of the 5-level bar of explicit when/when-not/alternatives.

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?

No annotations are provided, so the description carries the full burden. It discloses a cost ($0.02 USDC on Base), which is valuable. It also mentions the optional filter. However, it does not state whether the operation is read-only, what data is returned, rate limits, or any side effects. For a tool that retrieves records, missing this information is a gap.

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 concise sentence with a cost note, front-loading the purpose. Every word contributes, though the word 'Open' is vague and the PRG phrase is potentially misleading. It is appropriately short but could be more precise.

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?

Given there are no annotations, no output schema, and only two simple parameters, the description still leaves major unknowns: what exactly is a 'risk alert', what fields are returned, how pagination works, and whether the 'asset' filter is actually applied despite the 'PRG' phrasing. The description does not fully explain the tool's behavior or output.

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 description adds no meaning to the 'asset' parameter beyond its enum values; it even introduces ambiguity by saying 'PRG risk alert records' while the asset parameter allows multiple assets. For 'since', the description restates what the schema already says ('newer than a timestamp'), adding no new semantic value. The cost mention is not parameter-related.

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 uses a specific verb ('Open') and resource ('PRG risk alert records') and mentions an optional filter, which clearly distinguishes it from sibling tools like get_regime or get_risk_snapshot. However, 'Open' is a bit ambiguous (could mean fetch, retrieve, etc.) and the term 'PRG' is not defined in context, though the asset enum includes PRG. Still, it clearly indicates the tool's purpose.

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 explicit guidance on when to use this vs. siblings. It mentions the optional timestamp filter but does not specify when to use this tool over others, nor does it state any prerequisites or consequences. Only implicit that it's for risk alerts, which is not enough.

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?

There are no annotations to lean on, so the description carries the behavioral burden. It communicates a read-like operation and usefully exposes pricing/versioning context: free pre-calibration, moving to $0.05 after calibration. It does not discuss auth, rate limits, or failure modes, but those are less critical for this simple read.

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 is front-loaded and the description is compact. The only minor issue is redundancy: '[free]' is immediately followed by a parenthetical explaining the free state and future pricing, which could be trimmed slightly.

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?

Given that there is no output schema, the description usefully tells the agent what kind of result to expect — component letter-grades and abstention status — along with pricing context. It is complete enough for a two-parameter read tool, though an example of the 'id' parameter would strengthen 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 description maps the 'scope' enum values to meaningful real-world objects — 'payment rail, facilitator, or endpoint' — which adds semantic value. However, the meaning of the 'id' parameter is left implicit: an agent must infer that it identifies the selected rail/facilitator/endpoint. With 0 percent schema coverage, this gap is noticeable.

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 action and resource: 'Machine Hazard Index reading for a payment rail, facilitator, or endpoint.' It also names concrete outputs (component letter-grades, abstention status), which distinguishes it from broader or sibling tools like get_risk_snapshot and get_alerts.

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 when to use it — when an MHI reading for a rail, facilitator, or endpoint is needed — but it provides no explicit guidance about when not to use it or which sibling tool to choose instead. This is adequate context but not a clear usage policy.

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 must carry the burden. It discloses rate limiting and free-tier constraints, adding behavioral context. However, it does not describe error behavior, response format, or any side effects (though it's a getter). The rate-limit note is useful but incomplete.

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 very concise and front-loaded with the purpose. However, it redundantly mentions 'free' and 'rate-limited' twice ('Free, rate-limited' and '[free] (free tier, rate-limited per IP)'), which is slightly repetitive. Could be streamlined with a single mention.

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?

The description gives the core info (what it returns and rate limits) but lacks usage guidance and does not define 'composite score band' or explain how the result relates to other risk tools. Given the absence of an output schema and annotations, more context could be helpful, but the tool is simple enough that this is adequate.

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 has zero parameters, so the schema is trivially 100% covered. Per the rubric, a baseline of 4 applies when there are no parameters. The description adds no parameter info, but none 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 states a clear purpose: returns the current PRG market risk regime label and composite score band. It is specific about the resource (regime label and score band) but does not explicitly differentiate from sibling tools like get_risk_snapshot, which might also be used for risk data.

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 no guidance on when to use this tool versus alternatives. It mentions 'Free, rate-limited' but does not explain when to choose this over get_risk_snapshot or get_mhi. No exclusions or alternative tool references are 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?

With no annotations, the description carries the burden and it usefully discloses the paid nature ($0.05 USDC on Base) and the return composition. It implies a read-only operation via 'get' but does not explicitly state the absence of side effects or specify output formatting.

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 dense sentence that names the output components, scope, and pricing. Every piece of information is relevant and there is 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?

For a simple one-parameter tool with no output schema, the description provides enough to invoke it correctly: what is returned, which instruments are supported, and the cost. It could optionally explain score units or scale, but that is not essential for selection and 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?

Schema coverage is 100% with the asset enum and a description already explaining the optional behavior. The tool description adds the phrase 'one instrument or the market' but does not meaningfully extend the parameter semantics 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?

The description clearly states the tool returns a PRG composite risk score plus seven named dimension-level scores, for one instrument or the market. This distinguishes it from sibling tools like get_mhi and get_regime by specifying the exact output and scope.

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 usage context: the tool applies to one instrument or market-wide, and the schema reinforces that omitting asset gives market-wide results. However, it does not explicitly compare to alternatives or state when not to use it.

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