quantum

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, what side effects might occur, or how the mesh might change from calling this tool. The phrase 'The mesh gets smarter with every interaction' is vague and could misleadingly imply that invoking the tool itself improves the mesh, offering no clarity about side effects or safety.

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 at two sentences, with the main purpose front-loaded in the first sentence. The second sentence adds a somewhat vague marketing-style claim ('gets smarter with every interaction') that does not carry concrete behavioral information, but it does not waste much space. Overall it is efficiently sized for the tool's simplicity.

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 status tool with no output schema, the description provides a reasonable list of what the user can expect to see (weights, rewards, synapse history, top oracles). However, it lacks context on how the information is presented, whether it reflects current state or historical aggregates, and any notes about freshness. The description is minimally adequate but leaves out some details that could help the agent interpret results.

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 per the rubric baseline is 4. The description correctly does not attempt to explain parameters that do not exist, and the schema already covers everything (empty object). Since there is nothing to add about parameter meanings, a score of 4 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 uses the verb 'Show' with a specific resource ('OracleNet mesh intelligence') and enumerates concrete contents: learned weights, rewards, synapse history, and top-performing oracles. This distinguishes it from the sibling quantum_* tools, which all have action-oriented names like quantum_ask or quantum_deal. No ambiguity remains about what this tool does.

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 does not provide any guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or which sibling tools might be more appropriate for certain use cases. The only implied usage is that it is for viewing mesh status, but no explicit context is 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 provided, the description must fully disclose behavioral traits. It describes the flow (understands, finds oracle, executes) but omits critical details such as whether execution may have side effects, what happens if the request cannot be understood, whether results are immediate, or any permission/error considerations. The marketing-style 'One call. Full loop.' adds no behavioral clarity.

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 short and front-loaded with the core purpose ('front door of OracleNet', 'Describe what you need'). The final phrases 'One call. Full loop.' are somewhat redundant and could be omitted without losing meaning, but overall it's appropriately sized.

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 complex orchestrator with 4 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain return values, failure modes, or how the tool interacts with other oracles, leaving the agent without enough context to set expectations.

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 each parameter is already described in the schema. The description adds no new parameter semantics beyond the concept of natural-language 'need', which is also in the schema. Baseline score of 3 is appropriate since the schema does the heavy lifting.

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 identifies the tool as the 'front door of OracleNet' that accepts natural language, routes to an appropriate oracle, executes, and returns results. This distinguishes it from sibling tools like quantum_execute or quantum_route, but the exact scope of 'need' and 'oracle' remains high-level.

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 implies this is the main entry point for any OracleNet request ('One call. Full loop.'), but it provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or when-not-to-use scenarios. Sibling tools are not mentioned as 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 of behavioral disclosure. It mentions 'propose' and 'rate' as actions but does not disclose side effects, permission requirements, reversibility, or result format. The high-level phrasing leaves significant behavioral gaps.

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 clear front-loading: 'Deal Handshake' captures the essence, followed by concrete actions. Every word earns its place; no wasted content.

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 tool has 3 parameters, no output schema, and no annotations. The description covers the core purpose but omits usage context, return values, and behavioral nuances. It is minimally adequate but not fully complete for a commerce-related 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% (each parameter has a description: did, tool, action). The description adds no extra parameter detail beyond the schema, but the enum for action is clear. Baseline of 3 is appropriate since the schema handles parameter meaning.

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 ('propose a deal, get terms, rate') on a resource ('deal') and adds context with 'Agent-to-agent commerce.' It is clear and somewhat distinguishes from siblings by using 'handshake' terminology, though it does not explicitly name alternative tools.

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 implies use for agent-to-agent deal-making but does not explicitly say when to use this tool versus siblings like quantum_offer or quantum_settle. No alternatives or exclusions are mentioned, leaving the context implied rather than explicit.

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 burden. It discloses side effects: 'logs the neural synapse, and updates routing weights,' which is useful. But it does not explain potential risks, synchronous behavior, or error handling. The description adds some context but lacks depth about consequences of execution.

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 (four sentences) and front-loads the core purpose. The metaphor 'The muscle of the mesh' adds flavor but is non-essential. Overall, it's efficient with minimal fluff, earning a 4.

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 complex executor tool with no output schema, the description provides workflow guidance and side effects but does not specify return format, error behavior, or prerequisites. The schema covers parameters, but the lack of output details leaves a gap. It's adequate but not complete.

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 has 100% description coverage for all four parameters, including examples for 'tool' and explanations for 'oracle' and 'caller_did'. The description adds no parameter-specific details, but the schema already handles this dimension, so a 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 clearly states the tool's function: 'Execute a tool on an OracleNet oracle.' It further details the process ('Routes to the right oracle, calls it, delivers the result') and explicitly distinguishes from the sibling tool quantum_intent by positioning it as the follow-up step. The verb+resource structure is 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 gives explicit workflow guidance: 'Use quantum_intent first to find the right tool, then quantum_execute to run it.' This clearly indicates when to use this tool relative to a sibling. However, it does not mention exclusions or alternatives beyond quantum_intent, so it's not a full 5.

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 full burden of behavioral disclosure. It indicates a read-only polling operation and that it returns recent signals/changes/alerts, but it does not mention event ordering, pagination behavior, or any limitations. The word 'feed' and 'poll' strongly imply a safe read, but more detail (e.g., whether it's long-polling, how duplicates are handled) would improve transparency.

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, front-loaded sentence that conveys purpose and usage in 14 words. There is no redundant or filler content; every element 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?

The description covers the basic purpose and usage, but with no output schema, it does not explain the structure of the returned event objects. It also lacks information about sorting, filtering behavior beyond event_type, or any rate limits. While the tool is simple, this missing context could require an agent to probe the API.

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 both 'limit' and 'event_type' already described in the schema. The tool description does not add any additional semantics beyond what the schema provides, 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?

The description 'OracleNet event feed — latest signals, changes, alerts' clearly identifies the tool's resource (event feed) and the kind of data it provides. The verb 'poll' in the usage line implies retrieval, making the purpose clear. It distinguishes from siblings by being the only tool with 'feed' semantics, though it does not name specific siblings.

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 phrase 'Poll this for updates if you cannot use webhooks' explicitly states when to use this tool (when webhooks are unavailable) and implies the alternative (webhooks). This provides clear usage context, though it does not list other alternative tools or precise exclusions.

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 must disclose whether the operation is read-only, its side effects, or return format. It mentions past interactions and suggestions but does not clarify the nature of the operation, leaving significant behavioral ambiguity.

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 brief and front-loaded, but the second part ('What worked, re-engagement suggestions') is vague and under-specified. It is not too long, but lacks the clarity needed to be effective.

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 two parameters, no output schema, and no annotations, the description is critically incomplete. It does not explain parameters, return values, or use cases, making it impossible for an agent to correctly invoke the 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 coverage is 0%, and the description does not mention agent_did or limit. It provides no meaning for these parameters, leaving the agent without any understanding of what values to supply or what limit controls.

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 identifies the resource as 'past OracleNet interactions' and hints at insights ('what worked, re-engagement suggestions'), but lacks an explicit verb like 'retrieve' or 'list' to specify the operation. It is somewhat distinct from siblings but does not clearly articulate the action.

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 is provided on when to use this tool versus alternatives like quantum_feed or quantum_status. The description implies its use for historical insight but does not state exclusions, prerequisites, or context.

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 full behavioral burden. It discloses that the tool is LLM-powered (Gemma 4), considers context/urgency/multi-step workflows, and returns a structured plan. It does not specify failure modes or side effects, but for an intent parser this is 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?

Three sentences, each earning its place: what it does, how it works, and what it returns. The most critical information (natural language input) is front-loaded. No wasted words.

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, but the description outlines the nature of returns (best oracle, tools, workflow steps, exact API call). The 'front door' contextualizes its role within the tool family. It could mention error cases or when the LLM is unnecessary, but the essentials are covered.

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 both parameters ('need' and 'llm') have descriptions. The tool description adds no extra parameter detail beyond what the schema already provides, 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?

The description clearly states the tool's purpose: an intent parser that accepts natural language and returns a recommendation of oracle, tools, workflow steps, and API call. 'The front door of OracleNet' distinguishes it from siblings by positioning it as the entry point.

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 'front door of OracleNet' phrase implies this should be used first when needs are unclear, and 'describe what you need in natural language' gives concrete usage context. However, it does not explicitly mention when not to use it or name alternative tools for exclusion.

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 carries the full burden of disclosing behavior. It mentions the instant outcomes (trust score, mesh visibility, tool access) but does not disclose side effects, whether state is changed persistently, authentication requirements, or potential costs. This is minimal transparency for a join/mutation operation.

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, front-loaded sentence that wastes no words. It efficiently conveys the main purpose and key expected result.

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 moderate complexity (joining a network with optional parameters) and no output schema, the description provides sufficient contextual information: what it does, what to provide, and what to expect in return. It does not explain side effects or prerequisites beyond what the schema covers, but for a join action it is reasonably complete.

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 all four parameters already have descriptions. The description highlights 'agent card URL' but adds no new semantics beyond the schema, such as clarifying the either/or requirement for mcp_endpoint and agent_card_url, which the schema already states. 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 uses the specific verb 'Join' with a clear resource 'OracleNet', and lists concrete outcomes (trust score, mesh visibility, tool access). This clearly distinguishes it from sibling tools like quantum_status or quantum_ask, which focus on querying or other actions.

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 provides clear context that this is the one-call method to join OracleNet, implying when to use it. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusions but remains contextually 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?

With no annotations, the description carries the full burden for behavioral disclosure. It implies a read-only operation via 'List', but does not mention pagination, default limits, filtering behavior, data freshness, or potential errors. The presence of a 'limit' parameter further suggests that 'all' in the description is not literal, but this discrepancy is not addressed.

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, well-structured sentence with no redundant words. It front-loads the core action and immediately lists the key output fields. Every word contributes value.

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 list tool with two parameters and no output schema, the description gives the essential content (trust scores, grades, activity) but lacks important context like pagination behavior and the distinction between 'all' and the default limit. Given the simplicity, it is minimally adequate but leaves room for clarification.

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 both parameters (limit, status), so the description does not need to explain them. The description adds no additional semantic meaning beyond the schema, matching the baseline expectation of 3 when the schema handles parameter details.

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 a specific action ('List all registered OracleNet nodes') and specifies the data returned (trust scores, grades, activity). The verb 'List' and resource 'OracleNet nodes' make the purpose unambiguous and distinguish it from sibling tools that focus on status, reputation, or trust passports.

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 like quantum_reputation, quantum_trust_passport, or quantum_status. It does not state scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the purpose 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, what data it returns, or any side effects. The behavior is entirely implicit from the word 'catalog', which is insufficient.

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 concise single sentence that efficiently conveys the general content of the tool. It is not overly verbose, but it also doesn't provide any useful detail beyond a label.

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 low complexity (one optional parameter, no output schema), the description is minimally adequate to understand the tool's domain. However, it lacks details about the filter behavior and return format, leaving some ambiguity about the tool's full scope.

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 parameter 'tool' is described in the schema as 'Optional filter', providing 100% schema coverage. The description does not add any additional context about how the filter affects results, but it also doesn't contradict 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 identifies the tool as an OracleNet Offer Card catalog with pricing, SLAs, and payment methods, giving a general idea of its resource. However, it lacks an explicit action verb and does not distinguish it from sibling tools like quantum_deal or quantum_rate, making the purpose somewhat vague.

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, no prerequisite information, and no exclusions. It only describes what the tool is, not when to invoke 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It does reveal the key actions (verifies identity and trust) and the decision output (recommends escrow or direct), but it does not state whether the check is read-only, whether any permissions are required, or what the exact return structure looks like. This is adequate but leaves room for more context.

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 two sentences long, front-loaded with the tool's purpose, and contains no filler. Every word contributes to understanding what the tool does and what it outputs.

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 two-parameter tool with no output schema, the description offers enough context to understand its role and outcome. It mentions the key decision (escrow vs. direct), which partially compensates for the missing output schema. It could be slightly more explicit about return value, but overall it is complete for most use cases.

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 provides 100% coverage of the two parameters, so the baseline is 3. The description does not explicitly explain the parameters, but the schema already describes 'agent_did' and 'target_task'. The description adds minimal meaning beyond the schema, just hinting at the 'planned interaction' context.

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 a specific verb ('Pre-flight check'), a resource ('before agent-to-agent interaction'), and a distinctive outcome ('Verifies identity, trust, recommends escrow or direct'). This distinguishes it from sibling tools like quantum_scan or quantum_trust_passport by defining its pre-interaction role and advisory nature.

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 phrase 'before agent-to-agent interaction' provides clear contextual guidance on when to use the tool. It does not explicitly mention when not to use it or name alternatives, but the pre-flight positioning is sufficiently clear to guide selection among the sibling 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, the description carries the full burden and explicitly discloses a significant behavioral side effect: 'Adjusts neural weights and reputation.' This goes beyond a simple 'rate' verb and warns the agent of state changes, though it does not mention reversibility or permissions.

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 concise sentences deliver the core action, timing, scale, and side effect with no filler. The information is front-loaded and every clause adds value.

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 rating tool with no output schema, the description covers the essential elements: what, when, and consequence. It does not describe the return value or required parameter relationships, but the schema provides the required fields. The description is adequate for a basic action.

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 has 0% description coverage, so the description must compensate. It adds the meaning of the rating scale ('1-5 stars'), but fails to explain rated_did, rater_did, or feedback beyond their names. The partial compensation justifies a middle score.

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 action ('Rate') and the target ('an agent after interaction'), with a specific scale (1-5 stars). It distinguishes itself from the quantum_* siblings by focusing on the post-interaction rating act, not on queries or deals.

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 a clear usage context ('after interaction'), implying when the tool is applicable. It does not explicitly mention when not to use it or name alternatives, but the context is sufficient for most 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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'OracleNet points you to who CAN help,' suggesting a read-only, advisory function, but it doesn't clarify side effects, return format, or whether any action is taken (e.g., sending the referral). This is a minimal level of transparency for an unannotated 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 two sentences and front-loaded with the core purpose. The second sentence ('OracleNet points you to who CAN help') adds a little flavor but is not redundant. It is appropriately concise, though slightly vague.

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 tool has no output schema, no annotations, and minimal parameter documentation. The description fails to explain what the referral looks like, how the result should be used, or any prerequisites like needing an oracle relationship. For a 2-parameter tool with zero schema coverage, this is insufficient.

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%, and the description adds no explicit parameter meaning. While 'need' is reasonably implied by the text, 'current_oracle' is unexplained, and the tool does not compensate for the lack of schema documentation. The description provides minimal added value over the raw 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 states a specific verb ('Get referral') and resource ('best oracle for your need'), clearly identifying the tool's role. It distinguishes from siblings like quantum_ask or quantum_route by focusing on referral rather than asking or routing, though it doesn't explicitly name 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?

No explicit guidance is provided on when to use this tool versus alternatives. The phrase 'for your need' implies a general use case, but there are no exclusions or comparisons to sibling tools, leaving the agent to infer appropriate usage.

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 that the query returns a score, grade, and trust level, but does not mention any behavioral aspects such as authentication requirements, data freshness, or side effects. As a query tool, it is implied non-mutating, but this is not explicit.

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, information-dense sentence. Every word contributes meaning: it states the action, the subject, and the output range. No unnecessary words or repetition.

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 query tool with only two parameters and no output schema, the description provides the core return values and overall purpose. However, it does not explain the purpose of period_days or provide any usage scenarios, which would improve completeness. Overall, it is mostly complete for a low-complexity 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 0%, and the description does not mention either parameter (agent_did, period_days) or their meaning. The description adds no value beyond the parameter names, which are not self-explanatory enough to compensate for the lack of 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?

Description clearly states the verb 'Query' and the resource 'any agent reputation', and adds specific output dimensions (score 0-100, grade A+ to F, trust level). This distinguishes it from sibling tools like quantum_status or quantum_trust_passport by focusing specifically on reputation metrics.

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 implies the tool is used for querying reputation, but provides no explicit guidance on when to use it versus alternatives. It does not mention any exclusions or prerequisites, so the usage context is only implied, not directly stated.

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 full burden. It discloses that the tool considers trust, capabilities, and availability and returns ranked candidates, which is valuable behavioral context. However, it does not mention side effects, read-only nature, or any limitations, so transparency is moderate but not comprehensive.

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 three short sentences, front-loaded with the main action, and every sentence adds value. There is no redundancy or fluff, making it highly concise and well-structured.

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 simple tool (2 params, no output schema, no annotations), the description covers the purpose, decision criteria, and return type. However, it lacks detail on the structure of the returned candidates and does not explicitly address edge cases or usage context relative to siblings. Still, it is sufficiently complete for routine routing tasks.

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 clear descriptions for both parameters (task and constraints). The description adds context that trust and cost are considered, aligning with constraints, but it does not significantly enhance parameter understanding beyond what the schema already provides. 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 uses a specific verb 'Find' and clearly identifies the resource ('the best oracle for a task'), plus lists the criteria considered (trust, capabilities, availability) and the output (ranked candidates). This distinguishes it from sibling tools like quantum_ask or quantum_deal, which likely perform different actions.

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 implies usage when you need to select an oracle for a task, but it does not explicitly state when to use this tool versus alternatives. With many sibling tools, the lack of direct exclusions or alternative names leaves the agent to infer appropriate use, which is adequate but not explicit.

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 carries full burden. It discloses the passive nature of the scan, the type of output (declared/observed evidence, coverage, assurance, and a read-only admission decision), and what it does not do. This gives an agent a clear behavioral profile without needing annotations.

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 three sentences with no wasted words. It is front-loaded with the core purpose, then describes outputs, then lists exclusions. Every sentence serves a clear informational role.

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?

Although there is no output schema, the description explains what is returned (evidence, coverage, assurance, admission decision). It also clarifies non-behaviors. For a one-parameter tool, this is quite complete, though terms like 'NOMOS' would benefit from elaboration.

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 a thorough description for the single 'domain' parameter, including examples and rejections. The tool description adds no extra parameter meaning. Since schema coverage is 100%, a 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 clearly states the tool's function with a specific verb ('passively inspects') and resource ('public machine-readable discovery surfaces for a domain'). It also lists explicit exclusions ('does not execute third-party tools, make payments, certify identity or issue compliance verdicts'), which distinguishes it from siblings like quantum_execute or quantum_deal.

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 explicitly stated. The description outlines what the tool does and what it does not do, giving context, but it does not mention specific alternatives or provide direct 'when to use vs. when not to use' guidance. The exclusions help, but fall short of explicit alternatives or a clear usage decision tree.

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 full burden. It discloses that the tool updates trust score and revenue tracking, which is a meaningful behavioral trait. However, it does not mention permissions, reversibility, or idempotency, leaving gaps for a state-changing operation.

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 two short sentences, front-loaded with the primary action. Every word adds value, and there is no redundant repetition of the tool name or schema information.

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 covers the purpose and side effects but lacks guidance on prerequisites, return values, or consequences. Given no output schema and no annotations, it is adequate for a simple recording action but not fully complete for an agent to understand all implications.

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 has 100% description coverage for all four parameters, so the description adds no additional parameter-level meaning. It does not relate parameters to the trust score or revenue effects mentioned in the tool description, so it stays at 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 clearly states the action 'Record a completed deal settlement' with a specific verb and resource, and explicitly mentions the side effects on trust score and revenue tracking. This distinguishes it from sibling tools like quantum_deal or quantum_execute, which handle deal creation and execution respectively.

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 implies the tool should be used when a deal settlement is completed, providing clear contextual guidance. However, it doesn't explicitly name alternatives or exclusions, so it falls short of a 5.

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 carries the full burden of behavioral disclosure. It only states 'Live status' and lists content, but does not mention read-only nature, authentication requirements, response format, or potential latency. For a status tool, this is insufficient.

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 that front-loads the key concept ('Live status') and enumerates content areas efficiently. No word is wasted, though 'how to join' feels slightly out of place for a status tool.

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 no annotations and no output schema, the description provides a useful high-level summary of the tool's content, but it omits details about the return structure, whether the status is a summary or deep detail, and the unusual inclusion of joining information. It covers the surface but leaves the agent guessing about output shape.

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 input schema is trivially complete. The baseline for 0 params is 4; the description makes no mention of parameters, which is appropriate since there are none.

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 this tool provides live status of the entire OracleNet and enumerates specific content areas (nodes, attestations, routes, revenue, how to join), which distinguishes it from siblings like quantum_nodes or neural_status. However, it lacks an explicit verb (e.g., 'gets' or 'returns'), making the purpose slightly 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?

The description implies usage for retrieving a network-wide status overview, but provides no explicit guidance on when to use this tool versus alternatives such as quantum_nodes or quantum_route, nor any exclusions or prerequisites.

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 behavioral burden. It discloses the push-based nature and the event types, but it omits the tool's multi-action behavior (register/unregister/list) and any side effects or prerequisites beyond the schema. The description adds some context but leaves gaps.

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, zero fluff. The first sentence states purpose, the second explains benefits and mechanics. Well-structured and front-loaded.

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 adequately explains the core subscription concept but does not cover the tool's full action set (unregister/list) or the conditional requirement for webhook_url. Given the 5 parameters and lack of annotations, the description is incomplete for full invocation guidance.

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 listing concrete event examples (servers change, new capabilities, deals, trust scores), which enriches the parameter semantics for 'events' beyond the schema's generic 'comma-separated event types or all'.

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 'Subscribe to OracleNet events via webhook', which is a specific verb+resource+method. It clearly distinguishes itself from sibling tools by emphasizing push-based notifications, making its purpose unmistakable.

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?

While no explicit alternatives are named, the phrase 'Push-based — we come to you' implies this tool is for receiving notifications rather than polling. This gives the agent a clear sense of when to use it, though it lacks explicit exclusions.

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. While it clarifies that the operation is a retrieval ('Get') and the output is a signed, portable credential, it does not disclose potential prerequisites (like authentication), side effects, error conditions, or rate limits. For a tool that issues credentials, more transparency is needed.

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 that leads with the action and key artifact. All words contribute meaningful information, 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?

The description provides a clear sense of the return value (a signed, portable W3C Verifiable Credential), and the single-parameter schema is simple. However, the lack of an output schema and absence of any note about prerequisites or error handling makes it slightly under-specified for a tool in a security-sensitive domain.

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 fully documents the single parameter, node_id, with a clear description ('Your OracleNet node ID or DID'). The tool description adds no additional param-specific meaning, but since schema coverage is 100%, a 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 uses the specific verb 'Get' with the resource 'Trust Passport (W3C Verifiable Credential)' and specifies the context 'proving your trust level in OracleNet.' This clearly distinguishes it from sibling tools like quantum_status or quantum_scan.

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 implies the tool should be used when a user needs a verifiable trust credential, but it does not explicitly state when to use it over alternatives or identify any exclusions. With many sibling tools, more explicit guidance would be beneficial.

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