descrever_base_pr

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns field names and an example record, which is the core behavior, but it does not disclose potential limitations (e.g., whether the example record is representative, whether field names might be incomplete, or how the output is structured). Since annotations already handle the read-only nature, the description contributes some but not rich behavioral context, so a 3 is appropriate.

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

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

The description is a single sentence with zero waste. It front-loads the key information (returns field names and example record) and appends the purpose (to build filters). Every word earns its place, and it is appropriately concise for a simple read-only metadata tool.

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 only 2 parameters, one required, and an output schema exists. The description adequately states what the tool returns (field names and example record) and why it is used (to build filters). It does not explain error handling or edge cases, but for a read-only tool with clear annotations and an output schema, this is sufficient. The main missing piece is parameter clarification, which is already penalized in that dimension. Overall, the description is complete enough for an agent to call it correctly.

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 by explaining the parameters. It does not. The description does not clarify what 'base' refers to (though the enum values in the schema are self-explanatory) or what the optional 'ano' (year) parameter does. It only hints at the overall purpose (building filters) but leaves parameter meaning to the agent's inference from the schema. This is insufficient given the low coverage, so a 2 is justified.

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 a specific verb ('Retorna' = returns) and a distinct resource: original field names and an example record for building filters. It differentiates from sibling query tools like consultar_base_pr (which likely returns data) and listar_bases_pr (which lists bases). The phrase 'para montar filtros' adds contextual purpose, making it unambiguous what this tool is for.

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

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

The description implies usage by stating the output is for building filters, but it does not explicitly state when to use this tool over alternatives or provide any exclusions. It mentions no sibling tools and gives no when-to-use/when-not-to-use guidance, relying on the agent to infer that it is for obtaining schema metadata before querying. This is implied usage, not explicit guidance.

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