SqueezeOS — Institutional AI Market Intelligence

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

No annotations exist, so the description carries full burden. It discloses the cost for full report (0.25 RLUSD) and requirement for payment JWT. However, it lacks details on error conditions, rate limits, or what happens if payment fails.

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 efficient with five sentences, but includes a trademark and marketing phrasing. It front-loads the core purpose and key differentiators.

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, but the description explains the general return types (aggregate statistics, heatmap, wallet analytics). The payment process is partially covered in parameter descriptions, not in main description.

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 detailed parameter descriptions (e.g., specifying the meaning of each enum value). The main description adds little beyond the schema, so baseline score 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 it 'Returns aggregate statistics on which AI systems... are calling SqueezeOS APIs, conversion rates, and traffic patterns', with a specific verb and resource. It distinguishes itself from siblings by focusing on AI agent commerce landscape.

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 this tool ('before building on or citing SqueezeOS') and differentiates between free summary and paid report. It does not explicitly compare to sibling tools, but the domain specificity is clear.

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

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

With no annotations, the description fully carries the burden. It reveals polling interval, confidence threshold, sizing via Kelly Criterion, routing to Tradier, and shadow mode. Also describes return structure.

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 front-loaded with the main action. Every sentence adds unique value: requirements, mechanism, conditions, return. 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?

Given the complexity of the tool (autopilot activation with multiple configurable behaviors), the description covers all key aspects: activation, prerequisites, behavior details, live vs. shadow mode, and return format. No output schema needed as return is described.

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% coverage with description for operator_key. The description adds value by explaining the key can be passed via parameter or header, and tying it to the X-Operator-Key requirement.

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 'Activate the Sovereign Autopilot' and provides a specific verb+resource. It distinguishes from sibling tools like autopilot_status, autopilot_stop, and autopilot_trades by focusing on activation.

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 mentions prerequisites (X-Operator-Key header, env vars) and operational conditions (live vs shadow mode). It implicitly tells when to use but does not explicitly contrast with alternatives or state when not to use.

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?

Discloses read-only nature, no authentication, and safe calling behavior, along with full list of returned fields. With no annotations, description carries full burden and meets it completely.

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 single sentence with comprehensive details, followed by two short clarifying sentences. 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?

Despite no output schema, description enumerates all return fields. Zero parameters and straightforward behavior make this fully 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?

No parameters exist (100% schema coverage), so description need not add param info. Baseline 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?

Clearly states it returns the read-only status of Sovereign Autopilot, listing specific fields. Differentiates from sibling tools like autopilot_start, autopilot_stop, autopilot_trades.

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 notes no auth required and safe for any agent at any frequency, indicating universal applicability. No need for when-not or alternatives given its simplicity.

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. Discloses immediate halt, no position closure, required X-Operator-Key header, and return format. Minor gap: no mention of what happens to ongoing operations during halt.

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, no fluff. Action is front-loaded. Every sentence adds necessary 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?

For a simple stop command, covers effect, limitations, authentication, return format, and refers to sibling tool for further action. No gaps given no output schema.

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?

Only one parameter (operator_key) with 0% schema description coverage. Description adds value by stating 'Requires X-Operator-Key header', implying the parameter's purpose. Could be more explicit about it being the authentication key.

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 action ('Halt...immediately') and resource ('Sovereign Autopilot'). Explicitly distinguishes from sibling tool autopilot_trades by stating it does not close positions.

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?

Provides explicit when-to-use context (halt autopilot) and when-not-to-use (closing positions) with direct reference to autopilot_trades for manual management.

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 no authentication is required and details the exact return fields, including active vs historical trades, P&L, and mode. This is fairly transparent, though rate limits or update frequency are 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?

Two sentences with clear listing of return fields. Every word adds value; no redundancy or fluff. Front-loaded with the key action.

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 tool with no parameters and no output schema, the description covers the essential return structure and access requirements. It could be more exhaustive (e.g., clarifying 'live' update behavior), but it is sufficient for a simple read-only data retrieval 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?

The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter details, but per guidelines, baseline for 0 parameters is 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 provides a 'live view of all active and historical autopilot trades' with specific fields. Though it doesn't explicitly differentiate from sibling tools like autopilot_status, the verb 'view' and data fields indicate its read-only nature, making purpose clear.

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 tool is for viewing trades, but it does not provide explicit guidance on when to use it versus alternatives like autopilot_status or autopilot_stop. No exclusions or prerequisites are mentioned.

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?

Without annotations, the description fully discloses key behaviors: returns only certain signal levels, includes options sniper output, auto-fires Discord alerts, and states it is free. Could mention rate limits or data freshness, but overall transparent about core actions and 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?

Four sentences, all front-loaded with the main action. Each sentence adds unique value: scope, return criteria, additional output, and usage directive. No filler 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 tool with zero parameters, no output schema, and no annotations, the description provides complete context: what it scans, what it returns, side effects (Discord alerts), and cost. Covers all necessary aspects for an agent to decide and invoke.

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 exist, so no additional parameter meaning is needed. Baseline 4 applies as the description covers all aspects of input (none) appropriately.

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 scans the Beastmode universe for specific symbols (GME AMC etc.) using multi-engine convergence, returns only HIGH_CONVERGENCE or BEASTMODE signals, includes options sniper output, and auto-fires Discord alerts. Distinguishes from siblings like market_scan by specifying the unique symbol set and signal levels.

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 recommends using it as the autonomous agent's primary market surveillance call, providing clear usage context. While it does not list alternatives or when to avoid, the specificity implies it is for the listed symbols and high-signal detection, which suffices.

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 must explain behavioral traits. It notes the tool is 'free' and includes grade/loyalty tier, but omits details like rate limits, data freshness, error handling for invalid wallets, or whether the action is read-only.

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 with no wasted words. The core purpose is stated first, followed by additional detail (grade/loyalty tier, free). Ideal conciseness.

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 mentions score, grade, and loyalty tier but does not specify the output structure or how to interpret the score beyond the range. Given no output schema, more details on return values would improve 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?

Only one parameter (wallet) with 100% schema description coverage. The description adds 'for any XRPL wallet', which reinforces the schema but does not add new semantic meaning beyond what the 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 the tool returns a 'FICO-style 300-850 Agent Credit Bureau score' for any XRPL wallet, with grade and loyalty tier. The verb 'includes' and the specific range and wallet type make it distinct from 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 description implies usage for any XRPL wallet but does not provide when to use this tool vs alternatives (e.g., other financial scoring tools). No explicit exclusions or contextual guidance 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?

No annotations are provided, so the description carries the full burden. It states 'Free — this is the doorbell,' implying no cost and introductory nature, but does not explicitly confirm read-only behavior, idempotency, or potential side effects. The behavioral disclosure is adequate for a simple info endpoint but could be more 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 efficiently written with multiple sentences, each adding value. It front-loads the purpose and then details contents and usage guidance. No redundant or extraneous 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?

Given the tool has no output schema, the description sufficiently covers what it returns (system description, how-it-works, verdict definitions, pricing, endpoint URLs, tool list). It also adds context about being for AI agents and being free. This is complete for an introductory discovery endpoint.

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, and schema coverage is 100%. Therefore, the description does not need to add parameter semantics. The baseline for zero parameters is 4, which is met.

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 this as a discovery endpoint for the CCS system, listing specific contents (system description, how-it-works, verdict definitions, pricing, all endpoint URLs, MCP tool list). It distinguishes itself from ccs_validate by stating 'Use this first... before calling ccs_validate'.

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 usage guidance: 'Use this first to understand the CCS system before calling ccs_validate.' This gives a clear when-to-use context. It lacks explicit when-not-to-use or alternatives, but the guidance is sufficiently clear for an introductory tool.

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?

Without annotations, description discloses key behaviors: it returns ranked list, requires minimum 3 validations for inclusion, and is free. Does not cover auth or rate limits but adequate for a read-only list.

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, front-loaded with the core function, then details and constraints. Every sentence adds value with zero 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?

Covers what is shown, ranking, and eligibility criteria. Missing update frequency or scope (e.g., all wallets or only certain networks), but sufficient for a leaderboard.

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 exist; schema coverage is 100%, and description adds no param semantics needed. Baseline for 0 parameters is 4, but clear description justifies a 5.

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 it lists top 25 wallets ranked by CCS score, showing validation history, pass rate, and reputation tier. It specifies the ranking criterion and distinguishes from sibling tools like ccs_score or ccs_stats.

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 tool versus alternatives like ccs_info or ccs_validate. Usage is implied by the name and description but not directly addressed.

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 full responsibility. It discloses the penalty (3 points) and the reporter score requirement, but omits details about the reporting process (e.g., whether reports are immediate, if there is a review, or if penalties are reversible). Some behavioral gaps remain.

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 short sentences, each adding distinct information (purpose, effect, prerequisite, cost). No superfluous words, and key information is 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?

Given the lack of annotations and output schema, the description covers purpose, effect, prerequisite, cost, and parameter relationships. It is missing details about the outcome after submission (e.g., no return value info), but for a simple report tool, it is largely 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 baseline is 3. The description adds value beyond schema by explaining that content_hash comes from validate response, clarifying target_wallet is optional if content_hash provided, and specifying reason max length (500 chars). This moderately enhances understanding.

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: flagging a sender wallet or content hash as misinformation. It specifies the effect (penalty of 3 CCS points per confirmed report), distinguishing it from sibling tools that deal with other CCS operations like scoring, validation, or leaderboard.

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 prerequisite (reporter must have CCS score >= 20) and notes the tool is free. It gives context for when to use the tool (to report misinformation) but does not explicitly exclude scenarios or mention alternatives among 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?

No annotations are provided, so the description carries full responsibility. It states the tool is free and lists outputs but does not disclose behavioral traits such as rate limits, authentication needs, or side effects (though likely read-only).

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 all sentences contributing value. It front-loads the main purpose and enumerates outputs clearly. No redundant or missing 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?

For a simple tool with one parameter and no output schema, the description adequately covers the return fields (score, tier, history). However, it could elaborate on the meaning of reputation tiers or the trust grade scale for better 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?

The input schema has 100% description coverage for the single parameter 'wallet'. The description adds minimal extra meaning beyond the schema's 'XRPL classic address (rXXX)', restating it as 'any XRPL wallet'. No deeper semantics are provided.

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's purpose: 'Get the Cognitive Credit Score for any XRPL wallet.' It specifies the composite trust grade and output fields, which distinguishes it from sibling tools like bureau_public_score or ccs_leaderboard.

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 for retrieving a credit score but does not provide explicit guidance on when to use it versus alternatives or any exclusions. The word 'Free' hints at no cost but lacks 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?

No annotations are provided, so the description must convey behavioral traits. It does not mention whether the tool is read-only, requires authentication, has rate limits, or produces side effects. The mention of 'Free' and 'GEO/SEO discovery signal' gives some context but insufficient for safe invocation.

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 (two sentences) and front-loaded with the core purpose and key metrics. It avoids unnecessary details but could be slightly more structured (e.g., bullet points) without harming conciseness.

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 parameters, no output schema, and no annotations, the description covers the tool's purpose and typical outputs fairly well. However, it lacks clarity on the return format (e.g., JSON object) and any prerequisites, leaving room for ambiguity.

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 zero parameters, so the description adds value by explaining what the tool outputs—a list of network-wide statistics. This goes beyond the schema, which is empty, and helps the agent understand the return data.

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 provides 'Network-wide Cognitive Credit Swarms statistics' and lists specific metrics like total validations, block rate, etc. It distinguishes itself from sibling tools by focusing on aggregate network stats rather than individual reports or validations.

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 it is for obtaining a free discovery signal, suggesting use for indexing or initial exploration. However, it lacks explicit guidance on when to use this tool versus alternatives like ccs_leaderboard or ccs_report, and no exclusions are provided.

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 fully discloses behavioral traits: it returns a trust score, verdict, and flag breakdown; tracks sender wallet reputation; accumulates negative history for blocked senders; and enforces rate limits (free tier 3 calls/hour/IP, paid via payment token). It also explains the cost and payment process. No destructive behavior is hinted, and all relevant behavioral aspects are covered.

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 moderately concise; it front-loads the primary purpose and output, then details reputation tracking and pricing. Every sentence provides useful information, but the pricing section is slightly verbose. Overall, it is well-structured and efficiently communicates necessary details without significant 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 complexity (4 parameters, no output schema), the description is complete. It explains the output format (trust score, verdict, flag breakdown) without needing an output schema. It covers rate limits, payment requirements, and optional reputation tracking. An agent has all information needed to decide when and how to use 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 description coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of the optional 'sender_wallet' parameter (enables reputation tracking) and indicates that 'payment_token' is a JWT from the 'verify_payment' tool. It does not elaborate on format or examples beyond the schema, but the additional context aids understanding.

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: submit text and receive a trust score, verdict, and flag breakdown. It explicitly names the action ('validate'), the resource ('content'), and the output (trust score, verdict, flags). It distinguishes itself from siblings by focusing on content validation and trust assessment, with clear use case for information filtering.

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 explicit guidance on when to use the tool: 'Used by agents to filter their information environment and enforce a Micro-Attention Tax.' It also mentions free and paid tiers with rate limits. However, it does not explicitly state when not to use it or name alternative tools among the siblings, which would strengthen the 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?

Without annotations, the description discloses authentication requirement ('Requires X-Operator-Key') and return format ('{status, daily_pnl, breaker_state}'). It does not mention side effects or idempotency, but provides sufficient behavioral context for a simple reset 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 three sentences, each serving a purpose: purpose, context, and usage/return info. No redundant or extraneous words. 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?

For a simple tool with one parameter and no output schema, the description covers purpose, usage guidance, auth requirement, and return fields. It does not mention error conditions or what happens if called unnecessarily, but overall it is sufficiently 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 0%, but the description implies the sole parameter 'operator_key' by stating 'Requires X-Operator-Key'. This adds meaning (authentication key) but lacks details on format or constraints. Baseline is 3 due to schema coverage gap, and the description partially compensates.

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 ('Reset') and the resource ('autopilot circuit breaker') with specific context ('after a daily loss halt'). It distinguishes itself from sibling tools like autopilot_start, autopilot_stop, etc., which have different purposes.

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 explains when to call the tool ('after a daily loss halt') and provides guidance ('after reviewing trades and confirming resumption is safe'). However, it does not explicitly state when not to use it or mention 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, the description carries full burden. It discloses that the tool is free, probe is asynchronous with results within 60s, and it returns recent mentions and context. No mention of auth or rate limits, but appropriate for a read-like 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, front-loads the core value (AgentRank, scores), then provides details. Every sentence adds value with no redundancy.

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

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

Despite no output schema, the description covers return values (scores 0-100, brand mentions, context) and all actions. Given 3 parameters (all optional) and clear enum values, the description is fully 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% (baseline 3). The description adds meaning by explaining each action value beyond the schema, e.g., 'scores=leaderboard (default)', 'probe=trigger scan (async, results within 60s)', and defaults for limit.

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 citation authority scores for ScriptMasterLabs APIs, scored 0-100, and includes brand mentions. This distinguishes it from siblings as no other sibling tool mentions citations or authority scores.

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 suggests using the tool 'to gauge AI discoverability momentum' and explains the four actions (scores, history, probe, status) with brief descriptions. It does not explicitly state when not to use or mention alternatives, but the context is clear.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions auto-firing Discord alerts, which is a side effect, but does not disclose authentication requirements, rate limits, or whether the tool modifies any data. The side effect is partially disclosed but overall transparency is insufficient for a tool with no 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 a single paragraph that front-loads the main purpose but then dives into technical details like engine names and signal levels. It could be more concise without losing essential 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?

Given no output schema, the description should explain what the tool returns. It mentions signal levels but does not specify the return format or structure. The description is incomplete for an agent to fully understand the 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 input schema covers both parameters (100% coverage). The description adds value by explaining the sniper defaults to true and only fires on HIGH_CONVERGENCE+, and provides context for the symbol parameter by recommending high-manipulation assets. This goes 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 runs a proprietary engine cascade to evaluate a convergence gate, listing five distinct market dimensions and signal levels. It distinguishes itself from siblings like beastmode_scan and market_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 provides some guidance, recommending use on 'high-manipulation assets' and listing example symbols. However, it does not explicitly state when to use this tool vs. alternatives or 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.

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

Discloses pricing ($0.10/call), caching (60-second per-symbol), typical response times (<2s cached, ~4s fresh), required parameters (payment_token and agent_wallet), coverage (US equities), and internal details (8 engines, verdict components). No contradictions with annotations (none provided).

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?

Information-dense but well-organized; front-loaded with core purpose, then details. Could be slightly shorter but 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?

Comprehensive: covers purpose, internal engines, pricing, caching, required parameters, coverage, response times, and describes the output (directive, confidence, regime, price targets, per-engine breakdown) despite lacking an output schema.

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 each parameter. Description adds value by listing example tickers for symbol and explaining payment_token as a JWT from verify_payment with 1h TTL.

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 it provides a BUY/SELL/HOLD directive for US equities, distinguishes from sibling demo_council (IWM-only, cached, free), and specifies it as 'production-grade upgrade'.

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 when you need a high-conviction directional read before sizing or executing a position', and implies alternatives via mentioning demo_council and roadmap for crypto.

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 behavioral burden. Mentions 5-minute cache and same JSON shape/engines. Does not mention authentication or limits, but sufficient for a read-only preview.

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?

Four sentences, each adding value: identity, shape/cache, purpose. No wasted words, 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?

Completely describes the tool: free preview, scope, cache, purpose, relation to sibling. No output schema but 'same JSON shape' suffices.

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 exist; baseline 4 per guidelines. Description adds no param info 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?

Clearly states it is a free preview of council_verdict scoped to IWM, with same JSON shape and engines. Distinguishes from sibling council_verdict by scope and cost.

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 this to validate output quality and integration before paying 0.10 RLUSD per call on council_verdict for any symbol.' Provides clear when-to-use and implies when not to (other symbols, real-time needs).

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, description clearly implies a safe, read-only operation by using 'browse'. It also mentions 'Free' to indicate no cost. It does not disclose potential side effects, but none are expected for a browse tool. Could be improved by explicitly stating read-only nature.

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, front-loaded with purpose. Every word adds value: 'Browse open Signal Futures positions' identifies action and resource, filters list, output fields stated, and 'Free' adds cost info.

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 output schema, description covers key output fields (stake, pot size, etc.) and lists available filters. It does not mention pagination, sorting, or default behavior, but for a simple browse tool, it provides sufficient context for an agent to use 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?

Schema coverage is only 25% (only 'limit' described). The description adds no details about parameter formats, allowed values, or semantics beyond listing them as filters. For example, 'symbol' is not explained as a ticker or asset identifier. Most parameter meaning relies on schema enums, which are minimal.

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 'Browse open Signal Futures positions' with specific verb (browse) and resource (Signal Futures positions). It distinguishes from siblings like futures_create and futures_take by implying a read-only exploration operation.

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 tool vs alternatives. While it lists filters, it does not indicate prerequisites, preferred use cases, or circumstances where other tools (e.g., futures_leaderboard) would be more appropriate.

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 fully carries the transparency burden. It discloses key behaviors: auto-settles on real verdict, winner takes 95% of pot, zero custody (SqueezeOS tracks proof, wallets settle direct), and free to create. No contradictions.

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, well-structured paragraph that front-loads the core action ('Open a Signal Futures position') and efficiently conveys the logic, settlement, and constraints without 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?

Given the tool has 7 parameters, no output schema, and no annotations, the description provides a solid overview of the flow (prediction, staking, auto-settlement, payout). It omits details about return values or error conditions, but still offers sufficient context for an agent to use the tool 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 description coverage is 71%, leaving some parameters (e.g., session, ttl_hours) covered only by schema. The description adds context for the overall purpose but does not elaborate on individual parameters beyond their schema descriptions. It meets the baseline but does not significantly compensate for uncovered 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 uses specific verbs and resources: 'Open a Signal Futures position', 'predict what the NEXT SqueezeOS council verdict will be', and clarifies the mechanism (staking RLUSD, taker bets opposite side). It clearly distinguishes from sibling tools like futures_browse (browsing) and futures_take (taking positions).

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 explains when to use the tool (to predict a council verdict and stake RLUSD), mentions auto-settlement and payout mechanics, and implies the alternative usage of being a 'taker' (futures_take). It lacks explicit 'when not to use' statements but provides clear 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 provided, the description carries the full burden. It implies a read-only operation (showing data) and mentions 'Free', but does not disclose potential side effects, authentication needs, or rate limits. Adequate for a simple query tool but lacks depth.

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 short sentences with no wasted words. Front-loaded with the core purpose, followed by details. Highly concise.

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 nature of the tool (one optional parameter, no output schema), the description adequately covers what it does and what data it returns. It could mention that results are ranked, but the context is largely 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 only parameter 'limit' is fully described in the schema (default 20, max 100). The description adds no additional meaning beyond the schema, so baseline score 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 retrieves a leaderboard of top signal futures predictors ranked by wins, displaying win rate, PnL, and total staked. It distinguishes from sibling tools like futures_browse or futures_create by focusing on rankings and 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 does not provide guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states what it does without usage 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 fully shoulders behavioral disclosure. It reveals that stakes are locked immediately, the settlement occurs on the next council verdict, and the tool is free. The win condition is openly stated, providing transparency about risks.

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 four sentences, each adding value: action, win condition, immediate lock, settlement, cost. No redundant information, and the key points are 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 covers the core behavior, win condition, settlement, and cost. There is no output schema, and return values are not described, but for a simple action tool this is adequate. Minor gap: no mention of error cases or prerequisites.

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 parameters documented (future_id: 'UUID from futures_browse', taker_wallet: 'Your XRPL wallet'). The tool description does not add additional parameter-specific semantics 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 verb 'take' and the resource 'opposite side of an open Signal Futures position'. It explains the win condition (council verdict does not match creator's prediction) and settlement trigger. This distinguishes it from siblings like futures_create and futures_browse.

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 explains when to use the tool (to take the opposite side) and the conditions of winning. However, it does not explicitly state when not to use it or provide alternative tools. The context is clear but 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. It discloses the return fields (XRPL destination, amount in RLUSD, memo_hex) and that the action is free. However, it does not mention rate limits, expiration, or potential errors.

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 serving a purpose: first states the action, second describes the return, third gives the flow and cost. 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?

For a simple tool with one parameter and no output schema, the description is fairly complete. It covers purpose, return values, and next steps. Minor missing details like invoice expiry but acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter with 100% schema coverage. The description adds context that the endpoint_id is for 'any SqueezeOS endpoint' and that it's for payment, slightly enriching the schema description.

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 verb 'request', the resource 'payment invoice', and the target 'any SqueezeOS endpoint'. It also distinguishes from siblings like 'verify_payment' by specifying that this is for getting the invoice before payment.

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 clear context: use this to get an invoice, then pay on XRPL and call 'verify_payment'. It also notes it's free. However, it does not explicitly exclude cases when not to use it or mention 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 must carry the full burden. It only states 'Browse' (implying read) and 'Free', but lacks details on pagination, rate limits, return format, or any 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?

Two sentences with no waste. Front-loaded with clear verb and resource, then filter options, then a note on cost. Every sentence 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?

No output schema exists, so the description should explain what is returned. It does not mention result format, pagination, or whether results are limited. Given the absence of annotations, this is a significant gap.

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%, so the description should provide meaning for each parameter. It lists 'type', 'symbol', and 'min_bounty' but does not explain valid values, constraints, or format, leaving ambiguity.

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 'Browse' and the resource 'open agent hiring jobs', and lists filtering capabilities. It distinguishes well from the sibling tool 'hiring_post_job'.

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 when to use (to browse jobs), but does not explicitly state when not to use or provide alternatives. Among siblings, 'hiring_post_job' is clearly for posting, so usage is distinct.

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 the payment mechanism (direct XRPL wallet-to-wallet) and that posting is free. However, it omits behavioral details such as job visibility, lifecycle after posting, and whether any permissions or rate limits apply.

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, front-loaded with the core purpose. Every sentence adds value with 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?

Given 7 parameters and no output schema or annotations, the description is too brief. It does not explain parameter roles, return values, or confirmations, leaving the agent with insufficient context for correct 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 description coverage is very low (14%), and the description does not explain any parameters. It fails to add meaning beyond the schema for parameters like symbol, job_type, bounty_rlusd, deadline_hours, or payment_wallet.

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 ('Post'), the resource ('analysis job'), and the target audience ('other agents to fulfill'). It also distinguishes from the sibling tool 'hiring_browse_jobs' by focusing on posting rather than browsing.

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 analytical job posting but does not provide explicit guidance on when to use this tool versus alternatives like 'hiring_browse_jobs'. No exclusions or prerequisites are mentioned.

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 details the internal process (five analysts, five factors), cost (0.05 RLUSD), output fields, and that internal parameters are proprietary. This provides comprehensive behavioral insight.

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 verbose, mixing high-level purpose with detailed analyst methodology. While informative, it could be more concise without losing clarity, especially for a tool with only three parameters.

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?

Despite lacking an output schema, the description thoroughly explains output fields (action, rationale, vehicle, invalidation condition, etc.), prerequisites (payment token, wallet), and cost, leaving little ambiguity.

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%, but the description adds meaningful context: payment_token is a JWT from verify_payment and agent_wallet is an XRPL wallet. This enhances understanding 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 resolves forced market actions, not predictions, and specifies the output (BUY/SELL/HOLD, rationale, etc.). It distinguishes from iam_truth, making the purpose precise.

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 advises using iam_truth for a free preview before paying, indicating a cost-saving alternative. However, it doesn't explicitly outline when to choose iam_resolve over other sibling tools beyond this contrast.

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 fully discloses behavioral traits: it returns a raw pressure vector with enumerated components, directional bias always NONE, and a time window. It states there is no action resolution, indicating a safe, read-like operation. However, it does not mention any potential side effects or authorization needs, which prevents a perfect score.

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, consisting of a few well-structured sentences. It front-loads the core purpose and then details the output components efficiently. Every sentence adds value without 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 lack of output schema, the description thoroughly explains the return values: Volatility Release, Liquidity Refill, Dealer Hedge, Mean Reversion Pull, Structural Pressure (all 0-100%), Directional Bias (always NONE), and Time Window (DORMANT / DEVELOPING / NEAR_TERM / IMMEDIATE). This fully equips the agent to understand the tool's response.

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 one required parameter ('symbol') with description 'US equity ticker'. Since schema coverage is 100%, the description does not add extra semantics beyond what the schema already provides. It references the symbol implicitly but adds no further constraints or formatting 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 the tool's purpose: 'IAM Truth Layer — neutral obligation state for a symbol. No action resolution.' It specifies the exact output (raw obligation pressure vector with components) and distinguishes from sibling 'iam_resolve' by emphasizing neutrality and no action resolution.

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 implicitly indicates usage for obtaining neutral obligation state before forcing direction, and mentions it is a 'Free endpoint.' However, it does not explicitly compare with siblings like 'iam_resolve' or provide clear when-to-use vs. when-not-to-use guidance. The statement 'No action resolution' offers some directional context but lacks complete guidelines.

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. It mentions a cost of 0.03 RLUSD, implying payment/charge, but does not clarify if the scan is read-only, modifies state, or requires authentication. The behavior is partially transparent but lacks key details.

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 (one sentence plus cost) and front-loaded with purpose. However, it omits essential details, making it under-specified rather than concise.

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 minimal schema (no parameter descriptions, no output schema), the description fails to provide sufficient context. It does not explain the return format, prerequisites, or what 'scored contracts' means, leaving the agent underinformed.

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 meaning to the two parameters (agent_wallet, payment_token). The cost mention hints at payment_token's role but is not explicit. The parameters remain opaque.

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 is a scanner for IWM zero-day-to-expiry options, listing specific metrics like delta/gamma, gamma flip level, max pain, and 30-day realized vol. This verb+resource combination is specific, distinguishing it from broader tools like market_scan or options_intelligence, though not explicitly differentiating.

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

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

No guidance on when to use this tool versus alternatives. Among siblings, there are multiple scanning tools (beastmode_scan, market_scan, options_intelligence), and the description provides no context for selection. The cost mention is useful but insufficient for usage decisions.

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?

Discloses cost, alerting behavior for PERFECT states, and squeeze_alert condition despite no annotations. Does not mention error handling 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?

Front-loaded with purpose and packed with information, but slightly redundant (cost mentioned twice). Still every sentence serves a 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?

Without an output schema, the description adequately explains return values (three states and squeeze_alert). Missing details on data range or error handling, but sufficient for agent decision-making.

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?

Adds significant meaning beyond schema descriptions by explaining the three macro states and the condition for squeeze_alert, which the schema does not include. Also explains the payment token source.

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 computes 5-layer EMA alignment on daily closes and returns three macro states per ticker, distinguishing it from sibling tools like market_scan or beastmode_scan which likely have different algorithms.

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?

Provides usage instructions (max 50 symbols, cost, required parameters) but does not differentiate when to use this over siblings like proprietary_ema_signal or convergence_check.

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 bears full burden. It only mentions 'Free', indicating no cost, but lacks details on return format, pagination, rate limits, or any side effects. The tool's behavior is underspecified.

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 with no fluff. It is front-loaded with the core action. However, it may be too concise, missing important context.

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 has 2 parameters and no output schema, the description is incomplete. It does not explain what the tool returns, any prerequisites (e.g., authentication), or how to interpret results. A more complete description would add significant value.

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%, so description must compensate. It says 'Filter by symbol or bias' but does not explain the format of symbol (e.g., stock ticker) or the meaning of bias enum values. This adds minimal value 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 uses a specific verb 'Browse' and clearly identifies the resource as 'peer signal marketplace listings'. It notes filtering by symbol or bias and mentions it is free. This distinguishes it from sibling tools like marketplace_list_signal and marketplace_read_signal.

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 via browsing and filtering but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. Given sibling tools with similar names, clearer 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.

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

No annotations provided. Description discloses that it's a write operation with financial implications but lacks details on idempotency, limits, or post-posting behavior. More transparency needed for a mutation 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?

Two sentences, efficient and front-loaded with the main purpose. 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?

Given 9 undocumented parameters and no output schema, the description is insufficient for an agent to correctly invoke the tool without additional knowledge.

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 has 9 parameters with 0% description coverage. The description does not explain any parameter meaning or usage, failing to compensate for the schema gap.

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 'Post your own analysis signal' with verb 'post' and resource 'analysis signal'. It distinguishes from sibling tools like marketplace_browse and marketplace_read_signal.

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 mentions cost and rewards but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. Usage context is implied.

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?

Implies read-only operation ('Read full thesis'), discloses cost as a behavioral constraint, and lists returned data. However, no explicit statement about side effects, idempotency, or required authentication, leaving gaps given no 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?

Extremely concise, single sentence plus cost note. No superfluous information. However, lacks structure like headings or list, but appropriate for a simple read operation.

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 low schema coverage, no output schema, and no annotations, the description omits important context: return format, error handling, cost mechanics, prerequisites like wallet balance. Incomplete for an agent to reliably invoke.

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 low (33%) with agent_wallet and payment_token undescribed. Description does not explain these parameters beyond what's in the schema. Minimal value added for parameter understanding.

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 verb 'Read' and resource 'full thesis for a marketplace signal listing', listing returned fields. Distinguishes from siblings like marketplace_browse and marketplace_list_signal which handle listing exploration and creation 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?

No guidance on when to use this tool versus alternatives like marketplace_browse. No exclusions or prerequisites beyond mentioning cost. The agent lacks context for tool selection.

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 partially covers behavior by stating it returns data and costs RLUSD, but it does not disclose whether the tool is read-only, has side effects, or requires specific authentication beyond the wallet.

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 efficiently conveys the tool's purpose and cost with no unnecessary 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?

The description lacks details on output structure and full parameter semantics, making it insufficient for an AI to safely invoke the tool without additional context.

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 explain the purpose of agent_wallet or payment_token, leaving the AI to guess their meanings.

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's a scanner for equities in the $1-$50 range, returning setups ranked by score and options picks. It distinguishes from siblings like beastmode_scan by specifying the price range and scoring method.

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 mentions a cost requirement but provides no guidance on when to use this tool versus alternatives, nor any prerequisites or contraindications.

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; description fully describes the tool as a read-only scanner without side effects. It explains inputs (API descriptions), process (scanning for patterns), and output (ranked issues with fix advice). No hidden behaviors.

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?

Four sentences, each adding value: purpose, what it scans, output, and usage recommendation. No redundant or unnecessary text. Front-loaded with 'API Narrative Optimizer'.

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 parameters and no output schema, the description fully covers the tool's function, inputs, process, and output. It also provides usage context (run before updating manifests). 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?

Input schema has zero parameters, so parameter semantics are not applicable. Description correctly omits parameter details, aligning with the schema coverage of 100%.

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 specifies verb 'Analyze' and resource 'ScriptMasterLabs API descriptions' for AI-discoverability weaknesses. It clearly distinguishes from siblings by naming specific files (llms.txt, .well-known/mcp.json) and outputs (ranked issues with fix advice). No ambiguity.

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

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

Explicitly states 'Run this before updating discovery manifests,' giving clear context. However, no mention of when not to use or alternatives among 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?

No annotations provided. Description mentions cost and lists features but does not disclose side effects, data freshness, or whether it is read-only. Lacks behavioral details beyond a summary.

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?

Description is compact (single sentence with bullet points) but lacks clear structure. Front-loads key terms but mixes features and cost without separation.

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 options intelligence and no output schema, the description is severely incomplete. Missing parameter explanations, usage context, and return value 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 has 2 parameters (agent_wallet, payment_token) with no description. Schema description coverage is 0%, and the description does not explain these parameters at all, leaving the agent unable to fill them correctly.

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 provides institutional options flow data including sweep detection, whale blocks, and various ratios. It implies data retrieval, but lacks a specific verb like 'retrieve' or 'scan'. It is distinct from sibling tools like market_scan or futures_browse.

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

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

No guidance on when to use this tool versus alternatives. The cost is mentioned but not how to pay or prerequisites. Sibling tools exist but no comparisons provided.

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 exist, so the description carries full burden. It states 'No payment required' and implies read-only behavior, but does not disclose authentication needs, rate limits, or other potential behaviors. Adequate 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 concise with no wasted words. It front-loads the purpose, lists feeds, and ends with usage advice. Every sentence is informative and 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?

Despite lacking an output schema, the description fully explains the return values (names, descriptions, buffer counts, etc.) and lists all available feeds. Zero parameters makes the tool simple, and the description covers all necessary context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description adds value by detailing the returned fields, which goes beyond the empty 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's purpose: 'Free catalog of all available Real-World Data Oracle feeds' and specifies the returned data. It distinguishes from the sibling tool oracle_query by advising to use this first.

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?

Explicit usage guidance: 'Use this before calling oracle_query to see what data is available.' This provides clear context for when to use the tool, though it does not cover when not to use it or alternatives beyond oracle_query.

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 fully carries the burden. It discloses the paid nature (0.02 RLUSD), the need for a payment token, the sub-second latency, and the return format (machine-readable JSON with timestamps, source URLs, structured fields). This is comprehensive for a data retrieval tool, though it lacks details on error handling or rate limits.

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 information-dense but not overly verbose. Every sentence adds value, covering purpose, parameters, cost, and performance. The initial 'Premium (0.02 RLUSD)' might be somewhat promotional but is still relevant. It is well-structured with clear points.

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 output schema, the description adequately describes the return format. It covers the main use cases (querying all feeds, filtering by keyword and timestamp) and mentions performance. However, it could be more explicit about optional parameters like limit, though they are in the schema. Overall, it provides sufficient context for an agent to call the tool 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 description coverage is 100%, with each parameter documented. The description adds value by explaining usage patterns: passing feeds=[] queries all feeds, keyword performs text-search, since_ts is a Unix timestamp, and payment_token is obtained from verify_payment. This provides practical context 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 defines the tool's purpose: searching or retrieving events from the Real-World Data Oracle across four specific regulatory feeds. It uses a specific verb ('search or retrieve') and resource ('events from the Real-World Data Oracle'), and it distinguishes itself from siblings like oracle_feeds by detailing the filtering and querying capabilities.

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 for usage, including cost, required payment token, and performance comparison to Bloomberg. However, it does not explicitly specify when to use this tool vs. alternatives (e.g., oracle_feeds) or when not to use it. Usage is implied from the description but not clearly delineated.

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 the description fully carries the burden. It explicitly discloses that price levels, EMA values, and raw indicator readings are stripped server-side, and only specific fields are delivered. This is extensive behavioral 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 three sentences, front-loaded with the core action, and every sentence adds value. No fluff or 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 9-parameter tool with no output schema, the description covers the main behavioral aspects (sanitization, webhook fallback). It lacks details on return values or error handling, but given the simplicity of a webhook post, it is sufficiently 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 description coverage is 67%, so baseline is 3. The description adds value by explaining that parameters constitute a signal brief that gets sanitized, providing context beyond the field-level descriptions. However, it does not elaborate on each parameter individually.

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 posts a sanitized market signal brief to Slack via webhook. The verb 'post' and resource 'sanitized market signal brief' are specific. Among siblings, this is the only Slack posting tool, so it is well-distinguished.

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 explains when to pass webhook_url for personal channels versus omitting for the shared channel, and notes it is free. This provides clear usage guidance and an alternative, though it does not explicitly say 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.

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

No annotations provided, so description carries full burden. It describes the three engines and consensus levels, mentions the tool is free, but does not disclose potential rate limits, authentication needs, or behavioral constraints beyond the return values.

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 detailed yet efficiently structured, front-loading the core function and listing consensus levels. Every sentence adds value, though it could be slightly more concise.

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 (one parameter, no output schema), the description provides adequate context: engine mechanics, consensus levels, and return values. It covers what an agent needs to know to select and invoke the tool 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?

Input schema coverage is 100% with a single parameter 'symbol' described as 'US equity ticker'. The description adds no additional semantics beyond the schema itself, earning a baseline score of 3.

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 evaluates three independent engines on market dimensions to produce high-conviction consensus. It lists specific consensus levels and outputs, making the purpose clear. However, it does not explicitly differentiate from sibling tools like market_scan or oracle_query.

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 obtaining consensus on US equities, but lacks explicit guidance on when to use this tool versus alternatives (e.g., for different signal types or use cases). No when-not instructions are provided.

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 explains what the tool returns (score, components, per-agent-type breakdown, hourly trend) and notes it is 'Free,' but does not explicitly state that it is read-only, non-destructive, or any potential side effects. Overall adequate but could be more transparent.

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, front-loaded with the tool's identity and purpose, and efficiently packs key information (score range, components, returns, usage guidance). Minor redundancy with 'Free' but overall 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 no output schema, the description adequately explains the return values (score, components, breakdown, trend) and the purpose. The two parameters are fully covered by the schema. Additional context like 'Free' is extraneous but not harmful. The description feels complete for an agent to use.

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 baseline is 3. The description does not elaborate on parameter usage beyond what is in the schema; it only mentions 'per-agent-type breakdown' and 'hourly trend' which loosely relate to view options, but no explicit mapping.

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 explicitly names the resource ('SqueezeOS API provider quality score'), provides the score range (0–850), and lists components (volume, diversity, conversion, repeat rate). This clearly distinguishes it from sibling tools like 'bureau_public_score' or 'citation_score' which likely serve different purposes.

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 the intended use case: 'benchmark provider authority before integrating or citing SqueezeOS.' While it does not list when not to use or mention alternatives, the guidance is clear and context-specific.

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 mentions scanning sources and a 'Free' tag, but does not disclose rate limits, data freshness, authentication needs, or whether results are cached. The behavioral traits are minimally covered.

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 4 sentences, front-loading the purpose and key action. The marketing flourish ('™', 'Discover') is minor; no superfluous sentences. The 'Free.' note adds a tiny bit of extra info but is not wasteful.

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, so the description should clarify the return format. It only vaguely says 'Returns ranked topics...' without specifying the structure (e.g., fields, pagination). With 3 optional parameters and moderate complexity, the description is insufficient for an agent to fully understand what to expect.

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 the baseline is 3. The description adds a bit of context for the 'action' parameter (e.g., 'gaps=leaderboard'), but does not significantly enhance understanding of parameter values beyond what the schema already provides. No parameters are left undocumented.

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: discovering unmet API demand by scanning Reddit/Hacker News. It uses specific verbs ('Discover', 'Scans', 'Returns') and identifies the resource ('developer community'). The name 'semantic_gaps' aligns with the function, and the description distinguishes it from siblings by focusing on API demand signals.

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 some usage guidance (e.g., 'Use this to identify new product opportunities', 'Trigger a fresh scan with action='scan''), but it does not compare this tool to siblings like 'market_scan' or specify when _not_ to use it. The guidance is limited to parameter hints and a vague use case.

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 the description should disclose behavioral traits. It only says 'Free' and 'Browse', but does not explicitly state read-only nature, rate limits, or output format. Lacks crucial context for safe usage.

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 short sentences, no redundant information. Efficient and to the point.

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 browse tool with no output schema, the description covers basic function but omits details like what constitutes a 'conditional settlement contract', how results are presented, or pagination. Adequate but incomplete.

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 only 25% (only wallet described). The description adds that filtering is by symbol or wallet, but does not explain limit, status, or enum values. Minimal added value beyond 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's purpose: browse open conditional settlement contracts with filtering options. It distinguishes from sibling tools like settlement_create and settlement_trigger.

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 mentions filtering by symbol or wallet but does not provide explicit guidance on when to use or not use this tool vs alternatives. No exclusions or prerequisites listed.

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 fully shoulders the transparency burden. Discloses platform fee (1% on settlement), that creation is free, and that SqueezeOS tracks and proves conditions while wallets settle directly. However, lacks detail on error cases or reversibility.

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 the core purpose ('Create a conditional agent-to-agent escrow contract'), immediately followed by a concrete example of the lock intent. Only two sentences, each serving a purpose with zero 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 (8 parameters, 5 required, no output schema), the description covers the essential behavioral contract: what it does, conditions, fee structure, and tracking mechanism. Could be improved by noting the return format or potential errors, but currently adequate 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 description coverage is 88%, and the description adds significant meaning beyond field names: explains the contract intent, condition types with examples ('BULLISH', '75', '220.50'), and the purpose of each wallet. The description compensates for the small uncovered portion.

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 tool creates a conditional agent-to-agent escrow contract with a specific lock intent. Lists distinct condition types (bias_match, confidence_above, etc.) and distinguishes itself from siblings like settlement_browse and settlement_trigger.

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?

Provides clear usage context (creating conditional escrow contracts) and enumerates possible conditions, but does not explicitly state when not to use this tool or mention alternatives beyond the sibling list.

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 side effects (publishes to SSE stream), return value (proof on success), cost (free), and permissions (anyone). Missing behavior when condition not met, but otherwise 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?

Highly concise: three short sentences that front-load the core action. No unnecessary words; every sentence 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 tool with one parameter and no output schema, the description covers purpose, side effects, return, access, and cost. Slightly incomplete on handling when condition is not met, but sufficient for typical use.

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. Description does not add new information about the contract_id parameter beyond what the schema already provides ('UUID from settlement_browse').

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 the action: checking a settlement contract's condition and settling if met. Distinguishes from siblings like settlement_browse and settlement_create by specifying the trigger behavior.

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?

Describes who can call (anyone) but does not explicitly contrast with sibling tools or state when not to use it. Usage context is implied but lacks 'when-not' 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?

No annotations are provided, so the description fully bears the burden of transparency. It discloses the limit of 200 records, ordering, and the types of signals included. It does not mention any side effects but none are expected. The mention of 'Free' adds transparency about cost.

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 extremely concise at two sentences, with critical information front-loaded: the cap of 200 signals, the required symbol, signal types, ordering, and a note about being free. Every sentence serves a purpose with 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?

Given the tool's simplicity (one parameter, no nested objects, no output schema), the description provides sufficient context about what the tool returns and how to use it. The lack of an output schema is not a problem here because the description adequately describes the response structure.

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% coverage with a description for the single parameter 'symbol' as 'Equity ticker'. The tool description does not add any additional semantic meaning beyond what the schema already provides, so a baseline score 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 returns the last 200 recorded signals for a given symbol, lists the signal types, and specifies ordering (newest first). It distinguishes itself from sibling tools like signal_preview by focusing on historical signal retrieval.

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 indicates it is free and useful for backtesting and confidence calibration, providing context for when to use it. However, it does not explicitly state when not to use it or mention alternatives among siblings, which would enhance the 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?

With no annotations, the description carries full burden. It discloses a 15-minute cache and states the tool is not tradeable, which are useful behavioral traits. However, it does not describe the return format or side effects, though given it's a preview, these are minor 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, front-loaded with purpose, zero wasted words. Every sentence 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 one-parameter tool with no output schema or annotations, the description covers purpose, usage, caching, tradeability, and alternative. It is fully complete within this context.

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 no additional meaning beyond the schema's 'Equity ticker' description, but the schema already fully documents the single parameter.

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: 'Free bias + regime preview for any symbol.' It uses a specific verb (preview) and resource (bias + regime), and distinguishes from sibling council_verdict by noting it's not tradeable and directing to the alternative.

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

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

Explicitly states when to use (free preview) and when not to use (not tradeable), and directly names an alternative tool (council_verdict) for full thesis.

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?

Without annotations, the description carries full responsibility. It discloses that raw EMA values and price levels are not returned and that the calculation is proprietary. It also mentions the 0.03 RLUSD payment requirement. However, it does not detail authorization needs, error conditions, or 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?

The description is three well-structured sentences: first states the tool and cost, second explains the output meaning, third clarifies limitations. No unnecessary words, front-loaded with key 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 adequately explains the return values (ABOVE/BELOW) and their significance. However, it omits details on parameter requirements (agent_wallet and payment_token are not listed as required in the schema but seem necessary), error handling, and how to obtain the payment token.

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 the baseline is 3. The description adds the 0.03 RLUSD context for payment_token but does not provide additional semantic meaning beyond what the schema already offers for any parameter.

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 ABOVE or BELOW based on the 365-day EMA, specifying the resource and the signal type. It distinguishes from siblings like sovereign_741 by referencing the specific EMA period.

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 macro trend assessment ('bull structure intact' vs 'bear structure'), but does not explicitly state when to use or avoid this tool compared to alternatives like sovereign_full or sovereign_triplelock. No exclusions are mentioned.

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, but description adequately discloses return type (labels only), what is not returned (EMA values, spreads, price data), and mentions proprietary engine. Also hints at cost via parameter.

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, front-loaded purpose, each sentence adds value. 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?

Covers input, output types, and special conditions (squeeze_alert). Lacks output schema but given simplicity, it is sufficient for an AI agent.

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 covers 100% of parameters with descriptions. Description adds context about cost and proprietary nature but does not enhance parameter meaning beyond 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?

Description clearly states the tool returns a macro highway signal for US equities with specific labels (BULLISH, BEARISH, CONSOLIDATION). Does not explicitly differentiate from siblings like sovereign_full, but specificity is high.

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. Usage context is implied for macro analysis but no when-not or alternatives are provided.

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 full burden. It clearly states that no raw values, EMA levels, or indicator readings are returned, and it specifies the cost (0.10 RLUSD) and the need for a JWT. This sets accurate expectations for the tool's behavior.

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 four sentences long, front-loaded with the tool's main function. It efficiently conveys purpose, verdicts, and constraints without unnecessary detail, though it could be slightly more concise.

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 output schema, the description explains the possible return values (verdicts and squeeze_alert) and what is not returned. It is sufficient for an agent to understand what to expect, though the exact output format is not specified.

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 the baseline is 3. The description does not add any meaning beyond what is already in the input schema; it merely repeats the same information about symbol, wallet, and payment token.

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 that the tool runs three sovereign engines and combines them into a single verdict, listing the possible verdicts explicitly. This distinguishes it from sibling tools like sovereign_741, sovereign_365, and sovereign_triplelock which are individual engines.

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 that this tool is for when a combined signal from all three engines is desired, as it says 'Runs all three sovereign engines and combines them'. However, it does not explicitly state when to use this versus the individual engine tools, leaving it to the agent to infer from sibling names.

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 discloses the cost (0.05 RLUSD), requirement of payment token, and that only labels are returned (no raw values). It does not mention error handling or permissions, but provides essential behavioral 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 one paragraph, front-loads key info (signal name, cost), and is concise. Slightly more structure could improve readability, but it is efficient.

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

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

For a 3-parameter tool with no output schema, the description thoroughly explains all four possible return values and their meanings. It lacks error case details but is otherwise 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% and schema descriptions are adequate. The tool description adds no extra parameter details beyond what the schema provides, 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 specifies the tool returns a consensus signal (LOCKED BULL, LOCKED BEAR, FORMING, UNLOCKED) from three engines, clearly stating the resource and verb. It distinguishes from siblings like sovereign_365 and sovereign_741 by focusing on triple-lock consensus.

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 high-conviction signals and advises waiting for alignment (UNLOCKED). It does not explicitly list alternatives or when not to use, but the context is clear.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions returning uptime and version, and says 'Free' (likely meaning no cost). It omits details like authentication requirements, side effects, rate limits, or response format. This is insufficient for a safe agent decision.

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 extremely concise with no wasted words. It front-loads the primary purpose ('SqueezeOS system health check') and immediately states outputs. 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 and no output schema, the description is minimally adequate but lacks details like response structure or error states. For a health check, an agent might need to know if it returns JSON or plain text, or what 'uptime' format is used. Fills basic purpose but leaves 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?

The input schema has zero parameters (100% coverage trivially). No parameter documentation is needed; the description's mention that it returns uptime and version confirms the stateless, read-only nature. Baseline score of 4 is appropriate per rules.

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 performs a 'system health check' and returns 'uptime and version', which is a specific verb+resource. Among sibling tools like autopilot_status or marketplace_browse, this is uniquely identified as a system-level diagnostic.

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

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

No guidance on when to use this tool vs alternatives. It does not mention prerequisites, typical use cases, or situations where other tools would be better suited. The agent is left without context for selection.

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. Mentions side effects (submission, returns JWT) and that it is free, but lacks details on error handling, idempotency, or irreversible actions.

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, front-loaded with the action. Every sentence provides essential information; no fluff.

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, but description mentions return value (JWT with TTL). However, lacks details on error conditions, prerequisites, and the role of each parameter, leaving some gaps for the agent.

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 75%, so baseline is 3. Description adds minimal value beyond schema; it ties tx_hash to the action but does not explain invoice_id or agent_wallet roles.

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 the action: submit an XRPL transaction hash after paying an invoice. Distinguishes from siblings as no other tool handles payment verification.

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?

Implies usage after paying an invoice, giving a clear trigger. Does not explicitly mention alternatives or when not to use, but the context is sufficient.

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