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 calculation purpose but lacks details on permissions, rate limits, error handling, or output format. It doesn't clarify if this is a read-only calculation or if it has side effects like caching results, which is insufficient for a tool with potential financial implications.

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 purpose without unnecessary words. It directly communicates what the tool does without redundancy or fluff, making it easy 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 complexity (tax calculation with financial implications), no annotations, and 0% schema description coverage, the description is incomplete. It lacks behavioral details and full parameter explanations. However, the presence of an output schema mitigates some gaps by presumably documenting return values, preventing a lower score.

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 'net taxable income and household composition,' which partially explains two of the four parameters (net_taxable_income and household_parts). However, with 0% schema description coverage, it doesn't address the 'year' parameter's purpose or the 'ctx' parameter's role, leaving significant gaps in parameter understanding.

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

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

The description clearly states the tool's purpose: calculating French income tax based on specific inputs. It specifies the verb ('calculate'), resource ('French income tax'), and key factors ('net taxable income and household composition'). However, it doesn't explicitly differentiate from sibling tools like 'generate_tax_report' or 'get_tax_brackets', which might also involve tax calculations.

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 sibling tools like 'get_tax_brackets' (which might provide rate information) or 'generate_tax_report' (which might produce formatted output), nor does it specify prerequisites or exclusions for usage.

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 mentions generating a 'detailed report' but doesn't specify if this is a read-only operation, whether it modifies data, requires authentication, has rate limits, or what the output entails (e.g., file creation, format defaults). This is a significant gap for a tool with 5 parameters and 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 a single, efficient sentence that front-loads the core action ('Generate a detailed report'). There's no wasted verbiage, but it could be more structured by hinting at key parameters or usage context. It's appropriately sized for a basic tool but lacks depth.

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

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

Given the complexity (5 parameters, nested objects, no annotations) and the presence of an output schema, the description is incomplete. It doesn't address behavioral aspects like mutation risks or auth needs, and while the output schema might cover return values, the description should still clarify the tool's role versus siblings and parameter semantics. For a tool with this level of complexity, it's inadequate.

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

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

Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters like 'tax_data', 'topic_name', 'output_file', 'format', or 'ctx', leaving their purposes, formats, or constraints unclear. For example, it doesn't explain what 'tax_data' should contain or how 'topic_name' relates to the report. This fails to compensate for the low 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 states the tool 'Generate[s] a detailed report about a specific tax topic', which provides a clear verb ('generate') and resource ('report'), but it's vague about what constitutes a 'detailed report' and doesn't differentiate from siblings like 'get_tax_article' or 'search_tax_law' that might also provide tax information. It's adequate but lacks specificity about the report's nature or format.

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

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

No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_tax_article' or 'search_tax_law', the description doesn't clarify if this is for synthesized reports, official documents, or user-specific analyses. There's no mention of prerequisites, such as needing tax data input, which is implied by the schema but not stated in the description.

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 mentions the tool retrieves 'cached' data as a fallback, which implies read-only behavior and potential staleness, but doesn't detail what 'cached' entails (e.g., freshness, source, update frequency), error handling, or performance traits. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational 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 a single, efficient sentence that front-loads the core purpose and context without unnecessary words. Every part ('Get cached tax information when web scraping fails') earns its place by clarifying the tool's role and usage scenario.

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

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

Given the tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is minimally adequate. It explains the tool's purpose and fallback context but lacks details on parameters, caching behavior, and error cases. For a retrieval tool with output schema support, it meets a basic threshold but could be more informative.

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

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

Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about the parameters ('tax_topic' and 'year'), such as what constitutes a valid tax topic, how the year affects retrieval, or examples. With 2 parameters and zero coverage, the description fails to compensate, leaving semantics unclear.

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 cached tax information when web scraping fails.' It specifies the verb ('Get'), resource ('cached tax information'), and context ('when web scraping fails'), which distinguishes it from siblings like 'get_tax_info_from_web' that likely fetch live data. However, it doesn't explicitly differentiate from other caching or retrieval tools beyond the context hint.

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: 'when web scraping fails,' implying it's a fallback mechanism. This distinguishes it from 'get_tax_info_from_web' (for live scraping) and other tax info tools. However, it doesn't specify when NOT to use it (e.g., if cached data is stale) or name explicit alternatives beyond the implied sibling.

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 the tool retrieves information, implying a read-only operation, but does not mention potential side effects, authentication needs, rate limits, or response format. For a 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 purpose without unnecessary details. It could be slightly more structured by including usage hints, but it earns its place by clearly stating what the tool does.

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 (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It states the purpose but lacks behavioral context and parameter guidance. The output schema reduces the need to explain return values, but the description should do more to compensate for missing annotations.

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 does not mention parameters at all, and schema description coverage is 0%, so it adds no meaning beyond the input schema. However, with only 2 parameters and an output schema present, the baseline is 3 as the schema handles the heavy lifting, though the description fails to compensate for the coverage gap.

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 ('detailed information about a specific tax form'), specifying what information is retrieved ('fields and instructions'). It distinguishes from siblings like 'get_tax_brackets' or 'get_tax_deadlines' by focusing on form details, though it could be more explicit about differentiation.

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 'get_cached_tax_info' or 'get_tax_info_from_web'. It implies usage for retrieving form details but lacks explicit context, exclusions, or prerequisites, leaving the agent to infer 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns structured data, or handles errors. The description adds minimal behavioral context beyond the basic action, leaving gaps for an AI agent.

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 with zero wasted words. It's front-loaded with the core purpose and includes the data source. Every part earns its place, making it easy to parse quickly without 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?

Given the tool's moderate complexity (retrieving specific legal information), no annotations, and an output schema (which handles return values), the description is minimally adequate. It states what the tool does and the source, but lacks details on parameters, behavioral traits, and usage context, leaving the agent to rely heavily on the output schema and inference.

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

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

Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'a tax law article' but doesn't explain the 'article_id' parameter (e.g., format, examples, or source) or the optional 'ctx' parameter. It adds minimal semantic value beyond what's inferable from the tool name, failing to compensate for the schema gap.

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 action ('Get information about') and the resource ('a tax law article from legifrance.gouv.fr'), which is specific and unambiguous. It doesn't explicitly differentiate from siblings like 'search_tax_law' or 'get_tax_info_from_web', but the focus on retrieving a specific article by ID is implied. No tautology with the name/title.

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_tax_law' or 'get_tax_info_from_web'. It mentions the source (legifrance.gouv.fr) but doesn't specify prerequisites, exclusions, or comparative contexts. Usage is implied only by the verb 'Get', with no explicit when/when-not instructions.

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 states what the tool does but doesn't describe traits like whether it's read-only, requires authentication, has rate limits, or what the output format is. The description is minimal and fails to compensate for the lack of annotations, leaving key behavioral aspects unspecified.

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 with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no redundant or verbose phrasing.

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

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

Given the tool's low complexity (1 optional parameter) and the presence of an output schema, the description is adequate but minimal. It covers the basic purpose but lacks details on behavior, usage context, and parameter nuances. The output schema likely handles return values, so the description doesn't need to explain those, but it should do more to guide the agent effectively.

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

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

The description mentions 'for a specific year', which aligns with the 'year' parameter in the input schema. However, schema description coverage is 0%, so the schema provides no details about the parameter. The description adds minimal semantics by indicating the parameter's purpose but doesn't explain format, constraints, or the null default. It partially compensates but not fully for the coverage gap.

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 the resource 'income tax brackets (tranches d'imposition)' with the scope 'for a specific year'. It distinguishes from siblings like 'calculate_income_tax' (which computes tax amounts) and 'get_tax_info_from_web' (which fetches broader information), but doesn't explicitly differentiate them. The purpose is specific and actionable, though not fully contrasted with alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'get_cached_tax_info' or 'get_tax_info_from_web'. It implies usage for retrieving bracket data by year, but lacks explicit when/when-not instructions or prerequisites. This leaves the agent to infer context without clear direction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get tax deadlines' but doesn't describe what the tool returns (e.g., list of deadlines, dates, formats), whether it requires authentication, rate limits, or if it's a read-only operation. For a tool with no annotation coverage, 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.

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

The description is extremely concise—a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly. Every word earns its place by specifying the action, resource, and source.

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 that there's an output schema (which handles return values), no annotations, and low schema coverage, the description is incomplete. It doesn't address behavioral aspects like authentication needs or rate limits, and with 0% schema coverage, it fails to explain parameters. However, the output schema mitigates some gaps, making it minimally adequate but with clear deficiencies.

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

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

Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'tax deadlines' but doesn't explain the 'year' parameter (e.g., optional filtering by year) or the 'ctx' parameter (context object). It adds minimal semantic value beyond the tool name, failing to compensate for the lack of schema descriptions.

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

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

The description clearly states the action ('Get') and resource ('tax deadlines from service-public.fr'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'get_tax_info_from_web' or 'get_cached_tax_info', which might also retrieve tax information, but it's specific about the type of information (deadlines) and source (service-public.fr).

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

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

No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_tax_info_from_web' and 'get_cached_tax_info', the description lacks context on whether this is for official deadlines, cached data, or web-scraped info. It doesn't mention prerequisites, exclusions, or comparisons to other tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation by using 'Get', but doesn't specify whether it involves web scraping, API calls, rate limits, authentication needs, or potential delays. This leaves critical behavioral traits undocumented for a tool interacting with external websites.

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 with zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose without unnecessary elaboration, making it easy 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 complexity (interacting with external websites), lack of annotations, and 0% schema coverage, the description is incomplete. While an output schema exists (which reduces the need to explain return values), the description doesn't cover behavioral aspects like data freshness, error handling, or usage constraints, leaving gaps for effective tool selection.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'tax information' and 'official French government websites', which loosely relates to 'tax_topic', but provides no details on format, examples, or constraints for either parameter. The 'year' parameter isn't addressed at all, failing to add meaningful semantics beyond the bare schema.

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

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

The description clearly states the action ('Get') and resource ('tax information') with specific sources ('official French government websites'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_tax_article' or 'get_cached_tax_info', which might retrieve similar information through different means.

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 prefer it over siblings like 'get_cached_tax_info' (for cached data) or 'get_tax_article' (for specific articles), nor does it specify prerequisites or exclusions, leaving usage context unclear.

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

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

No annotations are provided, so the description carries full burden. It mentions retrieving information from 'service-public.fr', implying an external API/web source, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what format the information returns. For a tool with external dependencies and no annotation coverage, this is insufficient.

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 states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be more front-loaded with distinguishing features if they existed.

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 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema reduces the need to explain return values, but the description lacks crucial context about external dependencies, error cases, and parameter usage that would be needed for reliable tool invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'tax procedure' which aligns with the 'procedure_name' parameter, adding semantic context about what kind of name to provide. However, it doesn't explain the 'ctx' parameter or provide format/example details for either parameter, leaving significant gaps in parameter understanding.

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

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

The description states the tool 'Get information about a tax procedure from service-public.fr', which provides a clear verb ('Get information') and resource ('tax procedure') with source context. However, it doesn't differentiate from sibling tools like 'get_tax_info_from_web' or 'get_tax_article', leaving ambiguity about what specific type of information or procedure scope this covers.

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 sibling tools for tax information retrieval (e.g., get_tax_info_from_web, get_tax_article, get_form_details), there's no indication of what distinguishes this procedure-focused tool from others, leaving the agent to guess 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?

No annotations are provided, so the description carries full burden. It mentions the tool is a 'simple health check' which implies a read-only, non-destructive operation, but doesn't explicitly state this. It doesn't describe response format, error conditions, rate limits, or authentication requirements that would be helpful for behavioral understanding.

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, clear sentence that gets straight to the point. It's appropriately sized for a simple health check tool with no wasted words 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 simple health check tool with an output schema (which presumably documents the response), the description is reasonably complete. However, it lacks information about what 'responsive' means, what constitutes a successful check, or what the tool actually tests. The presence of an output schema helps, but more behavioral context would be beneficial.

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?

With only one optional parameter (ctx) that has 0% schema description coverage, the description doesn't mention parameters at all. However, since this is a health check tool that likely needs no parameters to function, and the single parameter appears to be an optional context injection mechanism, the baseline of 4 is appropriate for a tool that effectively has zero required operational parameters.

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: 'Simple health check to verify the server is responsive.' It uses specific verbs ('check', 'verify') and identifies the resource ('server'). However, it doesn't distinguish from siblings since this appears to be the only health-related tool among tax-focused siblings.

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 prerequisites, timing considerations, or relationships to other tools. The agent must infer usage from the purpose 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 the full burden of behavioral disclosure. It states the tool searches for articles but doesn't describe what the search returns (e.g., list of results, full text, metadata), whether it's a read-only operation, any rate limits, authentication needs, or how results are formatted/paginated. This leaves significant gaps for an AI agent to understand 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content, making it easy for an AI 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 that there's an output schema (which should document return values), no annotations, and low schema coverage, the description is minimally adequate but incomplete. It specifies the source (legifrance.gouv.fr) but lacks details on behavior, parameters, and usage context that would help an AI agent invoke it correctly, especially compared to sibling tools.

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

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

Schema description coverage is 0%, meaning the schema provides no descriptions for the two parameters ('query' and 'ctx'). The description adds no information about what the 'query' parameter should contain (e.g., keywords, phrases, filters) or how the optional 'ctx' parameter is used. It fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.

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 action ('Search for tax law articles') and the target resource/source ('on legifrance.gouv.fr'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_tax_article' or 'get_tax_info_from_web', which might have overlapping purposes.

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 prefer this over siblings like 'get_tax_article' (which might retrieve specific articles) or 'get_tax_info_from_web' (which might search broader web sources), nor does it specify any prerequisites or exclusions for usage.

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