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

No annotations are provided, and the description only states that it returns a JSON string with availability zones information. It does not disclose read-only behavior, authentication requirements, or any side effects. The description carries the full burden and 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 very short (two lines) and front-loaded with the purpose. However, it could be slightly more informative while still concise. It is not bloated, but it lacks detail.

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 the tool has no parameters and an output schema exists, the description is minimally adequate. However, it could mention that the output returns status information. Compared to the sibling complexity, it is incomplete in guiding the agent on when to use this tool.

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

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

The tool has zero parameters, so the schema already covers everything. The description adds no extra parameter information, but with no parameters, the baseline is 4. It does not detract but also does not add value beyond the schema.

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

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

The description states 'List availability zones and their status', which clearly indicates the action and resource. However, it does not explicitly differentiate from the sibling tool 'get_load_balancer_availability_zones', which could cause confusion despite being contextually different.

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, such as the load balancer-specific availability zones tool. There is no mention of prerequisites or 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?

No annotations are provided, so the description carries full burden. It describes read-only operations like listing and showing capacity, but does not explicitly state that the tool is non-destructive or has no side effects. It is clear enough but lacks explicit safety disclosure.

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

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

The description is concise with a clear header, bullet points for functions, example queries, and return type. It is front-loaded with the main purpose. Slightly verbose with 'Functions:' and 'Use when user requests:' but still 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 zero parameters and an existing output schema, the description provides sufficient context on what the tool does and what information it returns. It covers pool capacity and utilization, which is relevant for floating IP allocation.

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?

Input schema has no parameters, so the baseline is 4. The description adds value by explaining what the output contains (capacity information) and the purpose of the returned data.

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 it gets a list of floating IP pools, with specific verb 'Get' and resource 'floating IP pools'. It distinguishes from siblings like get_floating_ips by focusing on pools and capacity.

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 example user queries indicating when to use the tool, such as 'Show floating IP pools' and 'Check floating IP capacity'. However, it does not explicitly mention when not to use or alternatives 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?

No annotations are provided, so the description carries the behavioral transparency burden. The description adequately implies a read-only operation via the 'get' verb and lists what information is returned, but does not explicitly state that it is safe or describe any side effects.

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

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

The description includes some redundancy, with bullet points that essentially repeat the main function. It is structured but could be more concise.

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

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

The tool is simple with no parameters and has an output schema (indicated). The description mentions the return format and covers the necessary context for a straightforward list retrieval tool.

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 no parameters, so coverage is 100%. The description does not need to add parameter semantics. According to guidelines, zero-parameter tools have a baseline score of 4.

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

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

The description clearly states that the tool returns a list of floating IPs with associations. However, it does not explicitly differentiate from sibling tools like get_floating_ip_pools, which is a closely related tool.

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

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

The description provides usage context ('when user requests floating IP information, external connectivity queries, or IP management tasks'), but lacks exclusions or mention of alternative tools for specific scenarios.

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

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

With no annotations, the description carries full burden. It indicates a read-only operation and mentions return format (JSON) and functions (query status, timestamps, etc.), but lacks details on permissions, rate limits, or pagination 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?

Description is front-loaded with key purpose and includes a bullet list of functions, but has some redundancy (e.g., 'Get list' in title and description). Could be slightly more concise.

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

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

Given zero parameters and an output schema present, the description sufficiently explains what the tool does and returns. However, it does not mention if results are paginated or limited, which would enhance completeness.

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?

No parameters exist, so schema coverage is 100%. Description adds no param info, which is acceptable since there are none. Baseline 4 applies.

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

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

The description clearly states the verb 'Get' and resource 'list of Heat orchestration stacks', with specific functions listed. It distinguishes from sibling tools like get_instance or get_routers by focusing on orchestration stacks.

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

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

Explicitly states 'Use when user requests stack information, orchestration queries, or infrastructure-as-code status', providing clear context. However, it does not mention when not to use or suggest alternatives among the many 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?

Without annotations, the description only implies a read operation via 'Get' and mentions a JSON return. It lacks explicit disclosure of behavioral traits like read-only nature, performance characteristics, or prerequisites.

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 relatively concise and structured with separate sections for args and returns, though the 'Args' and 'Returns' labels are somewhat redundant when the parameter is already in the schema.

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

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

The description covers the return type but lacks specifics about what 'details and statistics' are included. It is adequate for a simple tool but could provide more depth.

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 0% schema coverage, the description compensates by explaining the parameter's meaning: it accepts a specific name/ID or 'all' for all hypervisors, adding value beyond the schema alone.

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 'detailed information about hypervisors', distinguishing it from sibling tools that target other resources.

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 explains the parameter usage (specific name or 'all'), but provides no guidance on when to use this tool over alternatives or when not to use it.

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 burden. It states the tool returns a comprehensive list with metadata but does not disclose potential volume, pagination, or performance implications. The read-only nature is implied by 'get' but not explicitly stated.

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 somewhat verbose with bullet points and a separate 'Returns' section that largely duplicates the initial sentence. It could be more concise by merging the first sentence and summary.

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 parameters and no annotations, the description adequately explains what the tool does and its output (metadata, properties, status). It does not mention pagination or rate limits, but for a simple list tool without filters, it is sufficient.

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

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

The tool has zero parameters, and schema coverage is 100% (trivially). The description adds value by confirming no input is needed and explaining the output scope ('all images'). This clarifies the tool's lack of filtering options, which is helpful.

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 explicitly states 'Get detailed list of all images with comprehensive metadata' and lists specific functions (status, size, format). It clearly distinguishes from sibling tools which target other resources like volumes, instances, or load balancers.

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 usage context: 'Use when user requests image listing, image information, or image metadata details.' This clearly indicates when to invoke this tool, though it does not mention when not to use it or suggest alternatives.

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

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

With no annotations, the description fully discloses behavior: supports pagination (limit, offset), case-sensitive search, all_instances flag, detailed mode, and returns JSON with metadata. No contradictions; it's a read-only tool, and all filtering modes are explained.

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?

Well-structured with sections: summary, functions, usage, args, returns, examples. Front-loaded with purpose. Slightly verbose but justified by the number of parameters and complex behavior. Every sentence adds value.

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

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

Given 0 required parameters, 10 params, no annotations, and an existing output schema, the description covers all necessary aspects: param usage, return format, pagination, and examples. No gaps observed.

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 has 0% description coverage, but the description provides detailed 'Args' section with explanations, defaults, and examples for all 10 parameters. Adds significant meaning beyond the schema's property types.

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?

Clearly states it's a unified tool for all instance retrieval patterns, listing specific functions like get by names/IDs, filter by status, search, and list all. Distinguishes itself from sibling tools by consolidating get_instance_details, get_instance_by_name, get_instances_by_status, and search_instances.

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

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

Explicitly says to use when user requests instance information, status checks, or searches, but does not provide when-not-to-use or alternative tools beyond the consolidation statement. Sibling list is available externally, but the description itself lacks 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?

No annotations exist, so the description must disclose behavioral traits. It states the tool returns 'detailed information or error message if not found,' which is minimal. It does not mention any side effects, idempotency, rate limits, or authentication requirements, leaving significant gaps for an unannotated tool.

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

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

The description is extremely concise: one sentence for purpose plus standard Args/Returns structure. Every sentence is earned and no fluff exists.

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 is simple with one parameter and an implied output schema, the description covers the basics. However, in a context with 40+ sibling tools, it lacks guidance on how this tool relates to similar ones like 'get_instance,' reducing completeness.

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

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

The schema has 0% coverage (no description for the parameter), but the description's Args section explicitly documents 'instance_name: Name of the instance to retrieve,' adding meaning beyond the schema type. While helpful, it is still minimal and does not provide format or constraints.

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 'Get detailed information for a specific instance by name,' which clearly identifies the action and resource. It is specific enough to distinguish from sibling tools like 'get_instance' (likely by ID) and 'search_instances' (possibly broader search), though it does not explicitly contrast 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_instances' or 'get_instance'. No prerequisites, use cases, or exclusions are mentioned.

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

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

The description discloses pagination support, configurable limits, and warns about include_all in large environments. No annotations provided, so this is helpful. It does not explicitly state it is read-only, but that's implied.

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

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

The description is structured but includes a bullet list of functions that is somewhat redundant; the core information could be conveyed in fewer words. Still, it is not overly long.

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 (6 params, many siblings, output schema exists), the description covers purpose, usage, parameters, and return type. It is missing explicit guidance on when to choose this over similar 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?

All 6 parameters are explained in the Args section with descriptions that add meaning beyond the schema. For example, explaining comma-separated lists and the behavior of all_instances and include_all.

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 it provides detailed information for OpenStack instances with specific aspects listed (name, ID, status, etc.), making the purpose clear. However, it does not explicitly differentiate from siblings like get_instance or search_instances, which also provide instance details.

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 includes a use case statement ('Use when user requests specific instance information...'), but does not provide guidance on when not to use it or mention 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.

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

No annotations are provided, so the description must disclose behavior. It explains the return value (list of instances) but does not mention pagination, error handling, or performance characteristics. For a simple filter, this is acceptable but minimal.

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

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

The description is extremely concise with only three sentences, yet it includes clear 'Args' and 'Returns' sections. Every word is purposeful, and the structure is well-organized, 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 simplicity (one required parameter, no nested objects) and the presence of an output schema, the description covers the basic purpose. However, it lacks contextual cues about when to prefer this tool over similar ones, limiting completeness for an agent unfamiliar with the domain.

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

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

The schema has 0% description coverage, so the description must add meaning. It lists example status values (ACTIVE, SHUTOFF, etc.) but does not specify if the list is exhaustive or provide format details. This adds some value but is insufficient for full 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 retrieves instances filtered by status, with a specific verb and resource. It distinguishes from siblings like get_instance (single instance) but does not explicitly differentiate from search_instances, which may offer more flexible 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 provides no guidance on when to use this tool versus alternatives. There is no mention of when not to use it or comparison with similar tools like search_instances, leaving the agent to infer optimal 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 full burden. It describes the return content (fingerprints, types, dates, truncated public key) but does not explicitly state that the operation is read-only or any authentication requirements. The name implies a read operation, but transparency is moderate.

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

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

The description is well-structured with bullet points and sections (Functions, Use when, Returns). It is concise and front-loaded with the main purpose. Minor redundancy could be trimmed but overall 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?

For a tool with no parameters and an output schema (implied), the description covers the purpose, usage scenarios, and return content. Missing explicit read-only declaration or auth notes, but it is generally complete for a simple list tool.

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?

No parameters exist, so schema coverage is 100%. The description adds context about the returned fields (fingerprints, types, dates), which adds value beyond the empty 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 states 'Get list of SSH keypairs for the current user' which is a clear verb+resource combination. It further enumerates specific information returned (fingerprints, types, dates, public key). Among sibling tools, this is distinct from other get_* tools (e.g., get_security_groups, get_volume_list).

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

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

The description explicitly says 'Use when user requests SSH key management, keypair information, or security key queries.' This provides clear context, though it does not mention when not to use or alternatives.

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 provided; the description indicates it is a read operation returning JSON, but lacks details on error conditions, authentication, or performance impacts, leaving 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 concise but includes structured sections (Args, Returns) which slightly lengthen it; however, every part is informative and not wasteful.

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 one parameter and no annotations, the description adequately covers purpose and return format. It could mention potential pagination or limits, but overall sufficient for a simple list tool.

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

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

The single parameter 'lb_name_or_id' is well-described: optional, can be name or ID, and default behavior when empty. This adds significant value beyond the bare schema type 'string'.

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

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

The description clearly states the tool retrieves amphora instances for a specific load balancer or all amphorae if no ID provided, distinguishing it from sibling tools like get_load_balancer_details or get_load_balancer_list.

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 explains the optional parameter and its default behavior, but does not provide guidance on when to use this tool over alternatives among the many sibling load balancer 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 present, so the description should disclose behavioral traits. It only states it returns a JSON string, but does not indicate if the operation is read-only, requires authentication, or has any side effects.

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

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

The description is extremely concise with two sentences and no wasted words. It is front-loaded with the 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 no parameters and an existing output schema, the description is minimal but could be more helpful by clarifying the scope relative to the sibling tools and the meaning of availability zones in this 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 tool has no parameters, so the schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, but given the lack of parameters, it is minimally sufficient.

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 'load balancer availability zones', making the purpose apparent. However, it does not differentiate from the sibling tool 'get_availability_zones', which may cause confusion.

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, such as get_availability_zones. There is no mention of prerequisites or context 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?

No annotations provided, so description carries full burden. Describes what information is returned but does not explicitly state that it is a read-only operation or disclose any side effects, authentication needs, or rate limits. Adequate but not comprehensive.

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

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

Well-structured with a main sentence followed by bullet lists for functions and use cases, plus explicit Args and Returns sections. Front-loaded with purpose, but bullet lists could be slightly more concise.

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

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

Given the tool has 1 parameter with good semantic coverage and a promised output schema, the description adequately explains what the tool does and how to call it. It is complete for the complexity level.

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 has 0% description coverage, but the description adds meaning: 'lb_name_or_id: Load balancer name or ID to query'. This clarifies that the parameter accepts both name and ID, beyond the schema's minimal type definition.

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?

Clearly states it retrieves detailed information about a specific OpenStack load balancer, listing specific components like VIP, listeners, pools, members, and health monitors. Distinguishes from sibling tools that focus on individual components.

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

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

Provides explicit use case examples like 'Show details for load balancer [name/id]' and 'What's the status of load balancer [name]?'. Does not explicitly state when not to use, but the specificity implies alternatives exist for narrower queries.

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 provided and the description only states it returns a JSON string. It lacks disclosure of behavioral traits such as read-only nature, authentication needs, or performance characteristics. The word 'Get' implies read-only, but no explicit details.

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

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

The description is concise with two sentences, front-loading the purpose. It could be slightly more structured but is not verbose.

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 parameters and presence of an output schema, the description is mostly adequate. However, it does not explain what 'flavors' are or how the result relates to other load balancer operations, which could help overall 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?

With zero parameters and 100% schema coverage, the description adds minimal value but does not need to. Baseline for 0 parameters is 4; the description confirms there are no inputs, which is consistent.

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 explicitly states 'Get load balancer flavors', clearly identifying the verb and resource. It distinguishes from sibling tools like get_load_balancer_amphorae or get_load_balancer_availability_zones.

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 on when to use this tool versus alternatives. The description does not specify context, prerequisites, or exclude cases, 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.

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

With no annotations provided, the description covers behavioral aspects well: it mentions the tool lists monitors, shows types and settings, returns a JSON string, and can be filtered by pool. This is sufficient for a read-only operation.

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

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

The description is well-structured with a summary, bullet points, usage examples, and argument/return details. It is slightly verbose but each sentence adds value, making it effective without being overly long.

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

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

The description covers the tool's core functionality, parameter, and return format. Given the simple input schema and presence of an output schema, it is adequately complete. It could mention error cases or pagination, but these are not critical for a basic list tool.

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

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

The schema has 0% description coverage, but the tool description adds meaning: 'Optional pool name or ID to filter monitors (empty for all)'. This clarifies the parameter's purpose beyond the schema's type-only definition.

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 'Get health monitors, optionally filtered by pool' and lists specific functions. It distinguishes from sibling 'get_load_balancer_*' tools by focusing on health monitors, making the tool's purpose unambiguous.

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

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

The description provides explicit usage examples like 'Show all health monitors' and 'List health monitors for pool [name/id]', giving clear context. However, it does not mention when not to use this tool or point to alternatives 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?

The description discloses the return format (JSON string with policy details, actions, rules), but with no annotations provided, it fails to mention permissions, read-only nature, or error handling. 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 concise, with the main purpose stated first, followed by a structured Args and Returns section. No unnecessary 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 simple structure (one optional parameter, no nested objects) and presence of an output schema, the description covers purpose, parameter, and return value adequately. It could mention error cases or permissions but is largely 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?

With 0% schema description coverage, the description fully explains the parameter's purpose, optionality, and default behavior (shows all policies if empty). This adds significant meaning beyond the raw schema.

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

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

The description clearly states the tool retrieves L7 policies, optionally filtered by listener, using a specific verb 'Get' and resource 'L7 policies'. It distinguishes from siblings like get_load_balancer_l7_rules and get_load_balancer_listeners.

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 explains when to use the optional listener filter and the effect of omitting it, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, so it is not a 5.

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

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

With no annotations provided, the description carries the full burden. It describes the return format (JSON string with rule types, values, conditions) but does not disclose whether the operation is read-only, requires special permissions, or has any side effects. It adds moderate context but lacks full behavioral details.

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

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

The description is concise with two short paragraphs (overview and Args/Returns). Every sentence serves a purpose, and the structure is clear. However, it could be slightly more compact by integrating the Args/Returns into prose.

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 (single required param, no nested objects, existing output schema), the description covers the essential points: what it does, what the parameter means, and what it returns. Minor gaps include no discussion of error cases or empty results, but overall it is sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It only restates that 'policy_name_or_id' is required without providing format hints, examples, or constraints beyond the schema's bare string type. This adds minimal value over the schema itself.

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 'Get L7 rules for a specific L7 policy,' specifying the verb (Get), resource (L7 rules), and constraint (specific policy). This distinguishes it from sibling tools like get_load_balancer_l7_policies which retrieves policies, not rules.

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 L7 rules for a known policy, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While it mentions 'specific L7 policy', it doesn't clarify that the policy must be obtained via another tool (e.g., get_load_balancer_l7_policies) first.

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 provided, so description carries full burden. Describes pagination (limit/offset), include_all option, and what information is displayed (VIP, status, listeners, provisioning status). Does not mention authentication or side effects, but as a read-only list, this is sufficient.

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?

Well-organized with clear sections: functions, use cases, args, returns. Every sentence adds value; no fluff. Front-loaded with 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?

Has output schema, so detailed return structure is covered elsewhere. Description notes returns 'JSON string containing load balancer details with summary statistics', which suffices. Complete for a list tool.

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

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

Schema coverage is 0% (only defaults and types). Description's 'Args' section explains each parameter: limit (1-200, default 50), offset (default 0), include_all (default False). Adds context missing from 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?

Description specifies 'Retrieve comprehensive list of OpenStack load balancers with detailed information' and lists functions like listing all LBs, showing VIP/status/listeners. This clearly distinguishes it from sibling tools like get_load_balancer_details (single LB) or get_load_balancer_listeners (listeners only).

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

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

Provides explicit use cases with example user requests ('Show me all load balancers'). Lacks explicit when-not-to-use or alternatives, but the context is clear enough for an AI to decide.

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 details the output fields (protocols, ports, configurations, timestamps) and states the return type (JSON string). While it does not mention rate limits or error handling, the behavioral traits are adequately disclosed for a read-only operation.

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 structured with a main sentence, bullet lists for functions and example uses, then Args and Returns sections. It is well-organized and front-loaded. Minor redundancy exists between the initial sentence and the first bullet point, but overall it is concise enough.

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 only one parameter and an output schema exists, the description is sufficiently complete. It covers the tool's purpose, input, and output details. It does not mention behavior for nonexistent load balancers or permission issues, but for a simple get operation this is acceptable.

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% description coverage, so the description must add meaning. It states that lb_name_or_id accepts 'Load balancer name or ID', which clarifies the parameter's purpose. However, it does not specify how the tool distinguishes between names and IDs or any format requirements, leaving some ambiguity.

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 'Get listeners for a specific OpenStack load balancer' and lists specific functions like listing all listeners and showing protocols. The tool's purpose is distinct from sibling load balancer tools such as get_load_balancer_health_monitors or get_load_balancer_pools.

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 example user requests (e.g., 'Show listeners for load balancer [name/id]') that clarify when to use the tool. However, it does not explicitly state when not to use it or suggest alternative tools for related tasks like retrieving health monitors or pools.

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

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

The description details what data is returned: member addresses, ports, weights, health status, admin state, operational status, and monitor configuration, and states it returns a JSON string. Without annotations, this provides adequate behavioral context, though it does not mention read-only nature or potential errors.

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

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

The description is well-structured with clear headings (Functions, Use when user requests, Args, Returns) and uses bullet points for readability. It is concise, containing only relevant information without 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?

The tool has an output schema (not shown), so the description's high-level summary of return values is sufficient. It mentions key fields like addresses, ports, and health status, covering expected outputs. A minor gap is the lack of explicit mention of pagination or limits, but not critical given the 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 input schema only names 'pool_name_or_id' without description. The description compensates by explaining it as 'Pool name or ID to query members for' and listing example queries that illustrate usage. This adds essential meaning, especially given 0% 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 'Get members for a specific OpenStack load balancer pool' and lists specific functions like listing members and showing addresses, ports, weights, and health status. It also provides example user requests, making the purpose unambiguous and distinct from sibling tools.

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 includes explicit use cases with four example queries (e.g., 'Show members for pool [name/id]'), providing clear context for when to invoke the tool. However, it does not explicitly exclude usage or suggest alternatives, such as when to use a different load balancer tool.

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

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

With no annotations, the description fully carries behavioral disclosure. It details that the tool lists pools, shows protocols, algorithms, members with status, and health monitor associations, and returns JSON. No contradictions.

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?

Description is well-structured with a summary line, bullet list of functions, usage examples, args, and returns. It is concise without unnecessary repetition, though slightly verbose in listing functions.

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 simple tool with 1 optional parameter and an output schema existing, the description covers purpose, behavior, parameter meaning, and return format comprehensively. No 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 has 0% description coverage, but description adds meaning: 'Optional listener name or ID to filter pools'. However, it lacks format details or examples that would further clarify usage, so baseline 3 is appropriate.

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

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

Description clearly states it gets load balancer pools, optionally filtered by listener. It explicitly lists functions like listing pools, showing protocols, members, and health monitors, distinguishing it from sibling tools such as get_load_balancer_list or get_load_balancer_pool_members.

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?

Description provides explicit usage examples like 'Show all load balancer pools' and 'List pools for listener [name/id]', guiding when to use. However, it does not mention alternatives or when not to use this tool despite ample sibling tools.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It only states that the tool returns a JSON string, omitting any side effects, authentication needs, or rate limits. As a read operation, it lacks necessary 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.

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

The description is extremely concise, using a single sentence and a line about the return type. It is front-loaded and contains no unnecessary words, earning its place efficiently.

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 no parameters and an output schema exists, the description is nearly complete for its simplicity. However, it could briefly explain what load balancer providers are to improve completeness.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter meaning, but it correctly implies no input is required.

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

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

The description clearly states the tool gets load balancer providers, with a specific verb and resource. It distinguishes it from sibling tools which target other resources. However, it does not clarify what 'providers' means in this context.

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 on when to use this tool versus alternatives. The description does not mention any prerequisites or context where this tool is appropriate, leaving the agent without decision criteria.

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, and the description only states it returns a JSON string without mentioning safety (e.g., read-only), authentication needs, or error handling. The description does not go beyond basic purpose.

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, using two sentences plus structured Args/Returns sections. Every word is functional with no redundancy.

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

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

The tool is simple with one optional parameter and an output schema. The description adequately covers the behavior and return format. It is nearly complete, though missing potential edge cases (e.g., invalid project ID).

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 explains the 'project_id' parameter's behavior (optional, defaults to all projects if empty), adding meaning beyond the schema's type and default. With 0% schema description coverage, this compensates well, though only one parameter is present.

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 it retrieves load balancer quotas with a specific verb 'Get' and resource 'load balancer quotas', including scoping to a project or all projects. This distinguishes it from siblings like 'get_quota' which may cover different quota types.

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 explicit guidance is provided on when to use this tool versus alternatives. Given the presence of a sibling 'get_quota', the description lacks differentiation or context for when each is appropriate.

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 provided, so description must cover behavioral traits. It lacks any mention of read-only nature, permissions, side effects, or rate limits. Only states it returns JSON 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?

Well-structured with functions, usage, args, and returns sections. Slightly verbose but clear and front-loaded with 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?

Covers multiple resource types comprehensively. Output schema exists (though not shown), and description explains return format. Adequate for the tool's complexity.

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?

Description adds meaning to the sole parameter 'network_name' by explaining it can be a specific name or 'all' for all networks, with default 'all'. Schema had 0% coverage, so this compensates well.

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?

Clearly states it provides detailed information for OpenStack networks, subnets, routers, and security groups. Lists specific functions, distinguishing it from sibling tools like get_routers or get_security_groups which focus on individual resources.

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

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

Explicitly says when to use (network information, subnet details, etc.) but does not mention when not to use or alternatives like get_routers for router-only queries.

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?

Without annotations, the description must convey behavioral traits. It specifies that it is a read operation, returns a JSON string with details/roles/quotas, and notes the 'list all' behavior for empty parameter. This sufficiently covers the expected behavior for a simple read tool.

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

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

The description is concise and well-structured with clear sections for purpose, parameters, and return value. Every sentence adds value without 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 simplicity (one optional parameter, no nested objects, output schema present), the description adequately covers input, output, and behavior. Minor gap: no mention of error handling for nonexistent project, but overall sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains the only parameter 'project_name', including its purpose, optionality, and effect (lists all if empty). This adds all necessary meaning beyond the schema.

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

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

The description clearly states it retrieves OpenStack project details, with a CLI equivalent ('openstack project list/show') for reference. It distinguishes from sibling tools (none other target projects) and notes the optional filtering behavior.

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

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

The description indicates when to use (to get project details) and explains the optional parameter behavior (empty lists all). However, it lacks explicit guidance on when not to use or alternatives, but the sibling tool list does not contain a direct substitute.

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 burden of behavioral disclosure. It explains that the parameter is optional and defaults to the current project, and that the return is a JSON string. However, it does not mention potential errors (e.g., if the project does not exist), required permissions, or whether the operation is read-only (implied but not stated). The transparency is adequate but not exhaustive.

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

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

The description is concise, with a clear structure including an Args section and a Returns section. The purpose is stated in the first sentence, making it easy to scan. There is no redundant information, and every sentence contributes to understanding.

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