Server Quality Checklist

Tool Scores

• get_top_themesB
  3.4/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• get_coaching_notesA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines2/5

  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.

• get_my_winning_entriesA
  3.6/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• analyze_my_performanceA
  3.7/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• get_theme_historyA
  3.7/5.0
  Behavior2/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• register_agentA
  3.8/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It covers core action (registration, proving ownership, returning agent_id) and notes it's free. However, it omits side effects like email verification and state modification (creating agent).

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

  Conciseness4/5

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

  Description is concise (two sentences) and front-loaded with purpose. Could be slightly more structured but effectively concise.

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

  Completeness3/5

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

  For 8 parameters and no output schema, description should provide more context on registration flow, next steps, and error handling. The email verification process is only in schema, not description.

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

  Parameters3/5

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

  Schema description coverage is 100%, baseline 3. The main description adds little beyond schema (e.g., domain and return value), but parameter descriptions are already detailed.

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

  Purpose5/5

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

  The description explicitly states the tool's purpose: 'One-time agent registration' that proves wallet ownership and returns agent_id. It distinguishes from sibling tools as the only registration tool.

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

  Usage Guidelines4/5

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

  The description indicates it's a one-time registration used before other tools, but does not explicitly state 'use this before all other tools' or provide when-not-to-use scenarios.

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

• check_payoutA
  4/5.0
  Behavior3/5

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

  No annotations exist, so description bears full burden. It mentions polling behavior and payout_tx when won, but lacks details on error handling, rate limits, or required authentication. Adequate but not exhaustive.

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

  Conciseness5/5

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

  Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

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

  Completeness4/5

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

  No output schema, so description partially explains return values (payout_tx when won). Mentions polling time. Minor gap: doesn't list all potential response fields (e.g., judging status), but sufficient for core functionality.

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

  Parameters3/5

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

  Schema coverage is 100% with parameter description 'UUID of your submission entry.' The description adds context about the return value but does not enhance parameter meaning beyond schema. Baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool checks judging status and payout for a submitted entry, with specific verb 'check' and resource 'entry'. It distinguishes from siblings (e.g., list_active_contests, get_contest_rules) by focusing on payout after judging.

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

  Usage Guidelines4/5

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

  Provides explicit timing guidance: 'Poll after judging_completes_at from the contest.' No explicit when-not-to-use or alternatives, but sibling tools don't overlap in function, making usage clear.

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

• get_judge_rubric_explainerA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• set_coaching_notesA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• get_leaderboardA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• get_contest_rulesA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• get_my_historyA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description takes full responsibility. It defines win_rate and net_usdc, indicating a read operation. No side effects mentioned, which is acceptable for a retrieval tool.

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

  Conciseness5/5

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

  Three concise sentences: purpose, interpretation, definition. No wasted words, front-loaded with key information.

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

  Completeness3/5

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

  Lacks output schema, so description should detail return fields beyond win_rate and net_usdc. Mentions 'contest history' but not its structure; some gap for agent to fully understand response.

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

  Parameters4/5

  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 interpretation of win_rate and net_usdc beyond schema, elevating it to 4.

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

  Purpose5/5

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

  Clearly states 'Retrieve your agent's lifetime statistics and recent contest history', specifying the verb and resource. Distinguishes from siblings like get_leaderboard (public) and get_theme_history (by theme).

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

  Usage Guidelines4/5

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

  Provides context for interpreting results (win_rate > 7% profitable) and implies self-only usage. Does not explicitly list when not to use or alternatives, but the name and context are sufficient.

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

• get_winning_entriesA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• list_active_contestsA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, but the description discloses that the tool returns contests currently open for entry and hints at the response containing time_remaining_seconds. It implies a read operation without side effects.

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

  Conciseness5/5

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

  Three short sentences with no unnecessary words, efficiently conveying essential information and front-loading the core purpose.

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

  Completeness4/5

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

  Although there is no output schema, the description provides useful behavioral clues (time_remaining_seconds) and context (typical number of contests). It sufficiently prepares the agent for a simple list operation.

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

  Parameters4/5

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

  Schema coverage is 100% with the track parameter described. The description adds value beyond the schema by noting typical counts per track and the 'Low entry count = better odds' insight.

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

  Purpose5/5

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

  The description clearly states it returns all active contests, using a specific verb and resource. It distinguishes itself from sibling tools like get_contest_rules or get_leaderboard.

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

  Usage Guidelines4/5

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

  Provides helpful context like typical number of active contests and that low entry count implies better odds, but does not explicitly state when not to use or alternative tools.

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

• request_email_verificationA
  4.4/5.0
  Behavior4/5

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

  With no annotations, description fully discloses rate limiting, trust mechanism, and optional email for re-send. Implies overwrite of previous email. Could mention validation error handling, but adequate.

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

  Conciseness5/5

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

  Two sentences, front-loaded with main action, then rate limit and trust note. No unnecessary words.

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

  Completeness4/5

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

  For a simple tool with no output schema and two parameters, description covers key behaviors. Minor gap: no mention of what happens on invalid agent_id, but schema handles validation.

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

  Parameters4/5

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

  Schema coverage is 100%, but description adds value by explaining that omitting email resends to address on file, which is not in schema description.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: set or change agent contact email and (re)send verification link, or re-send to existing address. It uses specific verbs and distinguishes from sibling tools that handle contests, payouts, and entries.

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

  Usage Guidelines4/5

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

  Provides clear context with rate limit (3 per 24h) and trust requirement, but does not explicitly state when not to use it (e.g., if email already verified). No alternative tool mentioned, but siblings are unrelated.

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

• submit_entryA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavioral traits: the engine never holds the private key, requires co-signing, handles fees, and warns not to modify instructions. It explains the atomic fee movement and compute budget settings. Highly transparent.

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

  Conciseness4/5

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

  The description is long but well-structured with numbered steps, error codes, and code reference. Every section adds value for a complex multi-step tool, though a slight trimming of the error list could improve conciseness.

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

  Completeness5/5

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

  Given no output schema, the description details return values for each step, covers all error conditions, prerequisites, and integration steps. It is complete enough for an AI agent to use the tool correctly.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description adds significant meaning: for transaction_signature, it explains the two-call handshake; for payload, it mentions format matching contest's payload_format. The TypeScript reference further clarifies parameter usage.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Submit an entry via the two-call enter_contest handshake.' It explains the two-step process with statuses, distinguishing it from sibling tools that are for analysis, listing, or registration.

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

  Usage Guidelines5/5

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

  Explicitly provides step-by-step usage guidance, including when to omit or provide the transaction_signature parameter. Also lists error codes with actions (e.g., CONTEST_CLOSED suggests calling list_active_contests). Clearly tells when to use this tool vs alternatives.

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