Server Quality Checklist

Tool Scores

• frontrun_classifyC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'Returns AI classification merged with your custom rules and tags' which hints at read-only analysis rather than mutation, but doesn't clarify permissions needed, rate limits, whether it's synchronous/asynchronous, or what happens with invalid inputs. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

  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 reasonably concise with two sentences that each serve a purpose: the first states the core function, the second provides additional context about the return value and usage timing. However, the second sentence could be more front-loaded with critical information, and some phrasing ('analyze entities on demand') is somewhat redundant with the first sentence.

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

  Completeness2/5

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

  For a tool with no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what format the classification results take, what 'AI classification' specifically means, how 'custom rules and tags' are applied, or any error conditions. Given the complexity implied by merging AI analysis with custom rules, the description should provide more context about the operation's behavior and outputs.

  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 schema already fully documents both parameters (usernames and twitter_user_ids). The description adds no additional parameter information beyond what's in the schema - it doesn't explain the relationship between these two parameter types, whether both are required, or how they interact. With high schema coverage, 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.

  Purpose3/5

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

  The description states the tool 'Run classification on specific entities' which provides a basic verb+resource combination, but it's vague about what 'classification' means in this context. It doesn't clearly distinguish this tool from sibling tools like 'frontrun_tag' or 'frontrun_search' that might also involve entity analysis. The mention of 'AI classification merged with your custom rules and tags' adds some specificity but remains somewhat abstract.

  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 minimal guidance with 'Use this to analyze entities on demand' which suggests real-time analysis but doesn't specify when to choose this tool over alternatives like 'frontrun_search' or 'frontrun_trending'. There's no mention of prerequisites, limitations, or explicit comparison with sibling tools, leaving the agent with insufficient context for optimal tool selection.

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

• frontrun_delete_ruleC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive operation, the description doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects on related data. This leaves significant behavioral gaps for a mutation tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple deletion operation and gets straight to the point.

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

  Completeness2/5

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

  For a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion (success confirmation, error conditions), whether the action affects other system components, or provide any context about the rule lifecycle. The agent lacks critical information to use this tool safely and 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 description coverage is 100%, with the single parameter 'id' documented as 'Rule UUID to delete'. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, so it meets the baseline expectation without adding extra value.

  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 action ('Delete') and the resource ('a custom classification rule'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'frontrun_update_rule' or explain what distinguishes deletion from other rule modifications.

  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 like 'frontrun_update_rule' or 'frontrun_list_rules'. There's no mention of prerequisites (e.g., needing an existing rule ID), consequences of deletion, or when deletion is appropriate versus updating.

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

• frontrun_list_trackedB
  3.1/5.0
  Behavior2/5

  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 states it's a list operation, implying it's read-only, but doesn't cover critical aspects like pagination, rate limits, authentication needs, error handling, or what 'follow activity' entails. This leaves significant gaps for a tool in a monitoring context.

  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, clear sentence with zero waste—it directly states the tool's purpose without fluff or redundancy. It's appropriately sized for a no-parameter list tool and front-loads the essential information.

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

  Completeness2/5

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

  Given the complexity of monitoring tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what data is returned (e.g., account details, tracking status), how results are formatted, or behavioral constraints, making it inadequate for reliable agent use beyond basic listing.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't add parameter details, earning a baseline score of 4 for not introducing unnecessary information.

  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 verb 'List' and the resource 'accounts currently being monitored for follow activity', which is specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'frontrun_list_rules' or 'frontrun_list_tags', which would require mentioning what makes this listing unique (tracked accounts vs. rules vs. tags).

  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 doesn't mention prerequisites (e.g., needing tracked accounts first), exclusions, or comparisons to siblings like 'frontrun_search' or 'frontrun_account_activity', leaving the agent to infer usage from the name alone.

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

• frontrun_tagB
  3.1/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 burden of behavioral disclosure. It describes the action ('Add') but fails to specify whether this is a creation, update, or mutation operation, and omits critical details like required permissions, rate limits, idempotency, or what happens if tags already exist. For a tool with 6 parameters and no annotations, this lack of behavioral context is a significant gap.

  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 efficiently structured in two sentences: the first states the core functionality, and the second provides usage examples. It avoids redundancy and is appropriately sized for the tool's complexity, though it could be slightly more front-loaded with key behavioral details given the lack of annotations.

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

  Completeness2/5

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

  Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and usage examples but fails to address behavioral aspects like mutation effects, error handling, or return values. Without annotations or an output schema, the agent lacks sufficient context to invoke this tool confidently in varied scenarios.

  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 has 100% description coverage, providing clear documentation for all 6 parameters (e.g., 'twitter_user_id' as 'Twitter user ID of the entity'). The description adds minimal value beyond the schema by listing the types of data that can be added ('custom tags, sector override, or notes') but does not elaborate on parameter interactions, constraints, or usage examples beyond what's already in the schema descriptions.

  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 action ('Add custom tags, sector override, or notes') and the resource ('to a specific entity'), with specific examples like 'build custom watchlists, mark competitors, or annotate companies.' However, it doesn't explicitly differentiate this tool from siblings like 'frontrun_list_tags' or 'frontrun_update_rule,' which might handle similar tagging operations, leaving some ambiguity about its unique role.

  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 provides implied usage through examples ('Use this to build custom watchlists, mark competitors, or annotate companies'), suggesting contexts for application. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'frontrun_list_tags' for viewing tags or 'frontrun_update_rule' for rule-based tagging), and does not mention prerequisites or exclusions, leaving the agent to infer best practices.

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

• frontrun_update_ruleB
  3.1/5.0
  Behavior2/5

  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. While 'Update' implies a mutation operation, the description doesn't specify permission requirements, whether changes are reversible, potential side effects, or what happens to unspecified fields (partial vs. full updates). For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps for the agent to navigate.

  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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a straightforward update operation and front-loads the essential information. Every word earns its place in this minimal but complete statement.

  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?

  Given the tool's moderate complexity (5 parameters with nested objects), lack of annotations, and absence of an output schema, the description is minimally adequate but leaves significant gaps. It identifies the operation type but doesn't address behavioral aspects, usage context, or return values. For a mutation tool without annotations or output schema, more contextual information would be helpful for the agent.

  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 has 100% description coverage, providing clear documentation for all 5 parameters and their nested structures. The description adds no additional parameter semantics beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description, which applies here.

  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 verb ('Update') and resource ('an existing custom classification rule'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'frontrun_create_rule' and 'frontrun_delete_rule' by specifying it updates existing rules rather than creating or deleting them. However, it doesn't explicitly differentiate from other update-like operations that might exist in the system.

  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 doesn't mention prerequisites (e.g., needing the rule UUID from 'frontrun_list_rules'), when not to use it (e.g., for creating new rules), or how it relates to sibling tools like 'frontrun_create_rule' or 'frontrun_delete_rule'. The agent must infer usage from the tool name and context alone.

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

• frontrun_enriched_followsB
  3.2/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 burden of behavioral disclosure. It mentions 'full enrichment' and merging of AI classification, custom rules, and custom tags, which adds some context about what the tool does beyond basic retrieval. However, it doesn't disclose critical behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what happens if no data is found. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

  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 appropriately sized with two sentences that are front-loaded: the first sentence states the core purpose and key features, and the second emphasizes its power for workflows. There's no wasted text, and it efficiently conveys value. However, it could be slightly more structured by explicitly separating features from usage advice, but it's still highly 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?

  Given the complexity (enrichment tool with no annotations and no output schema), the description is moderately complete. It covers the purpose and enrichment aspects but lacks details on output format, error handling, or behavioral constraints. Without annotations or output schema, more context on what the tool returns or its limitations would be beneficial. It's adequate for a basic understanding but has clear gaps for a tool involving custom rules and tags.

  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 schema already fully documents the two parameters ('since' and 'username') with descriptions. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter interactions, default behaviors beyond the schema's 'Default: "24h"', or how enrichment applies to filtered results. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra insights.

  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's purpose: 'Get new follows with full enrichment' which specifies the action (get) and resource (new follows). It distinguishes itself by mentioning 'AI classification + your custom rules + your custom tags, all merged' and calls it 'the most powerful endpoint for custom workflows,' which helps differentiate it from siblings like 'frontrun_new_follows' that likely provide basic follows without enrichment. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.

  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 context by stating 'This is the most powerful endpoint for custom workflows,' suggesting it should be used for advanced scenarios. It doesn't provide explicit when-to-use vs. when-not-to-use guidance or name specific alternatives like 'frontrun_new_follows' for basic follows. The implication is adequate but lacks clear exclusions or direct sibling comparisons, placing it at a medium level.

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

• frontrun_list_rulesB
  3.2/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 burden of behavioral disclosure. It states the action ('List') but doesn't add context such as whether this is a read-only operation, if it requires authentication, or any rate limits. This leaves significant gaps in understanding the tool's behavior beyond its basic function.

  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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse for an AI agent.

  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?

  Given the tool's low complexity (0 parameters, no output schema) and lack of annotations, the description is minimally adequate. It states what the tool does but lacks behavioral context and usage guidance, which could be beneficial for a tool in a set with many siblings. It meets the minimum viable threshold but has clear gaps.

  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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could briefly note the lack of inputs for clarity. Baseline is 4 since no parameters exist.

  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 verb ('List') and resource ('your custom classification rules'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'frontrun_list_tags' or 'frontrun_list_tracked', which likely list different types of items, so it misses full sibling distinction.

  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. For example, it doesn't mention if this is for viewing rules before editing with 'frontrun_update_rule' or deleting with 'frontrun_delete_rule', leaving the agent to infer usage from context alone.

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

• frontrun_searchB
  3.2/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 burden of behavioral disclosure. It mentions the search scope ('across all accounts followed by your tracked set'), which adds useful context. However, it doesn't disclose key behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or what the output format looks like (e.g., list of entities with details). For a search tool with no annotations, this leaves significant gaps.

  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 concise and well-structured with two sentences: the first states the purpose and parameters, and the second provides usage guidance. There's no wasted language, and it's front-loaded with key information. However, it could be slightly more efficient by integrating the usage hint into the first 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?

  Given the complexity (a search tool with 4 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose and scope adequately but lacks details on behavioral aspects (e.g., output format, pagination, errors) and doesn't fully compensate for the missing annotations. It's sufficient for basic use but leaves the agent to infer or guess about critical operational details.

  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 schema already documents all four parameters (sector, keyword, entity_type, limit) with clear descriptions and examples. The description adds minimal value beyond the schema by mentioning 'sector, keyword, or entity type' and the search scope, but it doesn't provide additional semantics like parameter interactions or default behaviors not covered in the schema. The baseline of 3 is appropriate given the high schema coverage.

  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's purpose: 'Search discovered entities by sector, keyword, or entity type.' It specifies the verb ('Search') and resource ('discovered entities'), and mentions the search scope ('across all accounts followed by your tracked set'). However, it doesn't explicitly differentiate from sibling tools like 'frontrun_trending' or 'frontrun_enriched_follows' that might also involve searching or listing entities.

  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 provides some usage context: 'Use this to find companies in a specific space.' This implies when to use it (for targeted searches), but it doesn't explicitly state when not to use it or name alternatives among sibling tools. For example, it doesn't clarify if this should be used instead of 'frontrun_trending' for broader discovery or 'frontrun_list_tracked' for already-tracked entities.

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

• frontrun_statusB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify authentication requirements, rate limits, whether this is real-time or cached data, or what happens if the account doesn't exist. The description mentions what data is returned but not how it's formatted or structured.

  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, efficient sentence that front-loads the core purpose ('Get account status') followed by specific data elements. Every word earns its place with no redundancy or unnecessary elaboration.

  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 zero-parameter read tool with no output schema, the description provides the essential what (account status) and what data it includes. However, without annotations or output schema, it should ideally mention the response format or structure. The description is adequate but leaves gaps about behavioral aspects and output format.

  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?

  With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't waste space discussing parameters that don't exist, which is efficient and correct.

  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's purpose with specific verb 'Get' and resource 'account status', listing the exact data returned (balance, tracked account count, usage stats, pricing). It distinguishes from siblings like frontrun_account_activity or frontrun_list_tracked by focusing on account-level status rather than activity or list operations.

  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. With siblings like frontrun_list_tracked (for tracked accounts) and frontrun_account_activity (for activity data), there's no indication of when this status tool is preferred over those more specific tools.

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

• frontrun_trackB
  3.4/5.0
  Behavior3/5

  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 key behavioral traits: it initiates monitoring, has cost implications ($0.10 for standalone users, free for SaaS Pro+), and outputs to 'new follows and convergence data.' However, it misses details like whether tracking is persistent, requires authentication, has rate limits, or what happens on errors. The description adds value but doesn't fully cover behavioral aspects.

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

  Conciseness4/5

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

  The description is appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second adds cost and data context. Every sentence earns its place by providing essential information without redundancy. It could be slightly more structured by separating usage notes, but it's efficient overall.

  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?

  Given no annotations, no output schema, and a simple input schema with 100% coverage, the description is moderately complete. It covers purpose, cost, and data output, but lacks details on behavioral traits like persistence, error handling, or integration with sibling tools. For a tool that initiates monitoring with financial implications, more context on operational aspects would improve completeness.

  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% for the single parameter 'username,' with the schema providing a clear description. The description adds no additional parameter semantics beyond implying the username is for Twitter/X tracking. Since schema coverage is high, the baseline is 3, and the description doesn't compensate with extra details like format examples or constraints.

  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's purpose: 'Start monitoring a Twitter/X account' with the specific action of tracking new follows. It distinguishes from siblings by focusing on initiating tracking rather than listing (frontrun_list_tracked), deleting (frontrun_untrack), or analyzing follows (frontrun_new_follows). However, it doesn't explicitly contrast with all siblings like frontrun_create_rule which might also involve monitoring setup.

  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 context by mentioning costs and that tracked data appears in 'new follows and convergence data,' suggesting when to use this for monitoring vs. other tools like frontrun_new_follows for retrieval. However, it lacks explicit guidance on when to choose this over alternatives such as frontrun_create_rule or frontrun_list_tracked, and no exclusions are provided.

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

• frontrun_list_tagsA
  3.5/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 filtering behavior ('Filter by tag name or sector'), which is useful, but lacks details on permissions, rate limits, pagination, or return format. For a list tool with zero annotation coverage, this is a moderate gap, as it doesn't fully describe operational traits.

  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, efficient sentence that front-loads the core action ('List your custom-tagged entities') and adds necessary detail ('Filter by tag name or sector'). There is no wasted text, making it appropriately sized 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?

  Given the tool's complexity (a list operation with filtering), no annotations, and no output schema, the description is moderately complete. It covers the purpose and filtering options but lacks information on output format, error handling, or behavioral constraints, which could hinder an agent's ability to use it 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 description coverage is 100%, with both parameters ('tag' and 'sector') documented in the schema. The description adds marginal value by mentioning filtering by 'tag name or sector,' but doesn't provide additional semantics beyond what the schema already states. This meets the baseline for high schema coverage.

  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 verb ('List') and resource ('your custom-tagged entities'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'frontrun_list_rules' or 'frontrun_list_tracked', which also list different types of entities.

  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 through the phrase 'Filter by tag name or sector,' suggesting it's for retrieving tagged entities with optional filtering. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'frontrun_search' or 'frontrun_list_tracked,' nor does it mention prerequisites or exclusions.

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

• frontrun_snapshotA
  3.5/5.0
  Behavior2/5

  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 states the tool retrieves a 'snapshot' and 'current' data, implying read-only behavior, but does not address critical aspects like rate limits, authentication requirements, data freshness, or potential errors (e.g., if the account doesn't exist). This leaves significant gaps for an agent to understand operational constraints.

  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 highly concise and front-loaded, consisting of two clear sentences that directly state the tool's purpose and scope without any redundant or vague language. Every word contributes to understanding, making it efficient and easy to parse.

  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 operation with one parameter and no output schema, the description adequately covers the basic purpose. However, without annotations or output schema, it lacks details on return format (e.g., list structure, pagination), error handling, and operational limits, which are important for an agent to use the tool effectively in real-world scenarios.

  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 has 100% description coverage, with the 'username' parameter fully documented in the schema itself. The description adds no additional semantic context beyond what the schema provides (e.g., format examples like '@handle' or validation rules). Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to.

  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 specific action ('Get'), resource ('current follow list'), and scope ('latest snapshot for a tracked account'), distinguishing it from siblings like 'frontrun_new_follows' (which likely shows changes) or 'frontrun_enriched_follows' (which may include additional data). It explicitly mentions 'Shows everyone they currently follow' to reinforce the static snapshot nature.

  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 by specifying 'for a tracked account' and 'current follow list', suggesting it's for retrieving real-time following data. However, it lacks explicit guidance on when to use this tool versus alternatives like 'frontrun_new_follows' (for changes) or 'frontrun_enriched_follows' (for enhanced data), leaving room for ambiguity in sibling tool selection.

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

• frontrun_untrackA
  3.6/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 full burden. It states the action ('stop monitoring') but doesn't disclose behavioral traits like whether this requires authentication, what happens if the account isn't being tracked (error vs. no-op), whether it's reversible, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place, and there's no redundancy or unnecessary elaboration.

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

  Completeness2/5

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

  Given the tool's complexity (a mutation operation to stop tracking), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens after stopping monitoring (e.g., does it return a confirmation?), potential errors, or prerequisites. For a tool that modifies state, more context is needed to guide 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?

  The description doesn't mention parameters, but the input schema has 100% description coverage (the 'username' parameter is fully documented in the schema). With high schema coverage, the baseline is 3 even without param info in the description. The description doesn't add meaning beyond the schema, but it doesn't need to compensate for gaps.

  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 specific action ('Stop monitoring') and the target resource ('a Twitter/X account'), distinguishing it from sibling tools like 'frontrun_track' (which likely starts monitoring) and 'frontrun_list_tracked' (which lists monitored accounts). The verb 'stop monitoring' is precise 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 Guidelines4/5

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

  The description implies usage context: it should be used when you want to cease tracking an account you're currently monitoring. However, it doesn't explicitly state when NOT to use it (e.g., if the account isn't being tracked) or name specific alternatives like 'frontrun_track' for the opposite action. The context is clear but lacks explicit exclusions or named alternatives.

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

• frontrun_account_activityA
  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 burden of behavioral disclosure. It describes what the tool returns (activity profile with specific metrics) but does not disclose critical behavioral traits such as whether this is a read-only operation, authentication requirements, rate limits, error handling, or data freshness. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational characteristics.

  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 appropriately sized and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and usage. The first sentence lists key outputs, and the second provides context, with no wasted words or redundant information. Every sentence earns its place by adding value.

  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?

  Given the tool's complexity (analyzing account activity with multiple metrics), lack of annotations, and no output schema, the description is incomplete. It specifies what the tool does but fails to cover behavioral aspects, return format details, or error conditions. While it adequately states the purpose, it does not provide enough context for safe and effective use without additional assumptions.

  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 has 100% description coverage, with clear documentation for both parameters ('username' and 'since'). The description does not add any meaningful semantic details beyond what the schema provides, such as explaining how 'follow velocity' is calculated or what 'sector distribution' entails. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

  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 with specific verbs ('Get activity profile') and resources ('tracked account'), listing concrete outputs like 'follow velocity, sector distribution, snapshot coverage, and recent follows with classification'. It distinguishes from siblings by focusing on analyzing a specific VC's recent behavior, unlike tools like 'frontrun_snapshot' or 'frontrun_new_follows' that might handle different aspects.

  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 clear context for when to use this tool ('to analyze a specific VC's recent behavior'), but does not explicitly state when not to use it or name alternatives among siblings. It implies usage for activity profiling rather than other operations like tagging or rule management, but lacks explicit exclusions or comparisons.

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

• frontrun_create_ruleA
  3.7/5.0
  Behavior2/5

  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 mentions that rules 'auto-tag entities matching conditions,' implying a write operation, but lacks details on permissions, side effects (e.g., whether rules are applied immediately or require activation), error handling, or rate limits. For a creation tool with zero annotation coverage, this is a significant gap in 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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the second providing usage examples. Every sentence earns its place by adding value without redundancy, making it efficient and easy to parse.

  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?

  Given the tool's complexity (3 parameters with nested objects, no output schema, and no annotations), the description is adequate but has clear gaps. It covers purpose and usage well but lacks behavioral details (e.g., how rules are applied, error cases) and does not explain return values or side effects, which are important for a creation tool with no structured output information.

  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 description coverage is 100%, so the schema already documents all parameters (name, conditions, actions) thoroughly. The description adds some context by mentioning 'bio keywords, sector, username pattern' and use cases like 'watchlists,' but this does not significantly enhance the parameter semantics beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 with specific verbs ('create a custom classification rule') and resources ('auto-tag entities matching conditions'), and distinguishes it from siblings like frontrun_list_rules or frontrun_update_rule by focusing on creation rather than listing or updating. It explicitly mentions what the rule does (auto-tag entities) and provides concrete examples of use cases.

  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 clear context for when to use this tool ('build custom watchlists, sector taxonomies, or competitor tracking'), which helps differentiate it from other tools like frontrun_classify or frontrun_tag. However, it does not explicitly state when not to use it or name specific alternatives (e.g., frontrun_update_rule for modifications), which prevents a perfect score.

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

• frontrun_new_followsA
  3.7/5.0
  Behavior3/5

  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 describes the core mechanism ('diffing consecutive snapshots') and return format ('who each tracked account recently followed'), which is helpful. However, it doesn't mention important behavioral aspects like rate limits, authentication requirements, data freshness, or what happens when no new follows are found.

  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 perfectly concise with just two sentences. The first sentence explains what the tool does and how it works. The second sentence provides usage guidance. Every word earns its place with zero wasted text.

  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 3 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate but incomplete context. It explains the purpose and usage but lacks behavioral details (rate limits, auth needs) and doesn't describe the output format beyond 'who each tracked account recently followed.' Given the complexity and lack of structured output documentation, more completeness would be helpful.

  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 schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.

  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's purpose: 'Detect new follows across tracked accounts by diffing consecutive snapshots' and 'Returns who each tracked account recently followed.' It specifies the verb (detect/return) and resource (new follows), but doesn't explicitly differentiate from sibling tools like 'frontrun_enriched_follows' or 'frontrun_account_activity' which might have overlapping functionality.

  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 clear usage context: 'Use this to see what VCs/accounts noticed recently.' This gives a specific use case (monitoring VC/account attention) and timeframe (recently). However, it doesn't explicitly state when NOT to use this tool or mention specific alternatives among the many sibling tools.

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

• frontrun_convergenceA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It effectively communicates the tool's core behavior (detecting convergence patterns) and signal strength logic (higher threshold = stronger signal). However, it lacks details about output format, rate limits, authentication requirements, or what constitutes 'tracked accounts' versus regular accounts.

  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 perfectly concise and front-loaded. The first sentence establishes the core functionality, the second explains signal strength logic, and the third provides usage context - every sentence earns its place with zero wasted words.

  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 2-parameter tool with no annotations and no output schema, the description provides adequate but incomplete coverage. It explains the tool's purpose and signal logic well, but doesn't describe the output format, what 'entities' or 'tracked accounts' mean in this context, or how results are structured. Given the complexity of convergence detection, more context would be helpful.

  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?

  With 100% schema description coverage, the baseline is 3. The description adds meaningful context beyond the schema by explaining that 'higher threshold = stronger signal' and that '3+ VCs independently follow the same account' creates 'high-conviction signals.' This provides valuable semantic interpretation of the threshold parameter that isn't in the schema descriptions.

  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's purpose: detecting convergence when multiple tracked accounts independently follow the same entity within a time window. It specifies the verb ('detect convergence') and resource ('entities followed by multiple tracked accounts'), but doesn't explicitly differentiate from sibling tools like 'frontrun_trending' or 'frontrun_new_follows' that might also identify interesting patterns in follows.

  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 clear context on when to use this tool: for 'highest-signal endpoint' when seeking strong pre-funding interest signals, with explicit guidance that '3+ VCs independently follow the same account' indicates high conviction. However, it doesn't specify when NOT to use it or name alternative tools for different scenarios.

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

• frontrun_trendingA
  3.9/5.0
  Behavior3/5

  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 adds some context by specifying sorting ('Sorted by follower_count descending') and the practical use case, but it lacks details on rate limits, authentication needs, error handling, or what the output looks like (e.g., format, pagination). This is a moderate gap for a tool with no annotations.

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

  Conciseness5/5

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

  The description is appropriately sized and front-loaded, with two sentences that efficiently convey the tool's purpose and usage without any wasted words. Every sentence adds value, 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?

  Given the complexity (a ranking tool with 3 parameters), no annotations, and no output schema, the description is incomplete. It explains the purpose and usage but lacks details on behavioral traits (e.g., performance, errors) and output format, which are crucial for an agent to use it effectively. This is adequate but with clear gaps.

  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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain 'since' or 'classify' further), resulting in a baseline score of 3.

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

  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 with specific verbs ('Get entities ranked by number of tracked accounts that recently followed them') and resource ('entities'), distinguishing it from siblings like 'frontrun_new_follows' or 'frontrun_enriched_follows' by emphasizing ranking and trending analysis rather than raw data retrieval.

  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 clear context for usage ('Use this for daily deal flow — see what VCs are paying attention to'), indicating when to use it for trend analysis. However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, which would be needed for a score of 5.

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