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

No annotations are provided, so the description carries full burden. It discloses the return content ('complete post content, metadata, and URL') and source ('getrecon.xyz'), which adds useful context. However, it lacks details on error handling, rate limits, or authentication needs, leaving behavioral gaps for a tool with no annotation coverage.

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

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

The description is front-loaded with the core purpose, followed by return details and source. Both sentences earn their place by adding necessary information without redundancy, making it appropriately sized and efficient.

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

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

Given no annotations and no output schema, the description partially compensates by specifying return content and source. However, for a tool with no structured behavioral data, it lacks details on error cases, performance, or integration context, leaving it adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter 'slug' with an example. The description adds value by clarifying the parameter's role ('by its slug') and linking it to the blog post retrieval, but does not provide additional syntax or format details beyond the schema. With only one parameter, the baseline is high.

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

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

The description clearly states the specific action ('Get a full blog post'), identifies the resource ('blog post'), and specifies the lookup method ('by its slug'). It distinguishes from siblings like list_book_chapters or search_site by focusing on retrieval of a single complete item rather than listing or searching.

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

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

The description implies usage when you need a complete blog post identified by slug, but does not explicitly state when to use this tool versus alternatives like get_substack_post or search_site. No exclusions or prerequisites are mentioned, leaving usage context somewhat implicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns ('full chapter content, category, and URL'), which is helpful, but doesn't cover critical aspects like error handling (e.g., what happens if the slug is invalid), performance characteristics, or authentication needs. For a read operation without annotations, this leaves significant gaps in understanding the tool's behavior.

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

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

The description is appropriately sized and front-loaded, starting with the core purpose. The second sentence adds useful return details, and the third provides source and coverage context. While efficient, the coverage list ('Covers: Chimera framework...') could be slightly trimmed for brevity, but overall, it avoids unnecessary fluff.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is moderately complete. It explains the purpose, returns, and source, but lacks details on error cases, response format beyond listed fields, or integration with siblings. For a simple read tool, this is adequate but has clear gaps in operational context.

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

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

The description mentions the 'slug' parameter and provides context about what it represents (e.g., examples like 'chimera-framework'), adding meaning beyond the schema's 100% coverage. However, it doesn't elaborate on slug format constraints or provide additional parameter details, so it meets the baseline for high schema coverage without fully compensating with extra insights.

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

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

The description clearly states the tool's purpose: 'Get a book documentation chapter by slug' specifies the verb (get), resource (book documentation chapter), and key parameter (slug). It distinguishes from siblings like 'get_book_concept' or 'list_book_chapters' by focusing on individual chapter retrieval. However, it doesn't explicitly contrast with all similar siblings, keeping it from a perfect score.

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

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

The description implies usage by mentioning the source ('book.getrecon.xyz') and coverage areas (e.g., 'Chimera framework'), suggesting when this tool is relevant. However, it lacks explicit guidance on when to use this versus alternatives like 'get_book_concept' or 'search_book', and doesn't specify prerequisites or exclusions, leaving some ambiguity for the agent.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about response format, error handling, authentication needs, rate limits, or whether it's a read-only operation. For a tool with zero 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.

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

The description is appropriately sized with two sentences: the first states the core purpose, and the second enumerates covered concepts. It's front-loaded with the main function and avoids unnecessary elaboration. The concept list could be slightly overwhelming but serves a clear informational purpose.

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

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

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is adequate but incomplete. It explains what concepts are available but doesn't cover behavioral aspects or output format. For a concept lookup tool, users need to know what kind of explanation to expect, which is missing here.

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

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

Schema description coverage is 100%, so the schema already documents the single 'slug' parameter with examples. The description adds value by listing specific concept topics that correspond to valid slugs, providing semantic context beyond the schema's technical definition. This justifies a baseline score of 3 since the schema does the heavy lifting but the description enhances understanding.

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

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

The description clearly states the verb 'Get' and resource 'technical concept explanation from the Recon Book', making the purpose specific and actionable. It distinguishes from siblings by focusing on concepts rather than chapters, posts, or search operations, and provides a comprehensive list of covered concepts to clarify scope.

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

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

The description implies usage context by specifying 'technical concept explanation from the Recon Book' and listing covered topics, which helps differentiate it from siblings like get_blog_post or get_book_chapter. However, it doesn't explicitly state when not to use this tool or name specific alternatives for overlapping functions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns (entities, strengths, conclusion, FAQs) and the source (getrecon.xyz), but doesn't address important behavioral aspects like error handling, rate limits, authentication requirements, or whether this is a read-only operation. The mention of 'source' adds some context but 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.

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

The description is appropriately concise with two sentences that each serve a purpose: the first states the core functionality and return values, the second provides source attribution. It's front-loaded with the main purpose. However, the second sentence about the source could be integrated more smoothly with the first.

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

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

For a single-parameter read operation with no output schema, the description provides basic completeness by stating what's returned. However, it lacks important context about the return format structure, error conditions, or how to interpret the returned data. Without annotations or output schema, the description should do more to explain the tool's behavior and results.

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

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

Schema description coverage is 100% for the single parameter 'slug', which is well-documented in the schema. The description doesn't add any parameter information beyond what's already in the schema. This meets the baseline of 3 when schema coverage is high, but the description provides no additional parameter context or examples beyond the schema's example.

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

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

The description clearly states the tool's purpose: 'Get a comparison article by slug' specifies the verb (get) and resource (comparison article). It distinguishes from siblings like get_blog_post or get_book_chapter by focusing on comparison articles. However, it doesn't explicitly differentiate from search tools that might also retrieve comparison content.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose get_comparison over search_all, search_site, or other search tools that might find comparison articles. There's no context about prerequisites, limitations, or appropriate scenarios for use.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return data (title, author, date, content) and source context (getrecon.substack.com with 36 posts), which adds useful behavioral context. However, it lacks details on error handling (e.g., what happens if the slug is invalid), performance aspects (e.g., latency), or other operational traits, leaving some gaps 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.

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

The description is appropriately sized and front-loaded, starting with the core purpose ('Get a full Substack post by slug') followed by return details and source context. Both sentences earn their place by adding value, but the second sentence could be slightly more concise by integrating the source info more tightly, preventing a perfect score of 5.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete: it covers purpose, return values, and source context. However, without an output schema, it should ideally describe the return structure more formally (e.g., data types or format), and it lacks error handling details, making it not fully comprehensive for a score of 5.

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

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

The input schema has 100% description coverage, with the 'slug' parameter well-documented in the schema (including examples). The description does not add any additional parameter semantics beyond what the schema provides, such as explaining the slug format or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3 even without extra param info in the description.

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

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

The description clearly states the specific action ('Get a full Substack post by slug') and resource ('Substack post'), distinguishing it from siblings like 'list_substack_posts' (which lists posts) and 'search_substack' (which searches). It explicitly mentions what is returned (title, author, date, content), making the purpose unambiguous and well-differentiated.

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

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

The description provides clear context for when to use this tool ('Get a full Substack post by slug'), implying it's for retrieving a specific post rather than listing or searching. However, it does not explicitly state when not to use it or name alternatives (e.g., 'list_substack_posts' for browsing or 'search_substack' for finding posts by query), 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.

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

With no annotations provided, the description carries full burden. It discloses the grouping behavior (by category) which is valuable context beyond basic listing. However, it doesn't mention other behavioral traits like whether results are paginated, sorted, cached, or if there are rate limits. The description adds some value but leaves gaps.

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

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

The description is a single, efficient sentence that immediately states the core functionality and provides the complete categorization scheme. 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.

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

For a zero-parameter tool with no annotations and no output schema, the description provides adequate context about what the tool does and how results are organized. However, it doesn't describe the return format, data structure, or what information each chapter entry contains, which would be helpful given the lack of output schema.

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

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

The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's behavior and output characteristics.

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

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

The description clearly states the specific action ('List all chapters') and resource ('in the Recon Book'), and distinguishes this tool from siblings like 'get_book_chapter' (which retrieves a single chapter) and 'search_book' (which searches content). It provides explicit grouping information that further clarifies scope.

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

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

The description implicitly suggests usage when needing a categorized overview of all chapters, but doesn't explicitly state when to use this versus alternatives like 'search_book' or 'get_book_chapter'. It provides clear context about the grouping structure, but lacks explicit exclusion criteria or direct sibling comparisons.

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

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

No annotations are provided, so the description carries full burden. It discloses the output fields (title, subtitle, date, word count, slug) but lacks behavioral details such as pagination, rate limits, authentication needs, or error handling. For a list 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.

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 all Recon Substack newsletter posts') and adds useful details (sorting, output fields) without waste. Every word earns its place, making it highly concise and well-structured.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description covers the basic purpose and output fields adequately. However, it lacks completeness for a list operation by omitting behavioral context like pagination or data freshness, which could be important for an AI agent to use it effectively.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and output. Baseline is 4 for zero parameters, as it avoids unnecessary details.

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

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

The description clearly states the specific action ('List all'), resource ('Recon Substack newsletter posts'), and scope ('sorted by date'). It distinguishes from siblings like 'get_substack_post' (singular retrieval) and 'search_substack' (filtered search) by emphasizing comprehensive listing without filtering.

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

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

The description implies usage context by specifying it lists 'all' posts sorted by date, which suggests this tool is for browsing the full collection rather than targeted retrieval. However, it does not explicitly state when to use alternatives like 'get_substack_post' for single posts or 'search_substack' for filtered results, missing explicit exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by specifying the return limit ('up to 20 tools') and the content included ('descriptions and URLs'), which helps set expectations. However, it doesn't cover aspects like pagination, error handling, or performance characteristics.

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

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

The description is a single, well-structured sentence that efficiently conveys the action, resource, limit, and output details without any wasted words. It is front-loaded and appropriately sized for the tool's simplicity.

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

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

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and the output format, but without annotations or output schema, it lacks details on error cases, rate limits, or full behavioral context, making it minimally viable.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by clarifying the tool's scope and output, which compensates for the lack of parameters, earning a baseline score above the minimum.

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

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

The description clearly states the verb 'List' and the resource 'all developer tools documented on getrecon.xyz', making the purpose specific and understandable. It distinguishes from siblings like 'search_all' or 'search_site' by focusing on listing rather than searching, though it doesn't explicitly compare to them.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'search_all' or 'search_site', nor does it mention any prerequisites or exclusions. It implies usage for listing tools but lacks explicit context for selection among siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the action is a forced refresh (implying mutation), it affects all three sources, and it includes a critical rate limit ('once per 60 seconds'). However, it doesn't cover aspects like error handling or response format.

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

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

The description is a single, efficient sentence that front-loads the core action ('force refresh the documentation cache') and includes essential details (sources and rate limit) without any wasted words. Every part earns its place.

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

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

Given the tool's moderate complexity (a mutation with rate limits), no annotations, and no output schema, the description is mostly complete. It covers the purpose, scope, and a key behavioral constraint (rate limit), but lacks details on what 'refresh' entails operationally or what the response looks like.

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

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

The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description adds no parameter-specific information, which is appropriate given no parameters exist, maintaining the baseline score.

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

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

The description clearly states the specific action ('force refresh') and the target resource ('documentation cache'), explicitly listing all three sources (getrecon.xyz, book.getrecon.xyz, getrecon.substack.com). It distinguishes this tool from siblings like 'get_blog_post' or 'search_all' by focusing on cache management rather than content retrieval.

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

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

The description provides clear context for when to use this tool ('force refresh the documentation cache'), but does not explicitly state when not to use it or name alternatives. It implies usage when cached documentation needs updating, though lacks exclusions like avoiding use during high traffic.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the scope of content searched, the return format ('top 15 matches with source labels'), and the specific domains covered. It doesn't mention rate limits, authentication needs, or pagination behavior, but provides substantial operational context beyond basic functionality.

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

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

The description is perfectly front-loaded with the core functionality in the first clause, followed by specific domain details and return format. Every sentence earns its place by providing essential information about scope, sources, and results without any wasted words or redundancy.

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

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

Given the tool's moderate complexity (single parameter search across multiple domains) and no output schema, the description provides strong contextual completeness. It clearly explains what content is searched, what domains are included, and what the return format looks like. The main gap is the lack of output schema, but the description compensates well by specifying the return format details.

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

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

The input schema has 100% description coverage with the single 'query' parameter well-documented. The description doesn't add any additional parameter semantics beyond what the schema already provides. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no parameter information in the description.

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

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

The description clearly states the specific action ('Search across ALL Recon content') and identifies the exact resources covered (blog, glossary, comparisons, tools, chapters, concepts, FAQs, newsletter posts). It explicitly distinguishes this tool from its siblings by emphasizing the comprehensive 'ALL' scope versus the more targeted sibling tools like search_book or search_substack.

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

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

The description provides explicit guidance on when to use this tool: for searching across all Recon content sources. It implicitly suggests alternatives by naming specific sibling tools (e.g., search_book, search_substack) that would be more appropriate for targeted searches within single domains, though it doesn't explicitly state 'when not to use' this tool.

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

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

No annotations are provided, so the description carries full burden. It discloses the result limit ('top 10 matches') and source ('book.getrecon.xyz'), but doesn't mention important behavioral aspects like whether this is a read-only operation, performance characteristics, error handling, or authentication requirements. For a search tool with zero annotation coverage, 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.

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

The description is appropriately concise with two sentences that each add value. The first sentence states the purpose and scope, the second adds behavioral context (result limit and source). No wasted words, though it could be slightly more structured.

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

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

Given the tool's moderate complexity (search operation with one parameter), no annotations, and no output schema, the description provides basic completeness. It covers what the tool searches and result limitations, but lacks details about return format, error cases, or how it differs from sibling search tools. Adequate but with clear gaps.

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

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

Schema description coverage is 100% (the single parameter 'query' is fully documented in the schema as 'The search query'). The description doesn't add any parameter-specific information beyond what's in the schema. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't need to.

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

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

The description clearly states the tool's purpose: 'Search across Recon Book documentation (chapters, concepts, FAQs)' with a specific verb ('Search') and resource ('Recon Book documentation'). It distinguishes from some siblings like 'get_book_chapter' (retrieves specific chapter) and 'list_book_chapters' (lists chapters), but doesn't explicitly differentiate from other search tools like 'search_all' or 'search_site'.

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

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

The description provides minimal usage guidance. It mentions 'Returns top 10 matches' which implies a limitation, but doesn't specify when to use this tool versus alternatives like 'search_all' or 'search_site'. No explicit when/when-not instructions or prerequisite context is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds some context: it specifies the return format ('top 5 matching glossary terms with full definitions') and the data source ('getrecon.xyz'), which are useful beyond basic functionality. However, it lacks details on error handling, rate limits, or authentication needs, leaving gaps for a tool with no annotation support.

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

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

The description is highly concise and well-structured in two sentences. The first sentence clearly states the tool's purpose, and the second adds valuable context about returns and source. Every sentence earns its place without redundancy, making it easy for an agent to parse quickly.

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

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

Given the tool's low complexity (one parameter, no annotations, no output schema), the description is moderately complete. It covers the basic action and return format but lacks output schema details (e.g., structure of returned terms) and deeper behavioral context. For a simple search tool, this is adequate but leaves room for improvement in guiding agent usage.

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

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

The input schema has 100% description coverage, with the single parameter 'query' documented as 'The search query to find glossary terms.' The description does not add any additional meaning beyond this, such as query syntax examples or search behavior nuances. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.

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

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

The description clearly states the tool's purpose: 'Search the Recon glossary for terms matching a query.' It specifies the verb ('search'), resource ('Recon glossary'), and scope ('terms matching a query'), making the intent unambiguous. However, it does not explicitly differentiate this glossary search from sibling tools like 'search_all' or 'search_book', which could help an agent choose between similar search functions.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the source ('getrecon.xyz'), but does not indicate scenarios where this glossary search is preferred over other search tools (e.g., 'search_all' or 'search_book') or when it might be inappropriate. Without such context, an agent must infer usage based on tool names alone.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns top 10 matches, which is useful context about result limiting. However, it doesn't disclose important behavioral aspects like whether this is a read-only operation, authentication requirements, rate limits, search algorithm characteristics, or what happens with empty/no results.

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

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

The description is extremely concise - a single sentence that efficiently communicates the search scope and result limitation. Every word earns its place with zero wasted text, and the most important information (what's searched and result count) is front-loaded.

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

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

For a search tool with 1 parameter, 100% schema coverage, and no output schema, the description provides adequate basic information about scope and result limitation. However, given the multiple sibling search tools and lack of annotations, it should ideally clarify differentiation from alternatives and mention more behavioral aspects to be truly complete.

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

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

Schema description coverage is 100% with the single 'query' parameter fully documented. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

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

The description clearly states the tool searches across getrecon.xyz content types (blog posts, glossary, comparisons, tools) and returns top 10 matches. It specifies both the action (search) and resource scope (multiple content types), though it doesn't explicitly differentiate from sibling search tools like search_all, search_book, search_glossary, or search_substack.

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

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

The description provides no guidance on when to use this tool versus the multiple sibling search tools (search_all, search_book, search_glossary, search_substack). It doesn't indicate whether this is a general search across all content types or if there are specific scenarios where it's preferred over the more specific search tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it searches 'across all Recon Substack posts', returns 'top 10 matches', and specifies the output format ('titles, dates, and content snippets'). However, it doesn't mention search algorithm, ranking criteria, pagination, error conditions, or authentication needs.

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

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

The description is extremely concise (two sentences) and front-loaded with the core functionality. Every word earns its place: the first sentence defines scope and action, the second specifies output format and limit. No wasted words or redundant information.

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

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

Given the tool's moderate complexity (search operation with ranking and formatting), no annotations, and no output schema, the description provides basic but incomplete context. It covers what the tool does and what it returns, but lacks details about search behavior, error handling, and differentiation from similar tools, which would be helpful for an agent.

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

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

The input schema has 100% description coverage, with the single parameter 'query' documented as 'The search query'. The description doesn't add any parameter-specific information beyond what the schema provides, maintaining the baseline score of 3 for high schema coverage.

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

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

The description clearly states the tool's purpose: searching across Recon Substack posts and returning top 10 matches with specific fields (titles, dates, content snippets). It uses specific verbs ('Search', 'Returns') and identifies the resource ('Recon Substack posts'), but doesn't explicitly differentiate from sibling tools like 'search_all', 'search_book', or 'get_substack_post'.

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

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

The description provides no guidance on when to use this tool versus alternatives. With multiple search-related siblings (search_all, search_book, search_site) and content retrieval tools (get_substack_post, list_substack_posts), there's no indication of scope boundaries, use cases, or prerequisites.

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