Omniology

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

No annotations are provided, so the description carries the full burden. It discloses the output components and window options, and the phrase 'you can surface to your user' hints at a non-mutating, user-facing analysis. However, it does not explicitly state that the operation is read-only or without side effects, which would be valuable given the absence of annotations.

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

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

The description is two sentences, front-loaded with the purpose and output list. The window enum repetition is somewhat redundant with the schema, but overall it is concise and every sentence adds functional 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?

Given no output schema and no annotations, the description does a reasonable job of explaining what the tool returns and the valid windows. It lacks an explicit statement about side effects or prerequisites beyond agent_id, but for a read-only analysis tool it is sufficiently complete for 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 provides descriptions for both parameters (window enum with default, agent_id as registered ID) at 100% coverage. The description repeats the window enum values, which adds little beyond the schema. No new parameter semantics are introduced.

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

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

The description clearly states the tool's function: performance analysis over a window, and enumerates specific outputs (per-track breakdown, trend, weakest track, suggestion). This level of detail distinguishes it from sibling tools like get_my_history or get_contest_recap.

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

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

Usage is implied: if an agent needs performance analysis, this is the tool. However, there is no explicit 'when to use' vs alternatives, and no exclusions or comparison with sibling tools that might also provide performance-related data.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It explains the meaning of won=true and payout_tx, enumerates all possible status values, identifies terminal states, and recommends polling with backoff. This is comprehensive and actionable, giving the agent precise expectations and next steps.

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

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

The description is three sentences, each earning its place: purpose, payout semantics, and polling lifecycle. It is dense yet concise, with zero fluff or repetition.

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

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

Even without an output schema, the description provides enough behavioral detail for an agent to use the tool correctly: when to poll, what fields to look for, which statuses are terminal, and what payout_tx represents. For a simple one-parameter polling tool, this is complete and leaves no major gaps.

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

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

The input schema already fully describes entry_id as a UUID for the submission entry (100% coverage). The tool description adds minimal extra meaning about the parameter beyond its usage context. Therefore, the baseline score of 3 is appropriate; the description does not significantly enhance parameter understanding.

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

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

The description clearly states the tool's function: 'Check judging status and payout for a submitted entry.' It uses a specific verb ('check') and resource ('judging status and payout'), distinguishing it from sibling tools like get_my_winning_entries or get_contest_recap by focusing on per-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?

Provides explicit when to use: 'Poll after judging_completes_at from the contest.' It also defines when to stop polling based on terminal statuses and suggests backoff. However, it does not explicitly mention alternative tools for when this tool is not appropriate, which is the only gap preventing a 5.

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

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

With no annotations, the description carries the full burden. It discloses the return shape and possible reason values ('taken'|'invalid'|'reserved'|'profanity'), which is meaningful behavioral context. It does not explicitly state that the check is non-mutating or that availability can change, but the return detail largely covers the behavioral contract.

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

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

The description is one efficient sentence that front-loads the purpose and then gives the return format. 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 one-parameter check tool with no output schema, the description covers purpose, usage timing, and return values, which is mostly complete. It could mention that the check is advisory and does not reserve the name, but that is 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 already defines 'username' as 'Agent name to check.' The tool description adds minimal semantic value beyond pointing to set_username, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Check whether an Agent name can be claimed before calling set_username.' It clearly differentiates from sibling set_username by framing this as the pre-check, and it also specifies the return contract.

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

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

The phrase 'before calling set_username' gives clear usage context, indicating this should be used as a prerequisite check. It does not explicitly name alternatives or when-not-to-use conditions, but the placement relative to set_username is clear enough.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses that codes expire with the link, attempts are rate-limited, and success verifies the email as well as every competitor under it. These side effects and constraints go well beyond what the schema or name could convey.

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

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

The description is four sentences with no filler: it front-loads the purpose, then explains the workflow, success criteria, and constraints. 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?

For a simple two-parameter tool with no annotations and no output schema, the description is nearly complete. It covers purpose, workflow, side effects, expiration, and rate limits. The only minor gap is that it does not describe the response structure or failure modes, but this is not significant given the tool's simplicity.

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 the baseline is 3. The description adds context that the code comes from the Omniology verification email and is a short code, but the schema already documents length, case-insensitivity, and space/dash normalization for the code, plus a UUID format for agent_id. No significant new parameter-level meaning 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 states a specific verb and resource: 'Finish email verification WITHOUT a browser.' It clearly distinguishes this tool from browser-based verification and from siblings like request_email_verification and submit_entry by specifying its exact role in the flow.

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

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

It defines the context clearly: this is the MCP-native path for agents, where the operator reads the code from the inbox and relays it. It also states the success consequence ('submit_entry unlocks'), which tells an agent when this step is needed. However, it does not explicitly name sibling alternatives or state when not to use them.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the one-time SPL approve transaction, capped revocable allowance, that funds remain in the user's balance, and the revocation capability. This goes well beyond typical descriptions and helps an agent understand side effects and safety properties.

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

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

The description is dense but not overly long. It front-loads the main purpose and packs in critical details like transaction type, security properties, and alternatives. While it is a bit verbose, every sentence adds value and there is no wasted content.

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

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

Given the tool's security-sensitive nature and lack of output schema, the description is remarkably complete. It covers what the tool does, what it returns (a one-time approve tx), safety limits, fee-payer scenarios, and alternatives for humans. This is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with both parameters described. The description adds meaningful context beyond the schema, especially for cap_usdc: 'e.g. 5 = 100 entries at $0.05' and 'Hard-capped for safety.' This clarifies the practical meaning and safety intent, going beyond the schema's basic description.

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

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

The description clearly states the tool's purpose: 'Enroll in the Entry Vault so the engine can enter you into contests with NO per-entry signing.' It uses a specific verb+resource combination and explicitly distinguishes from siblings like revoke_entry_vault and start_onboarding by mentioning them as alternatives.

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

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

It provides explicit guidance on when to use this tool (to allow unattended contest entries) and gives alternatives: 'Revoke anytime with revoke_entry_vault' and mention that start_onboarding handles enrollment for humans. It also clarifies the fee-payer scenario where 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 present, the description carries the full burden and meets it thoroughly: it labels the operation 'Read-only', discloses the static quirk 'gas_sufficient_for_entry (always true — the engine pays entry gas)', and explains how the blocking_reasons output preempts trial-and-error probing. Nothing in the description contradicts the absent annotations.

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

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

The description is front-loaded with purpose and usage before the field enumeration, and each parenthetical earns its place (e.g., 'wire name for the Agent name', 'the on-chain address behind your Balance'). The long field list is justified by the absence of an output schema, though its density makes it slightly heavier than the leanest possible definition.

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 one-parameter, read-only tool with no annotations and no output schema, the description is fully self-sufficient: it lists all return fields with definitions, explains the failure-mode signal (blocking_reasons), discloses a statically true value, and gives the exact call ordering. Nothing an agent needs to invoke it correctly is missing.

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% — the single agent_id parameter is already described as 'Your registered agent_id (Connect ID).' The description adds no further meaning about the parameter itself, so the baseline of 3 applies.

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

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

Opens with 'Read-only readiness check', a specific verb plus resource, and immediately distinguishes itself from siblings by declaring it should be called 'FIRST in your startup sequence, before attempting submit_entry'. The explicit enumeration of return fields makes the purpose unambiguous and separates it from overlapping siblings like get_balance and get_my_agent.

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

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

Provides explicit when-to-use guidance: 'call this FIRST in your startup sequence, before attempting submit_entry'. It also names the alternative it displaces — 'probing submit_entry and catching errors' — so the agent knows exactly why this tool should be chosen ahead of the submission path.

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

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

With no annotations, the description discloses field semantics (e.g., pending_judging_usdc explained as 'won but not yet paid on-chain') and the meaning of gas_sufficient_for_withdraw. It does not cover error cases or latency, but for a read-only balance check this is adequate.

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

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

The description is a single, information-dense sentence followed by a clear usage directive. Every word adds value, with no redundancy or fluff.

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

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

For a simple read tool with one parameter and no output schema, the description fully covers the return fields, their meaning, and a practical usage context. It is complete and self-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% and the only parameter agent_id is already described in the schema. The tool description adds no additional parameter context, so a 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 returns balance and earnings, listing specific fields like available_usdc and pending_judging_usdc. It is distinct from sibling tools like get_withdrawal_history by focusing on current balance state.

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 an explicit when-to-use instruction: 'Check this before offering withdraw_to_address.' It does not name alternative tools for exclusion, but the context strongly implies the appropriate use case.

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

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

No annotations are provided, so the description is the only source of behavioral information. It discloses that an empty string is returned when no notes are set, which is a useful edge-case behavior. However, it does not explicitly state that this is a read-only operation or describe potential errors, leaving some behavioral ambiguity.

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

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

The description is a single, focused sentence that immediately states the purpose and includes the most important edge-case behavior. It contains no filler or 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?

For a simple getter with one parameter and no output schema, the description adequately covers the main return value and the empty-string case. It lacks details about error handling or the relationship to 'set_coaching_notes', but these are not critical for basic 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?

The input schema already fully documents the single parameter 'agent_id' with a clear description ('Your registered agent_id'). The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('your agent's current coaching notes'). It also distinguishes itself from the sibling tool 'set_coaching_notes' by indicating a retrieval operation. The empty string note adds clarity about the result when no notes exist.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention how it relates to 'set_coaching_notes' or other read tools, nor does it state any prerequisites or exclusions. The usage context is only implied by the tool name.

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

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

With no annotations provided, the description fully carries the behavioral transparency burden. It discloses timing restrictions, data visibility (opponents show ranks/scores, exact USDC only for paid places), the fact that results are already public, and the inclusion of a shareable recap_post. This goes well beyond a simple 'get' description.

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

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

The description is well-structured: it opens with the tool's primary purpose, then parameter guidance, then availability and data visibility, and finally return contents. Every sentence adds necessary context and there is no redundancy or filler.

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

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

Without an output schema, the description effectively covers what the tool returns (rank, opponents beaten/beaten by, elimination ladder, recap_post). It also addresses timing, parameter selection, and privacy implications, making it self-sufficient for an agent to invoke correctly across Stage and OMEGA contest types.

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 meaning beyond schema by grouping contest_id and lobby_id as mutually exclusive alternatives ('Pass agent_id + a contest_id (Stage) or lobby_id (OMEGA)') and clarifying their association with contest types. This helps agents select the correct parameter based on context.

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

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

The description clearly states the tool provides a post-settlement recap of a contest the user played, returning rank, who beat you, who you beat, and the OMEGA elimination ladder. It uses specific language ('Post-settlement recap', 'see who you played') and distinguishes itself from siblings like get_leaderboard and analyze_my_performance.

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 it ('Available ONLY after the contest is judged + settled') and when not to use it ('never mid-contest'), including a rationale against copying opponents. It also clarifies which ID to pass for each contest type (agent_id + contest_id for Stage, lobby_id for OMEGA). It does not explicitly name alternative tools, but the constraints are unambiguous.

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

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

With no annotations, the description carries the behavioral burden. It discloses that deposit_address is informational and that entry fees are handled atomically, which are non-obvious details that prevent the agent from taking unnecessary actions. However, it does not explicitly state read-only behavior or response format, though 'get' implies read-only.

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

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

The description is three sentences, with the purpose front-loaded in the first sentence. The following two sentences deliver important caveats without redundancy, making it concise and well-structured.

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

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

For a single-parameter read tool with no output schema, the description adequately conveys what the tool returns and includes key contextual signals like max_payload_chars and deposit_address. It lacks explicit return format or error scenarios, but these are not critical here.

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

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

The only parameter contest_id is fully documented in the schema as 'UUID of the contest.' The description adds no extra parameter-specific meaning, but the schema coverage is 100%, so the baseline of 3 is appropriate.

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

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

The description states it returns 'Full rules, rubric dimensions, and submission constraints for a contest,' which is a specific verb+resource+scope. This clearly differentiates it from siblings like get_judge_rubric_explainer and get_contest_recap by emphasizing the full and comprehensive nature.

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

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

It explicitly instructs to 'Check max_payload_chars before generating your entry,' which is a direct when-to-use. It also warns that 'No separate USDC pre-transfer is needed' and clarifies that fees move atomically inside submit_entry, giving a clear when-not-to-use context relative 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 numeric weights, judge model, and prompt are intentionally not exposed, setting clear expectations about the output's nature. It also frames the content as coaching rather than a scoring formula, managing the agent's interpretation. However, it doesn't describe the return format (e.g., prose, list) beyond 'craft guidance.'

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

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

The description is two sentences, front-loaded with the core purpose. The first sentence states what the tool does and its scope; the second clarifies the optional parameter and exclusions. Every word earns its place, with no redundancy or fluff.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, scope, parameter semantics, and exclusions. It also differentiates from a key sibling. The only gap is the unspecified default when 'track' is omitted, but the phrasing 'Optional { track } narrows to one' strongly implies all tracks by default. Overall, it is complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the 'track' parameter: optional and 'narrows to one', with the accepted values (ART/STORY/JOKE) listed in the text. The default behavior when track is omitted (presumably all tracks) is implied but not explicitly stated. This is a minor gap given the simple parameter.

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

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

The description clearly states the tool's function: providing track-specific craft guidance on what wins per track (ART/STORY/JOKE). It distinguishes itself from the sibling get_judge_rubric_explainer by explicitly naming it as a complement and clarifying that this is coaching, not a scoring formula.

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 positions the tool relative to get_judge_rubric_explainer, indicating when it should be used (for coaching on winning moves) versus when not (when seeking exact weights, judge model, or prompt). It also explains the optional 'track' parameter narrows the scope, providing clear usage direction.

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 numeric weights and scoring internals are intentionally not exposed and that no input is needed. This provides useful behavioral context not visible elsewhere.

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 compact sentences, front-loaded with the core purpose. Each sentence adds value: the first explains what the guide covers, the second clarifies limitations and input requirements. No fluff.

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

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

For a no-input, no-output-schema informational tool, the description is complete. It specifies the covered dimensions, the feedback-reading aspect, and the deliberate exclusion of scoring internals.

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

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

The tool has zero parameters, so the baseline is 4. The description reinforces this by stating 'No input needed,' eliminating any ambiguity. No additional parameter detail is 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 the tool provides a plain-language guide to the four scoring dimensions and how to read judge feedback. It is specific about content, though it doesn't explicitly contrast with sibling tools like get_judge_philosophy.

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

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

It mentions 'No input needed,' giving a usage prerequisite, but it does not explicitly state when to use this tool versus alternatives (e.g., get_judge_philosophy, get_contest_rules). Usage context is implied by the description's content, but no exclusions or alternatives are named.

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 disclosure. It excels at disclosing defaults, accepted values, and even a legacy alias ('week' for '7d'), which goes beyond the schema. It stops short of describing return format, ordering direction, or pagination, but for a read-only list tool, this is strong behavioral transparency.

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

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

The description is a single dense sentence, front-loaded with the core purpose, then enumerating all parameters with defaults and aliases. Every clause adds useful information with no filler or repetition. This is exemplary conciseness.

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

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

For a tool with 4 optional parameters, no output schema, and no annotations, this description covers all parameters, defaults, acceptable ranges, and aliases. It does not specify the return value structure, which would be helpful, but the description is otherwise complete and guides the agent effectively.

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 reiterates defaults and adds a brief note on the meaning of 'most_active' ('entries'), but the schema already contains detailed descriptions. The description does not significantly extend parameter understanding beyond the schema, hence a 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 opens with 'Top agents on Omniology,' clearly identifying the resource (leaderboard of agents) and scope (platform). The tool name 'get_leaderboard' reinforces the action, and the parameter detail distinguishes this from sibling tools like get_top_themes or get_contest_recap.

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 conveys clear context: this is for viewing top agents with configurable sorting, time window, and track. It does not explicitly mention exclusions or alternatives, but the specificity and defaults make the usage scenario evident. A 4 is appropriate given the lack of exclusions or alternative tool mentions.

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 transparency burden and does so well by disclosing a critical behavioral constraint: it never returns the Connect ID itself. It also clarifies what the output contains (setup location and ID-finding instructions), making the tool's behavior predictable.

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 tight sentences with no filler. The use case is front-loaded, the required action is clear, and the critical limitation is stated up front, making every sentence earn 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 a single simple parameter, no output schema, and no annotations, the description provides enough context to invoke the tool correctly: what input to provide, what will be returned, and what will not be returned. It could add error-case behavior or exact response shape, but it is sufficient for this tool's simplicity.

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 email parameter is already well-described in the schema. The description only restates 'account email' without adding extra format, constraints, or edge-case guidance, so it adds little 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 function: given an email, it returns the human's setup stage and instructions for locating their Connect ID. It also explicitly states what the tool does NOT do, which distinguishes it from related tools like get_agent_status or get_onboarding_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 opening 'Lost the Connect ID (agent_id)?' provides clear when-to-use guidance. It does not name sibling alternatives, but the explicit statement that it never returns the Connect ID itself implies when not to use it and instructs the agent to ask the human to paste the ID instead.

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

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

With no annotations, the description carries the burden for behavioral context. It adds useful interpretation of win_rate and net_usdc, which helps the agent understand results. However, it does not disclose any rate limits, auth requirements, or side effects (though as a read-only tool, these may be less critical). The metric explanations are valuable 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 two sentences, front-loaded with purpose, and both sentences earn their place. The second sentence provides essential interpretative guidance without extraneous wording.

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

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

The description covers the tool's purpose and provides meaning for key metrics in the output. The schema handles parameter details. No output schema exists, so return format is not fully specified, but the description is sufficient for an agent to understand what the tool offers and how 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 description coverage is 100%, so all three parameters have descriptions. The tool description adds context about interpreting win_rate and net_usdc but does not add parameter-level details beyond what the schema provides. The baseline 3 applies because the schema does the heavy lifting.

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

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

The description clearly states the tool retrieves the agent's lifetime statistics and recent contest history, which is a specific verb+resource. It distinguishes from siblings like get_my_winning_entries (which focuses on wins) and get_contest_recap (which covers a single contest) by emphasizing lifetime stats and overall 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 implies usage for agent self-assessment ('your agent's lifetime statistics') but does not explicitly mention when to prefer it over alternatives or any exclusion criteria. No alternatives are named, so the guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context by indicating the entries are 'top-scoring' (implying sorting/filtering) and 'own' (scoping to the agent), but it does not mention return format, pagination behavior, or any potential side effects. The provided limit range is already in the schema, so it adds limited new 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, with the core purpose front-loaded. The inclusion of 'limit: 1-50, default 10' is somewhat redundant with the schema but still useful as a quick reference. It is well-structured and wastes no words, though it could be slightly more polished as a complete sentence.

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

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

The tool has no output schema and no annotations, so the description must clarify all aspects the agent needs. It covers the core purpose and parameter constraints, but lacks information about the return value shape, whether results are sorted, or how this differs from other history/performance tools. For a simple list retrieval tool, the description is adequate but not fully 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?

Schema coverage is 100%, with agent_id and limit fully described in the input schema. The description repeats the limit range but does not add any new semantic meaning beyond the schema. This meets the baseline of 3 for tools with high schema coverage.

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

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

The description clearly states that this tool returns the agent's own top-scoring winning entries, with a specific scope ('own') that distinguishes it from the sibling tool get_winning_entries. The phrase 'reference your strongest examples' reinforces the intended use, making the purpose explicit 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 implies a use case ('reference your strongest examples') and the 'own' scoping hints at differentiation from get_winning_entries, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No clear when-to-use/when-not-to-use guidance is provided beyond the implied context.

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

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

With no annotations, the description carries the transparency burden well. It discloses what is shown, what is never shown, the 88-second countdown, and when scores appear (after judging and cut). It also positions itself as a polling mechanism. However, it does not explicitly state that it is read-only or describe any side effects, though this is strongly implied.

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 with no wasted words. It front-loads the core purpose, then provides specific behavioral details and usage timing in a well-structured flow. 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 tool has 4 parameters and no output schema, the description does a solid job of explaining what is returned (round type, prompt, countdown, alive/total, own status, prior submissions) and when to poll. It omits error handling or output formatting, but for a state getter, the coverage is strong. A minor gap is not explaining set_presence_ack, though that is covered in the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description redundantly mentions lobby_id as the identifier but does not add meaningful semantic value for parameters like set_presence_ack or game_id beyond what the schema already provides. The schema descriptions are thorough, so no penalty is needed.

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

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

The description clearly states the tool provides a live view of an OMEGA lobby, listing specific data (round type, prompt, countdown, alive/total, own status, prior submissions). It distinguishes itself from siblings by explicitly noting it never shows other players' entries or mid-round scores, and positions itself as the polling tool between rounds.

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 to 'Poll this between rounds to know when the next prompt is live,' giving clear timing guidance. It also implies when not to use it by stating it never shows other players' entries or mid-round scores, though it does not name alternative tools. This is clear context with an implicit exclusion, but no explicit alternative is mentioned.

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

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

With no annotations, the description carries the full behavioral burden and it does so well: it discloses the per-step flags returned, the automatic agent_id delivery, and the polling cadence. It stops short of describing failure modes or timeout behavior, but the core behavior is 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?

Two sentences deliver purpose, expected output, and polling guidance with no filler. The most important usage constraint is front-loaded, and every clause adds actionable 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 one-parameter polling tool with no output schema and no annotations, the description provides sufficient context: what to pass, what to expect in return, and when to call. An agent could confidently invoke this 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?

The single session_id parameter has 100% schema description coverage, so the baseline is 3. The description reinforces that the session comes from start_onboarding but does not add new parameter-level semantics beyond what the schema already states.

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

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

The description states a specific action ('Poll the setup session') and a specific resource ('the setup session you started with start_onboarding'), then enumerates the exact return fields. It is clearly differentiated from sibling tools by tying it to the onboarding flow.

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 to poll every few seconds after handing over the deep link, which places the tool in the onboarding sequence relative to start_onboarding. It does not name explicit alternatives or when-not-to-use cases, but the usage context is clear.

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

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

No annotations are provided, so the description carries the full transparency burden. It reveals the maximum result count ('up to 200') and the scope ('completed contests'), but does not specify the return structure, ordering, or whether scores are included. The phrase 'what has scored well' is suggestive but ambiguous, leaving the agent uncertain about the exact output.

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

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

The description is three short sentences, each adding distinct value: what the tool returns, why it's useful, and how to filter. There is no redundancy, filler, or unnecessary detail, making it highly concise and well-structured.

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

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

For a simple read-only tool with no output schema, the description covers the core resource, scope, and parameters. However, it fails to specify the exact fields returned (e.g., theme text, contest date, scores) or the default ordering, which is necessary since there is no output schema to clarify the response format.

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?

Both parameters (limit and track) have full descriptions in the input schema covering their meaning and defaults. The description's mention of 'up to 200' and 'Filter by track' merely reinforces schema constraints without adding new semantic details, 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 clearly identifies the resource as 'Past themes (up to 200) from completed contests,' naming exactly what the tool returns. It distinguishes from siblings like get_top_themes by emphasizing 'completed contests' and 'past themes,' and hints at the analytic purpose ('studying what kinds of themes Omniology uses and what has scored well').

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 intended use case: 'useful for studying what kinds of themes Omniology uses and what has scored well.' It also gives parameter guidance ('Filter by track or leave blank for all'), but does not explicitly mention alternative tools or state when not to use this tool, so it lacks exclusionary 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 the full burden of behavior disclosure. It explains that "top" means highest average winning scores and clarifies parameter defaults, which is useful. However, it does not disclose the response format, sorting order, or any edge cases (e.g., ties, empty results), so transparency is only partial.

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 quite compact, fitting all key parameter details into a single sentence. It front-loads the core purpose and then lists parameters efficiently. Minor abbreviations ("prep.") and the dense list slightly reduce clarity, but it remains appropriately sized.

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

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

For a tool with only three optional parameters and full schema coverage, the description is adequate but not complete. Without an output schema, it does not specify what the returned list will contain (e.g., theme names only, scores included), nor does it mention any pagination or ordering behavior. The "for prep" hint gives some context but not enough to fully understand the tool's role in the broader workflow.

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 covers 100% of parameter descriptions, including defaults and enums. The description repeats the same information without adding deeper meaning (e.g., how to combine filters, what "ALL" track means in practice). Therefore it meets the baseline but does not exceed it.

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

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

The description clearly states that the tool returns themes with the highest average winning scores ("easy" themes), which is a specific and meaningful distinction from sibling tools like get_theme_history or get_winning_entries. However, it lacks a direct verb (e.g., "Retrieves") and is phrased as a noun phrase, so it is not maximally 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 implies usage for preparation ("for prep") and defines the meaning of the parameters, providing some context for when to use it. However, it does not explicitly compare against alternatives or state when not to use it, leaving room for ambiguity among the many get_* 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 full disclosure burden. It lists the fields returned and implies a read-only status lookup, but it never explicitly confirms that the tool has no side effects or does not mutate the vault. This is adequate but not fully 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 compact, front-loaded summary: it names the resource, lists key fields, and then gives the motivating use case. Every part earns its place with no redundancy.

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

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

This is a low-complexity getter with one required parameter and no output schema. The description compensates by enumerating the main returned fields and the practical use case. It is missing only an explicit side-effect/read-only statement, but it is otherwise complete enough for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already explains agent_id and entry_fee_usdc. The description adds useful output-field context but no new parameter-level semantics, so the 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 names a specific resource (Entry Vault status), enumerates the returned fields (enrolled, remaining_usdc, usdc_balance, entries_left_at_fee), and states the intended use case (show the user's standing allowance). This clearly distinguishes it from siblings like get_balance and get_agent_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?

It gives clear usage context ('Use to show the user their standing allowance') and hints at why it is preferred when signing UIs render delegates poorly. It does not explicitly name alternatives or say when not to use it, so it earns a 4 rather than a 5.

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

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

With no annotations, the description discloses useful behavioral context: it returns entries with specific components (theme, payload, judge feedback) and indicates a filtering dimension (track). It clearly implies a read-only operation, which is appropriate for a GET 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 extremely concise, with all necessary information in a compact format. The first sentence states the core functionality, followed by parameter details, 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?

Despite lacking an output schema, the description explains what the response contains. It covers purpose, scope, parameters, and return content, making it complete for a simple read-only tool with two parameters.

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 the description adds no new parameter meaning. It restates the enum values and limits, which are already present in the schema, providing no additional semantic value.

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 'Top-scoring winning entries across the platform' and specifies the content (theme + payload + judge feedback). It also distinguishes itself from the sibling tool get_my_winning_entries by emphasizing '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 phrase 'for strategy research' gives a clear context for when to use the tool. It implies an alternative for personal entries via the word 'platform', though it does not explicitly name get_my_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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It reveals the output fields, ordering (newest first), and limit semantics. It does not mention error handling, authentication, or rate limits, but for a simple read-only history tool, this level of disclosure is reasonable.

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

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

The description is a single, information-dense sentence plus a limit note. Every word earns its place: it states the resource, ordering, and exact return fields. There is no fluff or repetition, making it exceptionally 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?

With no output schema, the description appropriately lists all returned fields, which is crucial for the agent to understand the response. It lacks details on status values or pagination behavior beyond the limit, but for a 2-parameter list tool, 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 descriptions cover 100% of parameters (limit, agent_id), and the description essentially restates the limit range/default already present in the schema. It adds no new semantic meaning beyond the schema, so it meets the baseline of 3 for high schema coverage.

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 'your past withdrawals' and lists the returned fields, which distinguishes it from related tools like get_balance or get_my_history. It lacks an explicit verb, but the tool name 'get' makes the action clear.

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

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

The description implies the tool is for viewing withdrawal history, mentioning order and limit, but does not explicitly state when to use it over alternatives (e.g., get_my_history or check_payout) or provide exclusion criteria. No alternatives are named.

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 disclosure responsibility. It covers idempotent already_seated behavior, single fee movement, the two-call signing flow, the one-call vault variant, and the fact that round submissions are free — far beyond minimal 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?

The description is dense but every sentence carries operational weight. It is front-loaded with the core action and source of lobby_id. Slight redundancy around 'single, bounded' and 'fee moves once' and some length could be trimmed, but complexity justifies most of it.

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 — two-call handshake, vault shortcut, idempotency, fee timing — and the absence of an output schema or annotations, the description is remarkably complete. It explains what happens on each call, what already_seated means, and the fee/cost implications.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics for transaction_signature: omit on first call, pass on confirm, and that vault-enrolled agents don't need it. It also reinforces that lobby_id comes from list_omega_lobbies.

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

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

The description states a specific verb and resource: 'claim ONE seat in a lobby', sourced from 'list_omega_lobbies'. It clearly distinguishes this tool from generic entry paths by naming the OMEGA lobby context and the two-call handshake shared with 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?

The description gives explicit operational guidance: confirm cost first, call once for pending_tx, sign/broadcast, then call again with transaction_signature; Entry-Vault-enrolled agents use one call. It does not explicitly list when NOT to use the tool versus submit_entry or other entry mechanisms, but the specialized purpose is clear enough.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals output characteristics like absolute timestamps and time_remaining_seconds, and even adds strategic context ('Low entry count = better odds'). It does not specify empty-list behavior or return type, but covers the essential details.

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

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

The description is four short, front-loaded sentences. Each sentence earns its place: main purpose, typical count, strategic hint, and timestamp details. No verbose or redundant language is present.

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

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

For a simple list tool with one optional parameter and no output schema, the description provides a solid overview of return contents and key fields. It could explicitly state that the result is an array, but 'Returns all contests' implies a collection, and the main timestamp fields are listed.

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

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

The input schema fully covers the single parameter `track` with a clear description ('Filter by track. Default: ALL'). The tool description adds little beyond the schema's parameter semantics, so the baseline of 3 is appropriate.

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

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

The description opens with 'Returns all contests currently open for entry,' clearly stating the verb and scope. It distinguishes this from other listing tools like get_leaderboard or list_omega_lobbies by focusing on active contests and mentioning per-track behavior.

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

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

Clear context is provided: the tool is for retrieving currently open contests, and the note that typically 1–3 are active (one per track) implies when to use it. It does not explicitly name alternatives or exclusions, but the purpose is obvious enough for an agent to select it appropriately.

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 behavioral burden and does so thoroughly: it explains fill-triggered starts, no voting, zero scoring for missed rounds, reward distribution, on-chain settlement, and the exact output fields. This goes far beyond a simple 'lists lobbies' statement.

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 core purpose and then provides dense, relevant context. It is longer than strictly necessary, but every sentence adds useful operational detail about how lobbies work and what the tool returns, so it remains well-structured.

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

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

There is no output schema, so the description correctly explains what each lobby returns: entry_fee_usdc, seats filled/total, computed reward table, and estimated start. It also covers optional behavior through agent_id and the you_are_seated flag, making the tool fully understandable.

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

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

The only parameter, agent_id, is already documented in the schema, but the description adds meaningful semantics: passing it tags each lobby with you_are_seated and enables a useful skip decision. This is genuine added value beyond the schema.

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

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

The description opens with a clear verb-resource pair: 'list open elimination-game lobbies.' It specifies the Omega game context and distinguishes this tool from related concepts like join_omega_lobby or get_omega_state.

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 strong usage context: it is for finding open lobbies and checking entry cost before entering. It also advises skipping lobbies where you_are_seated is true rather than attempting a second entry. It stops short of explicitly naming alternatives or stating when not to use the 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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses the one-time nature, the keypair signing requirement, the returned agent_id, that it is free, and the exact GEO_BLOCKED error path including state and cloud-host caveats. This is far beyond a generic 'registers an agent' statement.

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 most important routing decision (advanced vs. onboarding), then delivers purpose, return value, cost, and geolocation warnings. Every sentence adds operational value, and the Replit example is concrete rather than filler.

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

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

For a complex registration tool with 8 parameters, no annotations, and no output schema, the description is unusually complete. It explains prerequisites, return value, cost, failure mode, and geo-restrictions. Combined with the fully described schema, an agent has enough to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters with rich detail, including the signed_message format and email verification behavior. The description adds useful global context about signing and geolocation but does not meaningfully expand parameter-level semantics beyond what the schema provides.

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

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

Description clearly states the tool's purpose: 'One-time agent registration: proves keypair ownership via signed message.' It names the exact signing domain and the returned agent_id, distinguishing it from the sibling start_onboarding 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?

Explicitly says this is the ADVANCED path requiring a local keypair, and directs agents without one to start_onboarding instead. It also gives geolocation constraints and alternative behavior, making the decision boundary unambiguous.

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 behavioral burden and does so thoroughly. It discloses rate limiting (3 sends per 24h), idempotent duplicate handling (already_verified and verification_pending cases do not re-send), the safe no-op behavior for re-supplying the current address, and the side effect of changing to a different address.

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 information-dense, with no filler. The first sentence states the core purpose, and subsequent sentences are grouped logically into general behavior, rate-limit/duplicate handling, and email-parameter semantics. Every sentence adds operational 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?

There is no output schema, so the description compensates by explaining the meaningful return states (already_verified, verification_pending with expires_at) and the two confirmation paths. It also situates the tool within the broader workflow by naming submit_entry and confirm_email_code, making the tool's role and expected outcomes clear enough to invoke correctly.

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

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

Schema description coverage is 100%, and the schema already documents the email semantics almost identically, including the optional omit behavior, no-op for current address, and trigger for a different address. The description adds no new parameter-level facts beyond what the input schema provides, though it does reinforce them 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?

The description opens with a specific verb-and-resource statement: 'Set or change your agent contact email and (re)send the verification link.' It also clarifies the tool's role relative to the email-verification flow and explicitly distinguishes it from confirm_email_code by describing the link-sending vs. code-confirming paths.

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 when-to-use guidance: verifying email is required before submit_entry, while 'everything else works without it.' It also covers when passing the email parameter is appropriate, when omitting it is appropriate, and points to confirm_email_code as the alternative MCP-native path for completing confirmation.

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 a key behavioral trait: 'Returns an SPL revoke tx to sign'—indicating the tool does not execute the revocation directly but provides a transaction for the user to sign. It also explains the effect ('removes the engine's delegate') and reassures about fund custody ('Your funds were never held by us'). This is more than a tautological restatement.

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

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

Two sentences, front-loaded with the main action, and every phrase adds value. No wordiness or repetition of schema details.

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 one-parameter tool with no output schema, the description adequately explains the return value ('SPL revoke tx to sign') and the net effect. It could be slightly more explicit about the context (e.g., that this is on Solana), but 'SPL' and 'USDC ATA' provide sufficient cues. The simplicity of the tool means less is needed.

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 is described as 'Your registered agent_id.'). The description adds no additional detail about the parameter, so the baseline of 3 applies as the schema does the heavy lifting.

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

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

The description opens with the precise verb+resource combination: 'Revoke the Entry Vault allowance.' It further clarifies the effect ('removes the engine's delegate on your USDC ATA') and clearly differentiates from the sibling tool 'enroll_entry_vault' by the verb 'Revoke'.

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

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

Usage is implied: if you want to revoke the Entry Vault allowance, this is the tool. However, there is no explicit statement of when to use it versus alternatives like enroll_entry_vault, nor any exclusions or prerequisites mentioned.

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

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

No annotations exist, so the description carries the burden. It discloses that notes are saved, read back by the agent, and that the stored notes are returned. However, it doesn't state whether existing notes are overwritten, any auth requirements, or error 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?

Two concise sentences cover the action, constraint, effect, and return value without waste. Information is front-loaded and easy to scan.

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 write operation with no output schema, the description is mostly complete: it states the purpose, the storage effect, and what is returned. It could mention overwrite semantics, but overall it provides enough context for correct invocation.

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

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

Schema coverage is 100%, with both agent_id and notes having descriptions. The description adds minimal extra meaning beyond the schema, mainly framing notes as coaching/style guidance and noting the agent uses them.

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') with a clear resource ('coaching/style guidance on your agent profile') and includes constraints (free text, max 4000 chars). It clearly distinguishes from the sibling tool get_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?

It provides clear context: use this to save guidance that the agent will read back to shape how it competes. It doesn't explicitly mention when not to use or name alternatives, but the purpose is evident.

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 and does well by specifying validation constraints, case-insensitive uniqueness, the exact return shape, and all rejection reasons. It does not clarify whether calling it again overwrites an existing username or whether claiming is a one-time operation, so it is not a 5.

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 deliver the purpose, constraints, behavioral nuance, full return contract, and terminology mapping without any filler. The most important action 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?

The description is nearly complete for a simple two-parameter setter: it includes required field usage, return format, validation rules, and failure reasons even though there is no output schema. It only misses explicit guidance about pre-checking with check_username_available and repeated-call/overwrite semantics.

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 already 100%, so the baseline is 3. The description adds meaningful parameter detail by explaining that case is preserved for display while uniqueness is case-insensitive, and it clarifies that 'username' is the wire name for 'Agent name'.

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 ('Claim') and resource ('Agent name'), including the context that this is the public leaderboard name. It clearly distinguishes this setting tool from the sibling check_username_available by focusing on claiming/setting rather than 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?

The imperative 'Claim your Agent name' implies when to use the tool, and the validation/return details define what success looks like. However, it does not explicitly mention alternatives such as check_username_available or state when this tool should be avoided.

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 main side effects: it creates the account and balance, and switches on instant contest entry. However, it does not mention potential constraints or failure modes (e.g., what happens if the user already has an account, or link expiration). Since there are no annotations, the description carries the full burden, and it covers the primary effects well but omits some edge-case 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 concise but includes some conversational extras (e.g., 'a normal ~3-minute website signup' and 'shown at the end of setup') that add helpful context without being overly verbose. It is structured logically from condition to action to follow-up.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is complete: it explains the input (src), the process (link generation, account creation), the expected output (setup link and agent ID), and how to integrate the result with sibling tools. Nothing essential is missing.

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 'src' is clearly described as an attribution tag for the link, with a default value of 'mcp'. The schema description fully covers its purpose and constraints (maxLength 64).

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: to generate a personal setup link for onboarding a human, which creates their account, balance, and enables instant contest entry. It also distinguishes itself from sibling tools like get_onboarding_status or register_agent by focusing on the link generation and initial setup process.

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 an explicit condition for use ('No keypair or account yet?') and instructs the agent to call this tool in that case. It also gives clear follow-up steps ('Afterwards ask them for their agent ID ... and use it with the other tools'), making it obvious when and how to invoke it relative to other tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses the two-call co-signing design, that the engine never holds the private key, that the engine pays the network fee and sets priority fee/compute budget, and warns not to modify the returned transaction. It also describes status transitions and error behavior 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 core steps are front-loaded and well-ordered, and every section has a clear purpose. However, the coaching-feedback section includes verbatim conversational scripts and the TypeScript reference is lengthy; while valuable, these could be trimmed without losing essential invocation guidance.

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, the description fully documents return shapes for both steps, all relevant error codes with recovery instructions, prerequisites such as ToS acceptance and email verification, and the exact signing/broadcast flow. Nothing critical to calling the tool correctly is missing.

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 the schema already documents all 5 parameters. The description goes significantly beyond the schema by explaining the OMIT-then-PROVIDE lifecycle of transaction_signature, the free include_feedback coaching behavior, and the atomic fee movement with no separate USDC transfer needed.

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

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

States a specific verb and resource ('Submit an entry') and immediately explains the two supported flows: instant entry for wizard-enrolled agents and a two-call handshake for everyone else. It clearly distinguishes the tool's role by referencing start_onboarding, list_active_contests, and the enter_contest contract flow.

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 guidance: enrolled agents use one call, non-enrolled agents use the two-call handshake; tells callers to call start_onboarding if no agent exists. The error-code section maps each failure mode to a concrete recovery action, such as calling list_active_contests when CONTEST_CLOSED.

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

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

No annotations are provided, so the description carries the full burden. It discloses major behavioral traits: the Judge scores every entry and cuts the lowest, there is NO voting, ties break toward earlier submissions, and frame-breaking scores the floor. This is rich behavioral context beyond the 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 yet dense: each sentence delivers distinct information—action, timing, entry limit, scoring mechanism, tie-breaking, and fiction constraint. There is no filler or redundant phrasing.

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, no annotations, and no output schema, the description covers the essential operational and strategic details: the 88-second window, one-entry limit, scoring curve with no voting, tie-breaking rule, and fiction requirement. Although return values are not mentioned, the behavioral context is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so all four parameters (game_id, payload, agent_id, lobby_id) are already documented. The description reinforces lobby_id as the canonical identifier but does not add new parameter-level semantics beyond the schema, meeting the baseline for high coverage.

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

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

The description opens with 'OMEGA — submit your entry for the live round of a lobby (by lobby_id), within its 88-second window,' specifying the action (submit), resource (entry for a live round), and key parameter. This clearly distinguishes it from sibling tools like submit_entry and get_omega_state.

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 clear context for when to use this tool: 'within its 88-second window' and 'One entry per round.' It does not explicitly name alternatives or exclusions, but the OMEGA-specific framing and timing constraints make the intended use unambiguous.

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