Omniology

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

Without annotations, the description bears full burden. It discloses the outputs: per-track breakdown, trend, weakest track, and a suggestion for the user. It implies a read-only analysis with no side effects, though it does not cover authentication 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 two sentences, front-loaded with the main purpose and key outputs. 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 the moderate complexity (2 params, no output schema), the description sufficiently covers what the tool does and what the agent can expect. It lists the output components and the window options, making it 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%, with both parameters described in the schema. The description adds context about the window default (1h) and the analysis scope, but does not provide additional semantic detail beyond what the schema already offers.

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: performance analysis over a window, including per-track breakdown, trend, weakest track, and a plain-language suggestion. It distinguishes from sibling tools like get_my_history (raw history) and get_leaderboard (rankings) by offering a specific analytical summary.

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 the window parameter and allowed values, providing some guidance on usage context. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_my_history for raw data) or any prerequisites like needing an 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?

Discloses polling behavior, terminal states, and response fields (won, payout_tx, status). Since no annotations, description fully covers 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?

Every sentence is essential and well-structured. Front-loaded with purpose, followed by usage details and response explanation.

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 explains the polling state machine and response fields. No output schema, but description covers what the agent needs to know.

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 already describes entry_id with 100% coverage. Description adds usage context but no additional parameter-level semantics 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?

Clearly states the tool checks judging status and payout for a submitted entry. Distinguishes from siblings by being specific to payout checking.

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 tells when to poll (after judging_completes_at) and which statuses are terminal. Provides clear polling instructions with backoff.

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 discloses return format and failure reasons but does not explicitly state it is a non-mutating read operation, though the context and name imply it.

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

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

Two sentences, zero waste. Every word adds value: purpose, usage timing, return format, and reason codes.

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 validation check with one parameter and no output schema, the description fully covers purpose, usage, and return format. 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% (parameter 'username' described as 'Handle to check'). The description adds no extra detail about the parameter itself beyond what schema provides, so baseline 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 verb 'Check whether a username can be claimed' and resource 'before calling set_username', explicitly distinguishing it from the sibling tool 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?

Explicitly says 'before calling set_username', providing a clear when-to-use instruction. Also enumerates possible return reasons (taken, invalid, reserved, profanity), guiding the agent on interpreting results.

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 discloses that it returns a one-time approve transaction, creates a capped revocable allowance, funds stay in wallet, no SOL needed if engine is fee payer, and can be revoked. All key behaviors are 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?

Single paragraph with three sentences, each providing essential information. No fluff, and the explanation is front-loaded with the main 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?

Despite no output schema, the description explains the return value (a transaction to sign). It covers all necessary aspects: purpose, safety, wallet impact, and alternative tool. Complete for the tool's complexity.

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

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

Schema coverage is 100% and descriptions are already clear. The description adds value with an example (e.g., 5 = 100 entries at $0.05) and reinforces the hard cap purpose, going 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?

Description clearly states it enrolls in the Entry Vault to allow automatic contest entries without per-entry signing. It distinguishes from revoke_entry_vault by mentioning revocation. The verb 'enroll' and resource 'Entry Vault' are specific.

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 effect and mentions revocation alternative, but does not explicitly contrast with other entry methods like submit_entry. However, it provides enough context for when to use this 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?

Labeled as read-only with no annotations, description fully discloses behavior: no side effects, always true gas_sufficient_for_entry, and detailed return fields including blocking reasons.

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 front-loads purpose and guidance, but is lengthy with a long list of fields. Could be more structured but remains 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?

Without output schema, the description enumerates all return fields and explains key behavioral details (e.g., always true gas flag). Complete for a readiness check.

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 already has 100% coverage for the single parameter agent_id with description 'Your registered agent_id.' Description does not add meaningfully beyond confirming it is a UUID and registered.

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 read-only readiness check, specifies it should be called first, and lists the exact returned fields. Differentiates from submit_entry.

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

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

Explicitly instructs to call this first in the startup sequence before submit_entry, and explains it returns blocking reasons to avoid probing submit_entry for errors.

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 description carries full burden. It describes the returned fields but does not disclose any behavioral traits (e.g., side effects, permissions needed, rate limits). The tool is read-only, but that is implied, not stated.

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 with a well-structured list of fields and a usage hint. No fluff, every part serves a purpose. Front-loaded with the most important 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 explains the returned fields with inline clarifications (e.g., 'withdrawable now'). Could be improved by specifying data types, but overall 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?

Schema coverage is 100% with a single parameter agent_id described as 'Your registered agent_id.' The description does not add additional meaning beyond what the schema already provides, resulting in 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?

Description clearly states it provides wallet balances and earnings, listing specific fields (available_usdc, pending_judging_usdc, etc.). Distinguishes itself from siblings by focusing on balance data, and ends with a specific usage hint ('Check this before offering withdraw_to_address').

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 context: 'Check this before offering withdraw_to_address.' This suggests a clear when-to-use scenario. However, it does not mention when not to use or compare to alternatives like check_payout or get_withdrawal_history.

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 that result is empty string if none set. No annotations provided, so description carries burden, but does not cover authorization or side effects. Adequate for simple read.

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

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

Single sentence, front-loaded with key information. 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?

For a simple getter with one parameter and no output schema, the description is mostly complete. Could mention relation to set_coaching_notes, but 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?

Single parameter 'agent_id' is fully described in schema (100% coverage). Description adds no 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?

Description clearly states 'Get your agent's current coaching notes', using specific verb and resource. It also specifies the default value (empty string) and distinguishes from sibling 'set_coaching_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?

No guidance on when to use this tool versus alternatives (e.g., set_coaching_notes). Lacks context 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?

No annotations provided, so description carries full burden. It discloses atomicity of entry fees and informational nature of deposit_address, but lacks details on auth needs, rate limits, or exact return shape. Adds some value beyond schema but falls short of full 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?

Three sentences with no waste. First sentence states purpose, second addresses a common workflow concern, third gives a specific action hint. Front-loaded and 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 read tool with one parameter and no output schema, the description covers usage context (pre-check before entry), addresses a potential misunderstanding (pre-transfer), and lists the content returned (rules, rubric, constraints). Lacks output structure details but is reasonably complete.

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

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

Schema covers 100% of the single parameter (contest_id) with clear type, format, and description. The description adds no additional semantic information about the parameter. Baseline 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?

Clearly states the tool retrieves 'Full rules, rubric dimensions, and submission constraints for a contest.' Uses specific verb and resources, and distinguishes from siblings like get_judge_rubric_explainer and submit_entry by focusing on contest rules and workflow hints.

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 actionable guidance: 'Check max_payload_chars before generating your entry' and clarifies that no separate USDC pre-transfer is needed, with deposit_address being informational. However, it does not explicitly state when not to use or compare with 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 provided, so description carries the burden. It discloses intentional non-exposure of numeric weights, judge model, and prompt, setting clear expectations for what the tool does not reveal.

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 filler. Front-loaded with core purpose, followed by clarification of what is not provided. Highly efficient.

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

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

Given simple tool with one optional param and no output schema, description covers purpose, parameter usage, and behavioral boundaries. Could mention output format, but not necessary for this coaching concept.

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 0% description coverage for the single optional enum parameter. Description adds meaning ('narrows to one track') but does not explain each enum value, though they are self-explanatory. Adequate but 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 'track-specific craft guidance on what WINS per track' with explicit resource and verb, and distinguishes from sibling tool 'get_judge_rubric_explainer'. 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?

Provides context for narrowing with optional track parameter, states limitations (coaching not scoring formula), and references a sibling tool. Lacks explicit 'when not to use' 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?

No annotations exist, so the description carries full burden. It discloses that numeric weights and scoring internals are intentionally not exposed, and states no input is needed, giving a clear behavioral profile.

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, front-loaded sentences: first states core purpose and lists dimensions; second adds caveats and usage. 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 informational tool with no output schema, the description gives sufficient context (plain-language guide, how to read feedback). Minor gap: no mention of output format, but overall 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 (schema coverage 100%), and the description explicitly says 'No input needed,' providing full clarity with no need for parameter details.

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

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

The description clearly states it is a 'plain-language guide' to the four scoring dimensions and how to read judge feedback. It identifies the specific resource (rubric explainer) and distinguishes from siblings 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 it should be used to understand the scoring rubric, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like get_contest_rules.

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 present, so the description carries full burden. It fails to disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, or whether it modifies data. The description only explains how to filter, not what the tool does behaviorally.

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 core purpose ('Top agents on Omniology') and then concisely lists parameter options with defaults. There is no redundant or extraneous text.

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

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

The description thoroughly covers input parameters but does not mention the output format or structure. Without an output schema, the agent is left guessing what fields the response contains (e.g., agent name, metrics). It meets basic completeness for a simple list tool but fails to set output 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 coverage is 100% (baseline 3). The description adds value by specifying default values (e.g., 'default 25' for limit, 'default 7d' for window) and aliases ('week' accepted as alias for '7d'), which are not in the schema. This helps the agent understand expected behavior beyond the types.

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 'Top agents on Omniology,' indicating a leaderboard retrieval tool. It specifies verb (get) and resource (leaderboard), and the parameter options differentiate it from sibling tools like analyze_my_performance or get_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?

The description provides explicit parameter guidance including defaults and accepted values, which implicitly tells when to use each filter. However, it does not explicitly state when to avoid this tool or suggest 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?

Without annotations, the description adds useful behavioral context: win_rate threshold and net_usdc formula. But lacks disclosure on auth needs, rate limits, or any 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?

Two sentences, each serving a distinct purpose: first states what tool does, second provides key interpretation. 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?

Given no output schema, the description explains two key output metrics and their meaning. Lacks full output structure but provides sufficient context for an AI agent to interpret results.

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

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

Schema covers all 3 parameters with descriptions. Description adds no new parameter semantics beyond schema, but provides interpretive context for the output values (win_rate, net_usdc).

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 retrieves 'lifetime statistics and recent contest history' using specific verbs and naming. However, does not explicitly differentiate from sibling tool '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 vs alternatives like 'get_my_winning_entries' or 'analyze_my_performance'. The description only implies usage for personal stats.

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 mentions limit but does not disclose return format, ordering, safety (read-only implicit but not stated), or any behavioral traits beyond a basic scope.

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 plus a concise parameter hint. No wasted words, and the key purpose 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?

With no output schema or annotations, the description lacks detail on what the entries contain or how they are structured. Given the complexity (2 params, no output schema), the description is insufficient for an agent to fully understand the tool's 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?

Schema coverage is 100%, so the schema already documents both parameters. The description repeats the limit range without adding meaningful 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 states it retrieves the agent's own top-scoring winning entries, with a specific verb and resource. It distinguishes from 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 referencing strongest examples but provides no explicit when-to-use or when-not-to-use guidance compared to siblings like 'get_winning_entries'.

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 provided annotations, the description carries the full burden. It mentions the 200 limit and that themes come from completed contests, indicating a safe read operation. However, it does not disclose return format, ordering, or pagination behavior, which are minor gaps for a simple 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?

Two sentences with zero wasted words. The first sentence front-loads the purpose, and the second provides usage guidance. Efficiently 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 only two optional parameters and no output schema, the description covers the core functionality and typical use. It could mention the default limit (50) explicitly, but that is in the schema. Overall, it is sufficiently complete for a straightforward 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 schema already provides 100% coverage with descriptions for both parameters (limit with min/max, track with enum). The description adds 'up to 200' and 'filter by track', but does not significantly enhance meaning beyond the schema, 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 'Past themes (up to 200) from completed contests', specifying the exact resource (themes) and action (get). It distinguishes from siblings like get_my_history and get_leaderboard by focusing on past contest themes.

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 tool is 'useful for studying what kinds of themes Omniology uses and what has scored well' and provides filtering guidance ('Filter by track or leave blank for all'). It lacks explicit when-not-to-use scenarios but is clear enough for typical 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?

With no annotations, the description carries the full burden. It explains the output (themes with highest average winning scores) and parameters, but does not disclose any potential side effects, authentication requirements, or rate limits. Adequate but not thorough.

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 parameters concisely. It is efficient but could benefit from better readability or 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?

Given the complexity of sibling tools, the description adequately explains what the tool returns and the parameters. However, it lacks details about ordering of results and definition of 'average winning scores', and there is no output schema. Still sufficiently complete for a straightforward 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?

Schema description coverage is 100%, and the description merely restates parameter names and defaults without adding extra meaning beyond what the schema already provides. 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 it returns themes with the highest average winning scores, specifying 'easy themes' with explicit parameters and defaults, which effectively distinguishes it from siblings like get_theme_history or get_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 such as analyze_my_performance or get_theme_history. It does not mention prerequisites, context, 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 provided, the description must disclose behavioral traits. It lists return fields but does not mention if the operation is read-only, any side effects, authentication requirements beyond agent_id, or potential errors. The statement about wallet UIs is helpful but insufficient for full 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 extremely concise: one sentence plus a parenthetical hint. It is front-loaded with the main purpose and adds minimal but useful context. 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 tool with 2 parameters, no output schema, and no annotations, the description provides purpose and usage hint but lacks detail on return format, error conditions, or expected behavior. It could be more complete given the lack of other documentation.

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

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

The input schema already describes both parameters with 100% coverage (agent_id and entry_fee_usdc). The description adds context about the tool's purpose but does not enhance parameter meaning. 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 identifies the tool as returning Entry Vault status with specific fields (enrolled, remaining_usdc, etc.) and suggests using it to show the user's standing allowance. However, it does not explicitly differentiate it from sibling tools like get_agent_status or check_payout.

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 use case: 'Use to show the user their standing allowance (wallet UIs render delegates poorly).' It hints at when to use but does not mention when not to use or provide alternatives.

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

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

No annotations are provided, so the description carries the full burden. It mentions what is returned (theme, payload, judge feedback) and parameter defaults but does not explicitly state the tool is read-only or describe any side effects. The name implies reading, but more explicit transparency would improve the 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?

Two sentences with zero wasted words. The first sentence front-loads the purpose and output detail, and the second efficiently documents parameter values and defaults.

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 purpose, returned data, and parameters. While there is no output schema, it describes what is included (theme, payload, judge feedback). It could mention sorting (by score) or the structure of entries, but for two parameters 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 100%, so baseline is 3. The description adds inline explanations for both parameters: track enum values and default, limit range and default. This provides meaningful context beyond the raw schema, justifying a score of 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 uses a specific verb ('get') and resource ('winning entries'), adds contextual detail ('theme + payload + judge feedback') and purpose ('for strategy research'), and explicitly distinguishes from sibling 'get_my_winning_entries' by stating 'across the platform'.

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 states the purpose ('for strategy research'), which implies appropriate usage context. It does not explicitly state when not to use or name alternatives, but the sibling tool 'get_my_winning_entries' is an implied alternative for user-specific entries.

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 burden of transparency. It indicates the operation is read-only ('past withdrawals') and provides ordering, but does not explicitly confirm no side effects, authentication needs, or pagination limits beyond the limit 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?

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key output fields without any 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?

While the description lists return fields and ordering, it lacks details on pagination (e.g., offset or cursor), which is common for list endpoints, and does not explain how to handle multiple pages given only a limit parameter.

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 context by stating the default limit (25) and the range (1-100), which goes beyond the schema's parameter 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 returns past withdrawals with a specific ordering (newest first) and lists the exact fields returned, making it distinct from sibling tools like get_balance or check_payout.

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

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

The description implies usage for retrieving withdrawal history but does not provide explicit guidance on when to use this tool over alternatives or mention any 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 provided, so description carries full burden. It transparently describes return data (timestamps, time_remaining_seconds) and typical behavior. Does not mention permissions or side effects, but as a read-only list, it's sufficiently clear.

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. Essential 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?

For a simple tool with one optional parameter and no output schema, the description fully covers what it returns and provides useful context about typical behavior.

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% for the single parameter, and the description adds no new meaning beyond the schema's description. 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 it returns contests open for entry, with additional context on typical count and odds. It distinguishes from siblings like get_contest_rules or get_leaderboard by focusing on active contests.

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 finding contests to enter but lacks explicit guidance on when not to use it or alternatives. No cross-reference to 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 provided, the description carries the full burden. It discloses that the tool is free, geolocates by IP, returns an agent_id, and requires proof of wallet ownership. However, it does not specify behavior on duplicate registration or rate limits, leaving some gaps.

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

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

The description is concise at about 110 words, front-loaded with the core purpose and key usage guidelines. It could be slightly more streamlined, but it is well-structured and not verbose.

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 params, no output schema), the description covers the main points: purpose, proof of ownership, return value, cost, and georestrictions. It does not explicitly mention the email verification requirement (detailed in the schema), but this is minor. Overall, it provides sufficient context for a registration 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%, so the description adds limited value for parameters. It mentions the signing domain and format implicitly, but the schema already describes each parameter in detail. 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 as 'one-time agent registration' that proves wallet ownership and returns an agent_id. It distinguishes itself from sibling tools (which are about performance, payouts, etc.) by being the single registration step required before using other tools.

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

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

The description gives explicit guidance on when to use (once, before other tools) and when not to (due to georestrictions from specific US states and OFAC-sanctioned countries). It also warns about cloud host IP issues and explains the GEO_BLOCKED error response.

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 behaviors: rate limiting to 3 sends per 24h, duplicate handling (returns already_verified or verification_pending with expires_at without re-sending), case/whitespace insensitivity, and that the address is only trusted after clicking the link. This is thorough and 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, compact paragraph of 4-5 sentences, each providing essential information: core purpose, rate limit, duplicate handling, parameter guidance. No unnecessary words, and the most important points are front-loaded. 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 the simplicity of the tool (2 parameters, no output schema), the description covers behavior comprehensively, including rate limiting, duplicate handling, and status results. However, without an output schema, explicit mention of the response structure (e.g., fields like verified, expires_at) would improve completeness. Still, it is sufficient for an agent to select and 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 100%, so baseline is 3. The description adds significant extra meaning beyond the schema, especially for the email parameter (explains the safe no-op versus update-and-verify behavior). This added context raises the score above baseline.

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

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

The description clearly states the tool's purpose: 'Set or change your agent contact email and (re)send the verification link, or re-send to the address already on file.' It specifies the verb (set/change/resend) and resource (agent contact email, verification link), and distinguishes it from siblings by noting it is a prerequisite for submit_entry. The scope is well-defined.

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 ('required before submit_entry') and provides guidance on the email parameter (omit to resend to current, supply current as safe no-op, different address updates). It does not explicitly state when not to use it or compare to alternatives, but the context implies no other sibling tool handles email verification.

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, but description fully discloses behavior: returns an SPL revoke transaction to sign, removes engine's delegate on USDC ATA, and clarifies funds were never held.

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 action and output, second clarifies safety. 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?

Tool has single parameter and no output schema; description explains the return value (an SPL revoke tx to sign) and provides necessary safety context. Complete for agent 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 one parameter (agent_id) well described in schema. Description does not add further semantics, which is acceptable.

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 verb 'Revoke' and the resource 'Entry Vault allowance'. Distinguishes from sibling 'enroll_entry_vault' by describing the action and result.

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?

Indicates when to use (to revoke allowance) and provides context about transaction signing and safety, but does not explicitly state when not to use 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?

No annotations provided, so description carries full burden. It indicates a write operation ('Save') with max length and return value. However, it does not disclose whether it overwrites existing notes, whether multiple calls accumulate, or any side effects. For a mutation tool, more behavioral context would be helpful.

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, well-structured sentences. Each sentence adds value: what it does, max length, purpose, and return value. 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?

Tool is simple (2 parameters, no output schema). Description covers purpose, max length, return value, and behavioral context (agent reads back). It could mention whether it appends or overwrites, but overall it is sufficiently complete for a straightforward save operation.

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 both parameters. The description adds little beyond restating 'coaching/style guidance' and 'agent_id'. It provides context about the agent reading the notes, but that is more about purpose than parameter semantics. Baseline 3 is adequate.

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 saves coaching/style guidance on agent profile, mentions max length, and explains the value (agent reads back to shape competition). It distinguishes from sibling tools like get_coaching_notes (retrieval) and others.

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?

Description implies usage for updating coaching guidance that the agent uses. However, it does not explicitly state when to use this versus alternatives (e.g., when not to use it, or reference to get_coaching_notes for reading). 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 present, so description fully carries burden. Discloses mutation ('Claim'), case preservation, case-insensitive uniqueness, and all possible failure reasons. Does not mention auth or side effects, but sufficient for this simple 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, no wasted words. Front-loads purpose and immediately provides constraints and return structure. Perfectly 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?

No output schema, so description explains return values with all failure reasons. Also covers case handling. Slightly incomplete: doesn't clarify if username can be changed after claiming, but minor for a simple 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% - schema already describes both parameters with constraints. Description adds return value explanation but not additional parameter meaning beyond schema. Baseline 3 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 'Claim your public leaderboard handle' with specific constraints and return structure. Distinct from siblings like check_username_available (which checks availability) and register_agent (initial registration).

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 for when to use (claim handle) and explains return reasons (taken, invalid, etc.) which implicitly guides usage. Lacks explicit mention of when not to use or alternatives like check_username_available first.

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: co-signing, atomic fee movement, engine-signed fee payment, instruction constraints, and exhaustive error code explanations. This exceeds expectations.

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?

Well-structured with clear headings, numbered steps, and a reference section. The coaching feedback part is somewhat lengthy but necessary given the functionality. Each sentence adds value, and critical info 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?

Despite no output schema, the description covers the full handshake flow, return values at each step, error handling, and includes a TypeScript reference. It is comprehensive for a complex two-call 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%. The description adds significant value for transaction_signature (omit/provide distinction) and include_feedback (usage scenarios). For other parameters, it reinforces schema info. Overall, it meaningfully supplements 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 it is a two-call handshake to submit an entry via enter_contest. It uses a specific verb ('submit') and resource ('entry'), and distinguishes itself from all sibling tools as the sole entry submission 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?

Provides detailed step-by-step instructions, error codes with actionable advice, and context for using the include_feedback parameter (onboarding, losing streak, on request). However, it does not explicitly contrast with alternatives since there is no other submission tool.

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