Obter metadados de um arquivo ou pasta

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'somente leitura' and 'sem alterar seu conteúdo'. It adds valuable behavioral guidance beyond the annotations: no confirmation is needed and the assistant should describe the result in simple terms without citing the technical tool name.

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 three dense sentences with no filler. It front-loads the read-only nature, then lists returned metadata fields, and closes with concrete user-interaction instructions. Every sentence earns its place.

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

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

For a simple one-parameter, read-only tool with full schema coverage and supporting annotations, the description is complete. It covers what the tool does, what it returns, that it is non-destructive, that confirmation is not needed, and how to communicate the result to the user.

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 already covers the only parameter, 'caminho', with 100% description coverage. The tool description does not add extra parameter-level semantics such as supported path formats or whether the path can be relative or absolute, so it remains at the baseline for fully documented schemas.

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 identifies the operation as a read-only metadata query for a file or folder, enumerating the exact data returned (name, extension, type, size, creation/modification dates). It explicitly states the content is not altered, which differentiates it from sibling mutation tools like mover_item, renomear_item, and enviar_para_lixeira.

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

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

The description provides clear context: use this when the user needs file/folder information without changing anything, and no confirmation is required. It does not explicitly compare against sibling tools like listar_arquivos or buscar_arquivos, so it stops short of giving exclusions or alternative routing.

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