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

No annotations are provided, so the description carries the transparency burden. It does clarify that checking status is a polling operation and implies it is safe to call repeatedly, but it does not discuss statuses beyond PROCESSING, terminal states, errors, or concurrency implications.

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

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

One concise sentence, front-loaded with the core purpose and followed by the key polling instruction. There is no wasted text or repetition.

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 1-parameter polling tool with an output schema, the description is largely complete. The only missing context is the full job-status lifecycle, but the description covers the most important behavior (keep polling during PROCESSING) while the output schema handles return-value details.

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 job_id is self-explanatory from its name and the description's reference to 'job'. The schema already provides the field name and required status, and the description adds no format or derivation details, but none are critically needed here.

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 uses a specific verb ('Consulta') and resource ('estado do job'), making it immediately clear the tool checks job status. It also adds a behavioral nuance about polling during PROCESSING, which distinguishes it from the sibling processing/discarding 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?

It explicitly tells the agent to keep polling while the status is PROCESSING and not to ask for 'Feito' during that time. This is direct, actionable guidance for the polling workflow.

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 carry behavioral disclosure. It states the action is immediate but does not clarify whether the discard is permanent, reversible, or has side effects. For a destructive operation, this lacks necessary transparency.

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

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

The description is a single sentence that front-loads the action and the key identifier. It is concise and contains no filler.

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?

While the basic action is clear, the description omits context such as prerequisites, what happens after discarding, and how this relates to sibling tools. The lack of guidance on when to discard versus querying or extracting text leaves the description incomplete for safe and correct use.

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 zero description coverage for the job_id parameter, and the description only says 'identified by the job_id,' which merely restates the parameter name. No format, source, or constraints are provided, so the description does not compensate for the missing schema documentation.

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 uses a specific verb ('discard') and a specific resource ('temporary derivative identified by the job_id'), clearly distinguishing this tool from its siblings like 'consultar_job' (query) and 'obter_texto_desidentificado' (get text).

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 usage is implied by the action: if you have a job_id and want to discard its temporary derivative, this tool is appropriate. However, there is no explicit mention of when not to use it or alternatives, such as querying the job first or waiting for completion.

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 only hints at blocking behavior for certain states, without explaining side effects, permissions, or potential errors. Given no annotations, the description carries the full burden but falls short of disclosing clear 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 and structurally simple, using a single sentence that is easy to parse. However, the brevity contributes to ambiguity, though it does not appear overly verbose or confusing.

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 lack of an output schema, the description attempts to describe the return value but does so cryptically ('texto PASS'). It fails to explain error conditions, the meaning of 'PASS', or what constitutes 'organized batch package', leaving significant gaps in 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 description does not mention the 'job_id' parameter at all. With schema coverage at 0%, the description adds no semantic value for this parameter, leaving the agent without guidance on its meaning or usage.

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

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

The description states the tool returns 'PASS text' or an organized batch package, but the meaning of 'PASS' and the exact nature of the returned data are unclear. It is not a tautology, but it lacks specificity and does not clearly distinguish from sibling tools like 'consultar_job'.

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 given on when to use this tool versus alternatives. The mention that 'other states block' provides a precondition but does not clarify the appropriate context for invocation.

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 bears the full burden of behavioral disclosure and does reveal the key interactive trait: it opens native OS folder selectors requiring user action, and it explicitly states no chat-based path arguments are accepted. However, it doesn't address what happens after the user cancels, whether processing is synchronous or asynchronous in light of job-based siblings like 'consultar_job', or what side effects occur, leaving a moderate transparency gap.

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 one sentence with the primary action front-loaded ('Abre seletores nativos de pastas') and a clarifying constraint in the second clause. Both clauses carry distinct information and there are zero redundant words.

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 parameterless tool with an output schema, the description is largely sufficient — it covers the interaction mechanism (native pickers), the processing mode (batch), and a key constraint (no chat paths). It could add a clause about return semantics or post-selection behavior, which would be especially useful given the job-oriented sibling tools, but the core context is adequately conveyed.

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, the rubric sets a baseline of 4, and the description adds value by explaining WHY no parameters exist — interaction happens via a native folder picker rather than schematized arguments ('sem receber caminhos no chat'). This gives semantic meaning to the empty schema that the schema itself cannot convey.

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 provides a specific verb+resource: 'abre seletores nativos de pastas' (opens native folder pickers) and 'processa em lote' (processes in batch), with the clause 'sem receber caminhos no chat' helping distinguish this from path-based workflows. However, the exact nature of the batch processing itself is vague — what happens with the selected folders is not stated — so it doesn't fully reach the specificity required for a 5.

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?

Usage context is implied through the phrase 'sem receber caminhos no chat', which tells an agent this tool is for interactive, UI-driven selection rather than chat-supplied paths. However, no sibling tool is named, no explicit exclusion conditions are given, and no scenario-based guidance is provided on when to prefer this over tools like 'selecionar_e_desidentificar' or 'obter_texto_desidentificado'. Guidance is present but only implied.

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 discloses the async kickoff pattern (returns job_id rather than completing work) and the side effect of opening localhost. However, it omits important behavioral context: whether prior steps are required (e.g., installation verification), what happens if localhost fails to open, or the nature of the jobs that are created - particularly relevant given the descartar_job sibling exists for cleanup. It's adequate but not rich.

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 two short sentences with zero waste. It front-loads the primary action and return value in the first sentence, then delivers the critical follow-up instruction in the second. Every word earns its place, and the Portuguese phrasing is compact. This is an exemplary compact description.

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?

There is an output schema (indicated by has_output_schema: true), which partially covers return values. For a process-initiating tool with no annotations, more context is needed: prerequisites (verificar_instalacao appears to be a sibling that should precede this), failure modes, and the job lifecycle (the agent would benefit from knowing descartar_job can be used to clean up). The next-step polling instruction is helpful, but the initiation flow is under-explained.

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 baseline of 4 applies. The description adds value beyond the empty schema by explaining the return contract (job_id) and the required next action (polling), which compensates for the absence of any parameter documentation needs. There is nothing to document for parameters, and the description appropriately focuses on the workflow contract.

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

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

The description clearly states the action ('Abre localhost e retorna job_id' - opens localhost and returns job_id), specifying both the verb and resource. It implies differentiation from siblings by establishing this as the job-initiating step, distinct from consultar_job (polling) and descartar_job (cleanup). It could be slightly clearer about the connection to de-identification, but the name carries that 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?

Explicitly instructs the agent to poll consultar_job next ('o agente deve pollar consultar_job em seguida'), giving a clear sequential workflow. However, it does not mention when NOT to use this tool, nor does it reference prerequisites like verificar_instalacao, which likely should be checked first given the sibling set. The next-step guidance is strong but the exclusion/prerequisite coverage is incomplete.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds one meaningful behavioral detail ('sem abrir documentos' / without opening documents), but it does not disclose potential side effects, error conditions, or whether it requires any local setup, network access, or permissions. The output schema exists, but return behavior is not described in the text.

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, front-loaded sentence that states the verb, the qualifier, and the target resource in a clear order. There is no wordiness, and every word contributes meaning ('Verifica', 'sem abrir documentos', 'se o processamento local está disponível').

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 check tool with zero parameters and an existing output schema, the description provides sufficient context. It explains what the tool does and adds a key differentiator (no document opening), which covers the essential usage context. No additional information seems necessary for an agent to understand and invoke the tool 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?

The tool has zero parameters, so no parameter explanation is needed. The schema coverage is 100% by definition, and the baseline score for 0 parameters is 4. The description adds no parameter details, but that is acceptable here since there are none.

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 action ('Verifica' / checks) and a specific resource ('se o processamento local está disponível' / if local processing is available), plus a key qualifier ('sem abrir documentos' / without opening documents). This distinguishes it from sibling tools that operate on documents or jobs, making the 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 phrase 'sem abrir documentos' implies this is a lightweight pre-check to verify availability before using document-processing tools, giving clear context for when to use it. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer when this tool is appropriate.

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