Server Quality Checklist

Tool Scores

• bank-searchC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects like what information is returned, whether it's a read-only operation, error handling, or any rate limits. The description is functional but lacks operational context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple search tool and front-loads the essential information.

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

  Completeness2/5

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

  For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned about Brazilian banks, what format the response takes, or any limitations. Given the lack of structured metadata, the description should provide more operational context.

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

  Parameters3/5

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

  The schema has 100% description coverage with the 'code' parameter clearly documented. The description adds minimal value beyond the schema by specifying this is for Brazilian banks, but doesn't provide additional context about code format, validation, or examples. Baseline 3 is appropriate given the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Find information') and resource ('Brazilian bank'), specifying the scope as Brazilian banks. However, it doesn't distinguish this tool from potential sibling 'bank-list' which might list banks rather than search by code, leaving some ambiguity about sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'bank-list' or other search tools in the sibling list. It mentions searching by code but doesn't specify when this is appropriate or what alternatives exist for different search criteria.

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

• ddd-infoC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states what the tool does ('Get information'), it doesn't describe behavioral traits like whether it's a read-only operation, potential rate limits, authentication needs, error handling, or what format the information is returned in. For a query tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Get information about a Brazilian area code') and adds specific details ('including state and cities'). There is zero wasted language, and every word earns its place by clarifying the tool's scope.

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

  Completeness2/5

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

  Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't address what the output looks like (e.g., JSON structure, possible fields), error conditions, or behavioral constraints. For a tool with no structured output documentation, the description should provide more context about the return value.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the parameter 'ddd' fully documented in the schema as a 2-digit area code. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain valid DDD ranges, examples, or edge cases. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb ('Get information') and resource ('Brazilian area code (DDD)') with specific scope ('including state and cities'). It distinguishes from siblings by focusing on area codes rather than banks, currencies, CEP, CNPJ, IBGE data, or domain checks. However, it doesn't explicitly differentiate from potential similar tools (like 'cep-search' which also deals with geographic codes).

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate (e.g., for area code lookup vs. other geographic searches like 'cep-search' for postal codes) or any prerequisites. The agent must infer usage from the tool name and description alone.

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

• ibge-municipalities-listC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List') but lacks details on permissions, rate limits, pagination, or return format. This leaves significant gaps for a tool with no output schema.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no wasted words. It front-loads the core action and resource, making it easy to parse quickly.

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

  Completeness2/5

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

  For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list format, fields included) or address potential behavioral aspects like error cases or data freshness.

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

  Parameters3/5

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

  The description adds minimal value beyond the input schema, which has 100% coverage. It implies the 'uf' parameter is a state abbreviation but doesn't provide additional context like valid examples beyond 'SP, RJ' or error handling. Baseline 3 is appropriate given the schema does most of the work.

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

  Purpose4/5

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

  The description clearly states the verb ('List') and resource ('municipalities of a Brazilian state'), making the purpose specific and understandable. It doesn't explicitly distinguish from sibling tools like 'ibge-state-search' or 'ibge-states-list', which prevents a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'ibge-state-search' or 'ibge-states-list', nor does it specify prerequisites such as needing the state abbreviation beforehand.

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

• registrobr-domain-checkB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions checking 'status and availability' but doesn't specify what status information is returned, whether it's a read-only operation, if there are rate limits, or what the output format looks like. This leaves significant gaps for a tool that presumably queries an external service.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information.

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

  Completeness3/5

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

  For a single-parameter tool with good schema coverage but no annotations or output schema, the description provides basic purpose but lacks important context about what information is returned and behavioral characteristics. It's minimally adequate but has clear gaps in completeness.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the single parameter 'domain' well-documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline score when schema coverage is high.

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

  Purpose4/5

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

  The description clearly states the verb ('Check') and resource ('status and availability of a .br domain name'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools, which are unrelated to domain checking, so it doesn't reach the highest score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives or any contextual prerequisites. It simply states what the tool does without indicating appropriate usage scenarios.

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

• bank-listB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation but doesn't describe return format, pagination, rate limits, or error conditions. For a tool with zero 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple list tool and front-loads the essential information.

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

  Completeness3/5

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

  For a simple list tool with no parameters and no output schema, the description adequately states what it does. However, without annotations or output schema, it should ideally provide more behavioral context about what the list contains and how it's structured.

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

  Parameters4/5

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

  The tool has zero parameters with 100% schema description coverage, so the schema already documents this completely. The description appropriately doesn't add parameter information, maintaining focus on the tool's purpose. Baseline 4 for zero parameters is appropriate.

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

  Purpose4/5

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

  The description clearly states the verb ('List') and resource ('all Brazilian banks'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'bank-search', which might serve a similar purpose with filtering capabilities.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives like 'bank-search'. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage patterns.

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

• cambio-currencies-listB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits like pagination, rate limits, authentication requirements, or what format the list returns. For a tool with zero 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple list tool and front-loaded with the essential information.

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

  Completeness3/5

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

  Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally complete but lacks important context. It doesn't explain what the list returns (e.g., currency codes, names, symbols) or any behavioral aspects. For a read-only list tool, this is adequate but with clear gaps.

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

  Parameters4/5

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

  The tool has 0 parameters with 100% schema description coverage (empty schema). The description doesn't need to add parameter semantics since there are none, and the schema fully documents this. Baseline for 0 parameters is 4, as the description appropriately doesn't discuss non-existent parameters.

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

  Purpose4/5

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

  The description clearly states the action ('List all available') and resource ('currencies for exchange rates'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'bank-list' or 'ibge-states-list' which also list resources, so it doesn't fully distinguish its specific domain.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparison to sibling tools like 'cambio-rate' (which might provide actual exchange rates rather than currency lists).

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

• cambio-rateB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states the basic function but lacks critical details: whether this requires authentication, rate limits, what happens with invalid inputs, the format/scope of returned rates (e.g., against a base currency), or weekend/holiday behavior (though the schema hints at this). For a data retrieval tool with zero 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.

  Conciseness5/5

  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 appropriately sized for this straightforward tool.

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

  Completeness2/5

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

  Given the tool's moderate complexity (currency exchange data retrieval) and absence of both annotations and output schema, the description is incomplete. It doesn't explain what 'exchange rates' means (rates against what?), doesn't mention error conditions, and provides no information about the return format. The description should compensate for these gaps but doesn't.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters clearly documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (currency symbol format, date format with weekend/holiday behavior). This meets the baseline expectation when schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('Get exchange rates'), target resource ('for a specific currency'), and temporal scope ('on a specific date'). It distinguishes this tool from all sibling tools, which handle banking, location, registration, and other data - none involve currency exchange rates.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. While it's clearly the only currency rate tool among siblings, there's no mention of prerequisites, limitations, or comparison to hypothetical alternatives like historical rate trends or multi-currency lookups.

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

• cep-searchB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic function. It doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what format the address information returns. For a query tool with zero 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.

  Conciseness5/5

  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 appropriately sized for a simple query tool, 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.

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete for contextual understanding. It doesn't explain what 'address information' includes (e.g., street, city, state), response format, or error handling. For a tool with rich potential output but no structured documentation, the description should provide more context.

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

  Parameters3/5

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

  The description adds no parameter semantics beyond what the schema provides (100% coverage). The schema already documents 'cep' as an 8-digit numeric string for postal code querying. The description doesn't explain Brazilian CEP format, validation rules, or examples, so it meets the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the specific action ('Query') and resource ('address information from a Brazilian postal code (CEP)'), distinguishing it from sibling tools like cnpj-search or ibge-state-search which query different types of Brazilian data. It precisely communicates what the tool does without ambiguity.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. While it mentions 'address information from a Brazilian postal code', it doesn't specify use cases, prerequisites, or contrast with similar tools like ibge-municipalities-list for location data. This leaves the agent without contextual usage instructions.

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

• ibge-state-searchB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the lookup mechanism but doesn't disclose error handling (e.g., invalid codes), response format, rate limits, or authentication needs. For a tool with zero 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste—it directly states the tool's function and parameter usage. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly without unnecessary elaboration.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete for a lookup tool. It doesn't explain what information is returned (e.g., state name, capital, population), error responses, or any constraints. While the purpose is clear, the lack of behavioral and output details makes it inadequate for full contextual understanding.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the parameter 'code' well-documented in the schema. The description adds marginal value by clarifying that 'code' can be an abbreviation (e.g., SP, RJ) or numeric code (e.g., 35), but doesn't provide additional syntax or format details beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Find information') and resource ('about a Brazilian state'), specifying it works by 'code or abbreviation'. It distinguishes itself from siblings like 'ibge-states-list' by focusing on individual state lookup rather than listing all states. However, it doesn't explicitly contrast with 'ibge-municipalities-list' for granularity differences.

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

  Usage Guidelines3/5

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

  The description implies usage when you need state-specific data by code/abbreviation, suggesting an alternative to 'ibge-states-list' for bulk retrieval. However, it lacks explicit guidance on when NOT to use this tool (e.g., for municipality data) or detailed comparisons with siblings like 'ddd-info' for regional info. The context is clear but not comprehensive.

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

• ibge-states-listB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the tool lists states with information, but doesn't mention what information is included, whether it's paginated, if there are rate limits, or any authentication requirements. This leaves significant 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core functionality without any unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information.

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

  Completeness3/5

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

  For a zero-parameter list tool with no output schema, the description is minimally adequate but lacks important context. It doesn't specify what 'information' includes, the format of the response, or how comprehensive the listing is. Without annotations or output schema, more detail would be helpful for the agent to understand what to expect.

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

  Parameters4/5

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

  The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which aligns with the schema. A baseline of 4 is appropriate for zero-parameter tools that don't need parameter explanations.

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

  Purpose4/5

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

  The description clearly states the action ('List') and resource ('Brazilian states with their information'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'ibge-state-search', which could be used for similar state-related queries, so it doesn't reach the highest score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'ibge-state-search' or 'ibge-municipalities-list'. It simply states what the tool does without context about appropriate use cases or limitations.

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

• cnpj-searchB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions querying information but does not specify whether this is a read-only operation, requires authentication, has rate limits, or what the return format might be. For a tool with zero 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It is appropriately sized for a simple query tool and earns its place by clearly stating the tool's function.

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

  Completeness3/5

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

  Given the tool's low complexity (single parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and parameter context but lacks behavioral details and usage guidelines, making it minimally viable but with clear gaps for an agent to understand full context.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the parameter 'cnpj' fully documented in the input schema. The description adds minimal value beyond the schema by clarifying that CNPJ stands for 'National Registry of Legal Entities' and relates to Brazilian companies, but does not provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('Query information') and target resource ('about a Brazilian company by its CNPJ'), distinguishing it from siblings like cep-search or bank-search that query different entities. It precisely defines what the tool does without being vague or tautological.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like registrobr-domain-check or ibge-state-search, nor does it mention prerequisites or exclusions. It states the purpose but lacks context for tool selection among siblings.

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