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

With no annotations, the description transparently states read-only behavior, no side effects, and even discloses cost (~$0.003 USDC). It lacks details on rate limits or error handling, but for a simple read operation, this is sufficient.

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 highly concise: two short paragraphs plus a code example. Every sentence adds value—purpose, usage, return details, cost, and example—with clear structure and 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?

Given the tool's simplicity (single parameter, output schema exists), the description covers purpose, usage, behavior, return format, and cost. Minor missing details like synchronous behavior or timeout, but overall complete for effective agent 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%, so baseline is 3. The description adds value by providing an example of a valid question and explaining the type of answer expected (entropy-derived, unbiased pick), which goes beyond the schema's documentation.

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's purpose: 'Ask the Platon oracle for a grounded, entropy-derived read-only answer.' It specifies a specific verb-resource pair and differentiates from siblings like get_random and verify_random by focusing on oracle-mediated decisions.

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 context on when to use: 'lightweight oracle-mediated decisions (e.g. an unbiased pick among options)' and emphasizes it is read-only. While it doesn't explicitly exclude scenarios, the sibling tools (compute_vdf, get_randomness_beacon, etc.) suggest alternative use cases.

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 provided, so description carries full burden. Describes that output requires T sequential squarings (no shortcut), attests delay, returns specific fields in envelope, and mentions cost ~$0.01 USDC. Comprehensive behavioral disclosure beyond 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?

No fluff. Clear sections: purpose, usage, returns, example. Every sentence adds value. Well-structured for quick parsing.

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 2 params, 100% schema coverage, and output schema present, description fully explains all aspects: what it does, when to use, parameter semantics, return values, and cost. No gaps for an agent to select and invoke 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?

Schema coverage is 100% with good descriptions. Description adds extra context: seed binds generator g, difficulty is T with range and wall-clock implication, and notes it cannot be parallelized/GPU-accelerated. This enhances understanding beyond schema 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?

Clearly states 'Evaluate a Verifiable Delay Function (Chronos)' and distinguishes from sibling `verify_vdf`. Provides specific verb ('compute' implied by name) and resource (VDF). Context signals and sibling list confirm differentiation.

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 says 'Use when you need provable, unforgeable elapsed time/sequential work' with examples like timed reveals, fair ordering. Mentions verifying cheaply with `verify_vdf`, giving clear when-to-use and when-not-to 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?

Describes output format, cost, and uses PageRank algorithm. No annotations exist, so description carries burden; it does well but could mention computational limits or lack of side effects.

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?

Very concise with clear sections: purpose, usage, returns, cost, example. No redundant sentences.

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 output schema exists and 4 parameters, the description covers all necessary context: what it does, how to use, what it returns, and an illustrative example.

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 baseline 3. Description adds example and explains weight meaning, but doesn't surpass what schema already provides.

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 it returns trust score, rank, and percentile for one node, and distinguishes it from the sibling get_reputation_scores by noting it's for a single agent.

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 says 'use when you only care about one counterparty's standing', providing clear selection criteria versus 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?

With no annotations, the description fully carries behavioral transparency. It details the return envelope (random_hex, proof, signature), explains that the oracle signs the value for offline verification, and notes the cost (~$0.004 USDC). No missing behavioral traits.

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?

Concise and well-structured: single-sentence purpose, usage guidelines, return values in bullet format, and an example. Front-loaded with the most important information. No extraneous text.

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 the complexity of verifiable randomness and the presence of an output schema, the description is complete. It covers purpose, usage, return format, proof structure, verification method, and cost. All relevant aspects for an agent to use the tool correctly are addressed.

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%, baseline 3. The description adds semantic value: 'Use 32 for a 256-bit seed/word' and explains client_seed's role in domain separation ('two callers asking at the same tick get distinct, attributable randomness'). This goes beyond schema details, justifying a 4.

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 it draws unbiased, Ed25519-signed verifiable randomness. The verb 'draw' and resource 'unbiasable...randomness (Platon)' are specific. It distinguishes itself from siblings by emphasizing verifiability and unbiasability, though not explicitly naming alternatives.

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 lists when to use: 'for fair selection, sampling, raffles, commit-reveal, anti-MEV ordering'. Provides context for verifiable randomness. Lacks explicit when-not-to-use or direct comparisons to siblings, but the use cases are 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?

Despite no annotations, the description adequately discloses that the tool is a read operation, returns a standard envelope with specific fields, and includes cost information. However, it could mention any potential side effects or prerequisites more explicitly.

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?

Very concise: two sentences for purpose/behavior, one for return shape/cost, and an example. No wasted words, front-loaded with key purpose.

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 zero parameters and presence of output schema, the description is fairly complete. It explains shared vs. caller-specific, cost, and return shape. Minor omissions: no mention of failure modes or if any user permissions are needed, but these are likely not applicable.

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?

No parameters, so schema coverage is 100% (empty). The description adds meaning by showing an example call with no arguments, confirming zero parameters and reinforcing simplicity.

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?

Clearly states it fetches the round's public randomness beacon (Platon), a shared value for all callers. Distinguishes from sibling tool get_random (caller-specific) and explains use as common coin/seed.

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 describes when to use (as a common coin/shared seed) and contrasts with get_random, guiding the agent to the correct tool for shared vs. caller-specific randomness.

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?

Since no annotations are provided, the description fully bears the burden. It discloses the return format (normalized scores summing to 1, convergence info), cost (~$0.005), and algorithmic detail (power iteration). It does not mention destructive effects (none expected) or auth/rate limits, but the information provided is sufficient for a computation 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?

The description is well-structured and concise: opening purpose, usage guidelines, return specification, and an example. Every sentence adds value without redundancy. It is front-loaded with the core verb and resource.

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 the complexity of the tool (graph algorithm with multiple parameters and return values), the description is thorough. It covers usage, parameter constraints, return structure (even though output schema exists), cost, and includes a concrete example. No significant gaps remain.

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 input schema already provides 100% coverage with descriptions for all three parameters (nodes, edges, damping) including ranges, defaults, and semantics. The description adds an example and explains the return structure but does not significantly enhance parameter meaning beyond the schema. 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 clearly states the tool computes PageRank/EigenTrust trust scores over a supplied directed trust graph. It specifies the resource (trust scores) and action (compute), and the mention of LUMEN distinguishes it from sibling tools like get_agent_trust or verify_reputation which likely handle precomputed or verified trust.

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 explicitly provides use cases: ranking agents/entities by trust for counterparty selection, sybil-dampened weighting, and prioritization. It implies when to use (when you have qui-trusts-whom edges) but does not explicitly state when not to use or mention alternatives. However, the clear use-case guidance is strong.

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, description carries full burden. It describes the return value (JSON array of objects) and implies a read-only, nondestructive operation. It mentions price information, adding transparency. Could benefit from explicitly stating no side effects, but sufficient.

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?

Concise, no fluff. Front-loaded with purpose, then usage guideline, then return format, then example. Every sentence 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?

Given zero parameters, an output schema exists (as per context), but description already supplies return format and example. It is complete: explains what the tool does, when to use it, what it returns, and how to call it. No gaps.

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?

Zero parameters, schema coverage 100% (empty). Description does not need to add parameter info. It adds value by explaining the return format and providing an example, which is more than baseline for 0-param tools.

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 specific verb 'List' and clearly states the resource: every oracle tool with its AIMarket capabilityId and per-call price. It distinguishes from sibling tools (like ask_oracle, compute_vdf) which perform specific actions, while this tool provides a catalog.

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 says 'Call this first to discover what's available and what each call costs before invoking.' Provides clear context for when to use the tool, though it does not explicitly specify when NOT to use it. The recommendation is strong 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?

No annotations, so description fully bears burden. Discloses Ed25519 signature verification, cost (~$0.001 USDC), and return format (valid bool). Does not mention authentication or rate limits, but adequate.

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-loaded with purpose, followed by usage details, return info, and example. Every sentence adds value; example is helpful but slightly lengthy. Overall 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?

Given output schema exists (so return values defined) and parameters well-described, the description provides sufficient additional context: verification method, cost, and requirement for exact parameter copying. Complete 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 coverage is 100% with descriptions and examples; description adds context that parameters must be exact copies from get_random/get_randomness_beacon and provides a concrete example, enhancing clarity.

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 it verifies a Platon randomness draw without re-running, using specific verb and resource. It distinguishes from siblings like get_random (which produces data) and verify_vdf.

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 instructs to pass parameters exactly as returned by get_random/get_randomness_beacon, providing clear usage context. Does not explicitly mention when not to use, but contrast with re-running implies alternative.

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. It discloses the re-derivation logic, cost (~$0.002 USDC), and return fields (valid, max_abs_diff, commitment_match). It does not cover error handling or authentication, but is sufficiently transparent for a verification 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?

The description is concise with four sentences and an example, all of which add value. It is well-structured with a title line, usage instruction, return specification, cost note, and example. No redundancy or waste.

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 five parameters (three required) and an output schema, the description provides enough context to understand the tool's functionality and usage. It mentions cost and a return envelope. However, missing details on error conditions or prerequisites slightly reduce completeness.

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 descriptions for all five parameters. The description adds value by explaining usage context (pass from get_reputation_scores) and providing an example, which goes beyond the schema alone. It also clarifies the role of optional parameters.

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 verifies LUMEN reputation scores by re-deriving PageRank, with the parenthetical 'LUMEN verify' distinguishing it from get_reputation_scores. The verb 'verify' and resource 'reputation scores' are specific and 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?

The description explicitly instructs to pass the graph and scores (and optionally graph_commitment) from get_reputation_scores results, and confirms they are the correct PageRank. It provides an example and implies usage after get_reputation_scores, but lacks explicit when-not or alternative tools.

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 provided, the description discloses key behavioral traits: it performs efficient verification without redoing squarings and costs ~$0.001 USDC. It does not mention side effects, but the operation is read-only and non-destructive.

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 concise (under 100 words) and well-structured: starts with purpose, then parameter usage, then return value, then cost, then example. Every sentence serves a purpose with no waste.

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 the tool's complexity and the presence of an output schema, the description fully covers purpose, parameters, return format, cost, and provides an example. It is complete for an AI agent to use 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?

Schema coverage is 100%, and the description adds significant context: it explains that parameters come from 'compute_vdf', provides an example call, and clarifies the proof object structure. This adds 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?

The description clearly states 'Verify a Chronos VDF proof in a single exponentiation' and explains the mathematical verification (y = g^(2^T) mod N). It distinguishes itself from the sibling 'compute_vdf' by focusing on verification rather than computation.

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 explicitly states to pass the parameters returned by 'compute_vdf' or any party claiming a VDF result. It gives clear context for when to use the tool, though does not explicitly 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.