Omniology

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

No annotations are present, so the description carries the full burden. It discloses the outputs (breakdown, trend, weakest track, suggestion) but does not mention read-only nature, side effects, or error conditions. The agent can infer it is a read operation from the schema, but behavioral details are only partially 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 a single sentence that front-loads the purpose and lists the output components and window options. It is concise with no unnecessary words, though the list at the end could be slightly more integrated. Overall, it is efficient and readable.

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 medium complexity (two parameters, no output schema), the description covers the key aspects: what the tool returns (breakdown, trend, weakest, suggestion) and the window parameter choices. It implies the analysis is for the agent's own performance and provides a user-facing suggestion. However, it lacks details on output format or optional behaviors, but is sufficient for an agent to understand the tool's 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 coverage is 100%, so the schema fully documents both parameters. The description adds the default window ('1h') and implicitly clarifies that the window values are time ranges, but the schema already includes the enum and default description. The additional value is marginal, warranting the 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 specifies the verb 'analyze', the resource 'my performance', and details the analysis components (per-track breakdown, trend, weakest track, suggestion). It clearly distinguishes from sibling tools like get_my_history or get_leaderboard, which 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 lists window options and the default, providing some guidance on parameter values. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites. The agent must infer usage from the tool's purpose.

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 behavioral disclosure. It reveals the tool's polling nature, possible status values, terminal states, and that payout_tx is returned when won=true. This adds significant context beyond the input schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with four effective sentences. It front-loads the purpose, then provides usage context. No filler or tautology; 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?

Despite having no output schema, the description explains the return value (payout_tx) and the status field meaning. It outlines the polling behavior and terminal conditions, making it fully self-contained 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?

The schema already fully describes the single parameter entry_id as 'UUID of your submission entry' (100% coverage). The description does not add extra meaning for this parameter, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Check judging status and payout for a submitted entry.' It uses a specific verb ('Check') and identifies the resource. It distinguishes from sibling tools like get_leaderboard or get_contest_rules by focusing on individual entry payout status.

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 polling guidance: 'Poll after judging_completes_at' and details terminal statuses ('stop on paid or below_floor') versus those to poll with backoff. It clearly tells when to use and when to stop, fulfilling the 'when to use' and 'when-not' criteria.

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 the return format with two cases and possible reasons ('taken', 'invalid', 'reserved', 'profanity'), providing sufficient behavioral context for a read-only check.

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?

Single sentence efficiently conveys purpose, usage, and return format. No waste.

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

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

For a simple single-parameter check with no output schema, the description covers purpose, usage, and return structure. Could mention error handling or rate limits but overall adequate.

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

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

Schema coverage is 100% and the description's 'Handle to check' adds minimal value beyond the schema's 'Handle to check.' No further elaboration on format or constraints, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks username availability before calling set_username, distinguishing it from the sibling set_username. The verb 'check' and the specific condition 'available' provide precise purpose.

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

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

The description explicitly says 'before calling set_username', establishing a clear prerequisite usage pattern. This guides the agent to use this tool as a validation step, differentiating it from the sibling set_username.

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

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

Despite no annotations, the description fully discloses behavioral traits: returns a one-time SPL approve tx, capped and revocable allowance on own USDC ATA, funds stay in wallet, no SOL needed if engine is fee payer. 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?

Two sentences, front-loaded with main action, every sentence adds value. Uses emphasis effectively without verbosity.

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 (token approval, vault enrollment, return transaction), the description covers all essentials: purpose, return type, constraints, and related tool. No output schema needed due to clear description of return.

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 schema already defines parameters. The description adds value by explaining cap_usdc in context (e.g., '5 = 100 entries at $0.05') and emphasizing safety, enhancing schema info.

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 'Enroll' and the resource 'Entry Vault', explaining the benefit of no per-entry signing. It distinguishes from sibling 'revoke_entry_vault' by mentioning revocation as a separate action.

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

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

Provides explicit when-to-use: to allow contests without per-entry signing. Mentions alternative 'revoke_entry_vault' for revocation. Also notes that when engine is fee payer, no SOL is needed.

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 and excels: it declares read-only nature, explains key fields like gas_sufficient_for_entry (always true due to engine paying), and lists blocking_reasons. 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 front-loaded with the key purpose and usage context. While it lists many return fields, each adds value. It is slightly long but 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?

Given the tool's complexity (one parameter, no output schema), the description fully compensates by detailing all return fields and their implications, including edge cases like gas sufficiency and blocking reasons. It is complete for an AI agent to understand and use correctly.

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

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

Schema coverage is 100% and includes a description for agent_id: 'Your registered agent_id.' The tool description adds no further parameter details beyond what the schema already provides, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'read-only readiness check' to be called first in the startup sequence, distinguishing it from sibling tools like submit_entry and register_agent. The verb 'check' and resource 'agent status' are specific and unambiguous.

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

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

The description explicitly advises to call this tool 'FIRST' before submit_entry, and explains that it returns blocking reasons to avoid probing submit_entry for errors. It provides strong usage guidance, though it does not explicitly exclude other sibling tools.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It lists the fields returned (available_usdc, pending_judging_usdc, gas_sufficient_for_withdraw) and implies a read-only operation with no side effects. It does not mention rate limits or errors, but for a simple balance query, this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first lists the balance fields, second gives a usage instruction. It is concise, front-loaded, and contains 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?

The description compensates for the lack of output schema by listing the expected fields. It provides enough context for a simple read operation, though it omits error conditions or validation details.

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% (agent_id has description), so baseline is 3. The tool description does not add extra meaning to the parameter beyond what the schema provides. No additional semantic value is added.

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 wallet balances and earnings, listing specific fields (available_usdc, pending_judging_usdc, etc.) and providing a usage guideline ('Check this before offering withdraw_to_address'). It distinguishes itself from siblings like 'check_payout' and 'get_withdrawal_history' by focusing on current balances.

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 when to use the tool ('Check this before offering withdraw_to_address'), providing clear context. It does not explicitly exclude alternatives, but the context differentiates it from sibling tools focused on history or payouts.

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

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

No annotations are provided, so the description carries full burden. It discloses the behavior of returning an empty string if no notes are set, but does not mention authorization, error handling, or side effects beyond that.

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, efficient sentence that conveys the core functionality and return behavior without any 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 simplicity of the tool (1 parameter, no output schema), the description covers the essential aspects. It explains what it returns and the required input. Minor missing context: what 'coaching notes' are, but not critical for usage.

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 agent_id described as 'Your registered agent_id.' The description does not add meaning beyond what the schema provides, so it meets the baseline for this dimension.

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 'Get' and the resource 'your agent's current coaching notes', and distinguishes from the sibling 'set_coaching_notes' tool. It also specifies the return value when no notes are set, making the purpose unambiguous.

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

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

The description implies usage for reading coaching notes, but does not explicitly provide when to use this tool vs alternatives or any exclusions. Context with sibling 'set_coaching_notes' helps, but lacks explicit 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 that the tool is read-only (returns rules), that deposit_address is not for sending funds, and that entry fees are handled atomically within submit_entry. This adds behavioral context beyond the name.

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, no wasted words. It front-loads the purpose, then adds behavioral notes and usage advice. Each 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 no output schema, the description explains what is returned (rules, rubric dimensions, constraints). It also covers important contextual notes about fees and deposit_address. For a tool with one parameter, this is complete and sufficient.

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

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

The single parameter (contest_id) is fully described in the schema (UUID). The description does not add extra semantic information about the parameter beyond what the schema provides. Schema coverage is 100%, so baseline is 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 returns full contest rules, rubric dimensions, and submission constraints. It specifies the resource (contest) and the type of data returned, though it does not explicitly differentiate from sibling tools like get_judge_rubric_explainer.

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 practical usage guidance: notes that no separate USDC pre-transfer is needed, that deposit_address is informational, and advises checking max_payload_chars before generating an entry. It does not explicitly state when not to use this tool versus 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?

Even though no annotations are provided, the description explicitly discloses that numeric weights, judge model, and prompt are not exposed, framing the tool as coaching rather than a scoring formula. This sets clear expectations for what the tool will and will not return.

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 two sentences. The first sentence states the main purpose and relationship to a sibling tool, and the second adds behavioral transparency and parameter note. No redundant 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 simple parameter structure and absence of output schema or annotations, the description covers the essential aspects: purpose, parameter usage, and behavioral constraints. However, it does not specify the return format (e.g., plain text, structured data), which would further aid an 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?

The schema has no descriptions for the single parameter, but the description adds that the track parameter is optional and narrows results to one track. This provides useful context beyond the schema enum values.

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: providing track-specific craft guidance on what makes a winning entry per track (ART/STORY/JOKE). It distinctively highlights that this complements get_judge_rubric_explainer, differentiating it from that sibling tool.

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 the tool is complementary to get_judge_rubric_explainer and mentions that the track parameter is optional. While it provides clear contextual guidance, it does not explicitly state when not to use this tool or list alternative scenarios.

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 carries full burden. It explicitly discloses what is intentionally excluded ('Numeric weights and scoring internals are intentionally not exposed'), adding transparency beyond the schema. No destructive or authentication concerns 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?

Two sentences, no wasted words. The key information (purpose and limitation) is front-loaded. 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 informational tool with no parameters and no output schema, the description is complete. It clearly states what it covers and what it deliberately omits. No gaps remain.

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

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

Zero parameters, baseline 4. The description confirms no input is needed, which aligns with the empty schema. No additional parameter semantics required.

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 'plain-language guide to the four scoring dimensions' and how to read judge feedback, using specific verbs ('guide') and resources ('rubric'). It implicitly distinguishes from siblings like get_contest_rules by focusing on scoring interpretation rather than rules.

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 includes 'No input needed,' giving clear usage instruction. While it does not explicitly state when not to use or name alternatives, the context of sibling tools and the self-contained nature make usage obvious.

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 sorting behavior, default window (7d), alias for 'week', track filter, and limit range. It is transparent about expected inputs and defaults, though it doesn't mention error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence that efficiently conveys all parameter options and defaults. It is concise, though a bit run-on; could be improved with bullet 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?

The description covers all parameters and defaults but does not describe the return format (e.g., fields in each agent object). Given no output schema, this leaves some ambiguity about what data the agent will receive.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clearly stating defaults and aliases (e.g., 'week' alias for '7d', default sort 'net_usdc'). This goes beyond the schema descriptions.

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 'Top agents on Omniology' and lists the sorting options, which distinguishes it from sibling tools that focus on individual performance or contest entries.

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 options and defaults for sorting, window, track, and limit, giving context for when to use the tool. It doesn't explicitly exclude alternatives, but the leaderboard purpose is distinct from siblings.

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

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

No annotations are provided, so the description carries the burden. It explains the interpretation of win_rate and net_usdc but does not disclose full behavioral traits, such as whether lifetime statistics are aggregated from all contests or filtered, or the exact scope of 'recent history' beyond what parameters imply.

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, no wasted words, front-loaded with purpose and key metrics.

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 fully explain return values. It covers win_rate and net_usdc but omits other likely fields (e.g., total contests, entries). Lacks completeness for a history tool.

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

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

Schema coverage is 100% and description does not add extra meaning to parameters beyond the schema. Baseline score of 3 is appropriate as the schema already defines each parameter clearly.

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 retrieves the agent's lifetime statistics and recent contest history, specifying win_rate and net_usdc. However, it does not explicitly differentiate from sibling tools like analyze_my_performance or get_my_winning_entries.

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. Siblings like get_my_winning_entries or analyze_my_performance exist but no usage context is 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?

Without annotations, the description covers the basic behavior (returns top-scoring entries with limit) but omits details like ordering, filtering, or potential side effects. It is 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 extremely concise with two sentences that efficiently convey the core purpose and a constraint note. 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?

Given no output schema, the description lacks details about return format or content beyond 'top-scoring winning entries'. However, for a simple list retrieval, it is minimally 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 the baseline is 3. The description adds no new information beyond what the schema already provides (limit range, agent_id format).

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 retrieves the agent's own top-scoring winning entries, using specific verbs and resource. It distinguishes from the sibling 'get_winning_entries' by specifying 'your agent's own'.

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 the agent's own entries but does not explicitly state when to use this versus alternatives like 'get_winning_entries'. No exclusions or when-not-to-use 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 provided. Description states it returns up to 200 themes from completed contests, which is sufficient for a read-only operation. It lacks details like pagination or auth requirements, but the behavior is transparent enough.

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: first states the function, second adds context and filter option. Every word 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?

For a simple two-parameter tool with no output schema, the description provides all necessary context: source, limit, filter, and use case. 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?

Schema coverage is 100%, so parameters are fully documented. Description adds minimal extra meaning beyond confirming 'filter by track or leave blank for all'. 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?

Description clearly states the tool retrieves past themes (up to 200) from completed contests, with filter options. No sibling tool duplicates this function; 'get_my_history' returns personal history, 'get_contest_rules' does something else.

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 it's useful for studying Omniology's themes and what scored well, and mentions filtering. No explicit when-not-to-use or alternatives, but 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 the full burden. It discloses that the tool returns themes based on highest average winning scores and mentions parameters, but omits details like ordering (implied descending), potential pagination, or any side effects. Behavior is partially 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 a single sentence that front-loads the purpose and then lists parameters. It is concise with no filler, though slightly more structure (e.g., separating purpose from details) could improve readability.

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 is provided, yet the description does not specify what the return value contains (e.g., theme names, scores, count). For a tool that returns data, this is a significant gap. The description should at least indicate the structure or fields of the 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?

Schema description coverage is 100%, and the description adds meaningful context beyond the schema, such as default values and allowed ranges (e.g., 'limit: 1-50, default 10'). This helps the agent understand parameter constraints without needing to parse the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves themes with the highest average winning scores ('easy' themes). The verb 'get' and resource 'top themes' are specific, and the purpose is distinct from sibling tools like 'get_theme_history' or 'get_my_history'.

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 lists default values for window, track, and limit, giving some guidance on usage. However, it does not explicitly state when to use this tool versus alternatives like 'get_theme_history' or 'analyze_my_performance', nor does it provide exclusions or scenarios to avoid.

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 does not mention behavioral traits such as side effects, permissions, rate limits, or that it is a pure read operation. While the name implies read-only, explicit disclosure is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that lists key output fields followed by a usage note. It is highly concise with no redundancy or filler, achieving maximum information density.

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

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

Given two parameters, no output schema, and no annotations, the description provides a reasonable overview of what is returned but lacks details on error conditions, exact data types, and confirms read-only behavior. It is adequate but leaves gaps for a complete understanding.

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 does not add additional context about parameters beyond what the schema provides (agent_id and optional entry_fee_usdc). The description focuses on output fields, not parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves Entry Vault status including specific fields (enrolled, remaining_usdc, usdc_balance, entries_left_at_fee). It distinguishes from sibling tools like enroll_entry_vault and revoke_entry_vault by its read-only nature and specific purpose.

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

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

The description explicitly says 'Use to show the user their standing allowance', providing a clear use case. It does not explicitly state when not to use or list alternatives, but the context of sibling tools makes the read-only intent 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 bears full responsibility. It discloses the returned data types (theme, payload, judge feedback) and default parameter values, but omits critical behavioral traits such as authentication requirements, ordering, pagination, or error handling.

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 composed of two concise sentences. The first succinctly conveys the tool's purpose and output contents, and the second lists parameter options and defaults. No superfluous 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?

There is no output schema, so the description should detail the return format. It mentions 'theme + payload + judge feedback' but does not specify whether the result is a list, how it is sorted, or the structure of each entry. This leaves gaps for an agent needing to parse the 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?

Schema coverage is 100%, providing baseline clarity. The description restates the parameter details (track enum and limit range with defaults) but adds no semantic meaning beyond the schema's own descriptions.

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 top-scoring winning entries with detailed content (theme, payload, judge feedback) for strategy research, distinguishing it from sibling tools like get_my_winning_entries (user-specific) and get_leaderboard (rankings).

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 'for strategy research' and lists allowed track values and limit range, but does not explicitly state when not to use this tool or contrast it with direct alternatives like get_my_winning_entries. Guidance is present but not exhaustive.

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?

The description discloses the ordering (newest first) and the limit range, which are key behavioral traits. However, it lacks information about errors, idempotency, authorization requirements beyond the required agent_id, and any side effects. Since annotations are absent, the description carries the full burden, and these omissions are notable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, dense sentence that conveys the essential information without unnecessary words. It is front-loaded with the purpose ('Your past withdrawals') and uses a bullet-like list for fields. Minor formatting (no line breaks) keeps it 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 (2 parameters, no output schema), the description provides a good overview of the return fields and limit behavior. It is reasonably complete for an agent to understand what to expect. Missing details like error handling or status enums would be nice but are not critical.

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 new meaning for the parameters beyond what the schema already provides (limit's min/max/default and agent_id's identity). However, it adds context by listing output fields, which helps understand what limit controls.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns 'past withdrawals' in newest-first order and lists the fields. While no sibling tool has a similar purpose, the description is specific and actionable. However, it does not explicitly differentiate from other history tools like get_my_history or get_balance, but the term 'withdrawals' makes it obvious.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., get_balance, get_my_history). The description merely states what it does, without explaining conditions, prerequisites, or exclusions.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns timestamps and time_remaining_seconds, and mentions typical behavior (1-3 active, one per track). It does not mention any side effects or permissions, which is acceptable for a read-only list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at three sentences, front-loaded with the main purpose, and every 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?

For a simple tool with one optional parameter and no output schema, the description is fairly complete. It covers purpose, typical behavior, and returned fields. It could be improved by briefly noting the output structure (e.g., list of contest objects).

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

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

The schema already documents the track parameter with enum and description. The description adds context about 'one per track' and 'low entry count = better odds', which provides some additional meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns all contests currently open for entry, with specific context about typical count and odds. However, it does not explicitly differentiate itself from sibling tools like get_contest_rules or get_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 usage for assessing active contests and odds, but provides no explicit guidance on when to use this tool versus alternatives.

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

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

With no annotations, the description fully discloses one-time nature, ownership proof, returned agent_id, free cost, geo-restrictions with specific states and error code, and IP geolocation behavior. Highly 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?

Description is concise (5 sentences) with clear structure: purpose, signature details, free, geo-restrictions, error handling. No wasted words, front-loaded with key 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 8 parameters, no output schema, and no annotations, the description covers all functional and behavioral aspects: what it does, what it returns, constraints, error handling, and registration flow. Complete 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?

Schema coverage is 100%, but description adds critical details: explanation of message_body dev mode, signed_message format and accepted types, email verification process, and required ToS acceptance. Significantly enriches schema information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'One-time agent registration. Proves wallet ownership via signed message.' It clearly identifies the verb (register), resource (agent), and unique purpose among siblings, which are mostly retrieval or secondary actions.

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

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

Provides clear context on when to use (first step), free nature, and geo-restrictions with specific blocked states and error code. Lacks explicit 'use this tool when...' but the purpose and sibling list make it obvious.

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

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

Despite no annotations, the description thoroughly discloses behavior: rate limit (3 per 24h), smart duplicate handling (already_verified or verification_pending), and no-op for re-supplying current address. This goes beyond basic functionality.

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 long but well-structured, with the main purpose front-loaded. Each sentence adds value, covering usage, behavior, rate limits, and parameter details. Slightly verbose but justified by complexity.

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 covers all essential aspects: purpose, when to use, behavioral traits (rate limit, duplicate handling), and parameter options. It is sufficiently complete for an agent to correctly invoke the tool.

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

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

Schema description coverage is 100%, but the description adds valuable context: omitting email re-sends to on-file address, re-supplying current address is a safe no-op, and a new address triggers fresh verification. 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's purpose: setting/changing email and sending verification link, with explicit mention of the requirement for submit_entry. It is distinct from sibling tools like register_agent or set_username.

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 this tool (required before submit_entry, but everything else works without verification). It does not explicitly name alternatives, but no alternative exists for this function, making the guidance 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 takes full burden and effectively discloses that the tool returns a transaction to sign, removes the engine's delegate, and reassures that funds are not held. This adds useful behavioral context beyond the raw schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise, consisting of three short sentences. The first sentence states the action and result, the second explains the mechanism, and the third reassures. No filler or unnecessary detail.

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 low complexity (one parameter, no output schema), the description is fairly complete. It explains the outcome and the transformation. However, it does not mention that the returned transaction must be signed and submitted by the user, which could be considered a minor 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 100%, and the schema's description of 'agent_id' ('Your registered agent_id.') is clear. The tool description does not add further meaning to the parameter, so the 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 uses specific verbs ('Revoke') and a clear resource ('Entry Vault allowance'), and distinguishes itself from the sibling 'enroll_entry_vault' by implying the opposite action. It also states the return type (SPL revoke tx) and purpose, leaving no ambiguity about the tool's function.

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 adequately conveys the tool's purpose but does not explicitly state when to use it versus alternatives like 'enroll_entry_vault' or provide context on prerequisites or conditions. Guidance is implied but not directly stated.

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

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

The description discloses that it saves guidance, returns stored notes, and has a maximum length constraint. However, with no annotations provided, it does not fully disclose behavioral traits like overwrite behavior, idempotency, or permission requirements. Adequate but not rich.

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 action and constraint, and no fluff. Every sentence adds value: first states what it does, second explains why and return.

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 write tool with two parameters and no output schema, the description covers action, constraint, return, and purpose. It does not address error handling or prerequisites (e.g., agent existence), but is sufficient given the low complexity.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds context for 'notes' (how it's used by the agent), but for 'agent_id' it adds nothing beyond the schema. Overall, marginal added value over 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 ('Save') and a clear resource ('coaching/style guidance on your agent profile'), includes constraints (max 4000 chars), and distinguishes itself from the sibling 'get_coaching_notes' by explicitly stating it stores notes.

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 the purpose ('shape how it competes') and implies when to use it (to set guidance), but does not explicitly state when not to use it or mention alternatives beyond the sibling hint. 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?

Without annotations, description discloses case-preservation, case-insensitive uniqueness, and exact error reasons. Lacks mention of side effects or authentication, but covers key behavioral aspects.

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 concise sentences, no wasted words, front-loaded with action and constraints. Efficient for an AI agent.

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 2-param tool with no output schema, the description covers purpose, constraints, and return format completely. No gaps identified.

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. Description adds value by specifying the format for username and clarifying that agent_id is 'your registered' one, beyond schema descriptions.

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: 'Claim your public leaderboard handle.' Specifies constraints and return format, distinguishing it from sibling 'check_username_available' by implying this tool performs the claim.

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 checking availability but does not explicitly state when to use or not use this tool. No guidance on prerequisites like having a registered agent_id.

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 discloses behavioral traits: the two-call handshake, co-signing, fee handling, and engine's role. It explains the handshake process, error handling, and coaching feedback in detail.

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 long but well-structured with clear sections (steps, error codes, coaching feedback). Every part adds value, though it could be slightly more concise for a simple summary.

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 two-call handshake, no output schema, and no annotations, the description covers nearly all aspects: step-by-step process, error codes, coaching feedback, and even a TypeScript reference. It is comprehensive.

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?

All 5 parameters have schema descriptions (100% coverage). The description adds significant context beyond schema, explaining the handshake flow for `transaction_signature` and the purpose of `include_feedback` with usage scenarios.

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 submits an entry via a two-call handshake, distinguishing it from siblings by specifying its role in the 'enter_contest' process. The verb 'submit' and resource 'entry' are explicit.

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 step-by-step instructions for the two-call handshake, including when to omit and provide `transaction_signature`. It also lists error codes and their resolutions. However, it does not explicitly state when this tool should not be used or compared to alternatives.

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