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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's statement that it adds tracking is consistent. But the description adds no additional behavioral context beyond annotations, such as whether the action is idempotent, reversible, or requires permissions.

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 front-loaded with the purpose. It uses bullet points for parameters, making it easy to scan. No unnecessary text, but could be slightly more informative without bloating.

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 existence of an output schema, the description does not need to explain return values. However, it omits information about error conditions, idempotency, and the meaning of 'especial' tracking. It is adequate but not fully complete for a mutation 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?

With 0% schema description coverage, the description must compensate. It provides brief explanations for all three parameters, including the format of processo and a cross-reference for grupo. However, it lacks details on optionality, default behavior, or constraints, which is a gap.

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 adds special tracking (acompanhamento) to a process, with a verb and resource. It is distinct from siblings like sei_remover_acompanhamento, but does not explicitly differentiate usage contexts, though the action is clear.

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 provides a useful cross-reference to sei_listar_grupos_acompanhamento for getting the group ID. However, it lacks guidance on when to use this tool versus alternatives (e.g., when to remove tracking) and does not mention prerequisites or limitations.

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?

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that the tool is available from mod-wssei 2.0.0 and suggests checking version on error, but does not elaborate on side effects, authorization needs, or state changes beyond 'altera'.

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 brief sentences plus a version note and error tip. It front-loads the main action and efficiently covers key information.

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 3 simple parameters and an output schema (not shown), the description adequately conveys the purpose and parameters. However, with zero schema description coverage, more detail on parameter constraints or return values would 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?

With 0% schema coverage, the description compensates by explaining that 'processo' is a protocol number or IdProcedimento, 'grupo' is the new group, and 'observacao' is the new observation. This adds meaning, though it could specify allowed formats or values.

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 'altera' (alters) and the resource 'acompanhamento especial de um processo', distinguishing it from sibling tools like 'criar' and 'remover'.

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 vs alternatives like sei_criar_grupo_acompanhamento or sei_remover_acompanhamento. The description only lists parameters without contextual usage advice.

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?

Annotations already indicate it is not read-only (readOnlyHint: false) and not destructive (destructiveHint: false), and is idempotent. The description adds version availability and a troubleshooting hint, but does not disclose any additional behavioral traits like required permissions or side effects. This is adequate given the annotation coverage.

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 brief with two sentences, each serving a purpose (action and version note). No redundant information. However, it is too sparse, missing important details that could be added without much length, so it slightly loses points for under-specification.

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 presence of an output schema and annotations, the description still lacks essential context. It does not explain what an 'anotação' is in this domain, the relationship to the signature block, or what the output will contain. For a tool with three undocumented parameters, the description is insufficient to fully understand usage.

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%, and the description provides no explanation of the three required parameters (id_bloco, documento, descricao). The parameter names are self-explanatory to some extent, but without any context or format details, the description fails to add meaning beyond the schema. This is a critical gap.

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 'Altera' and the resource 'anotação de documento em um bloco de assinatura', making the purpose specific. However, it does not explicitly differentiate from similar tools like 'sei_anotar_documento_bloco_assinatura' or 'sei_alterar_anotacao_bloco_interno', so a slight deduction.

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. There is no mention of prerequisites (e.g., the annotation must exist) or context where it should be preferred. The only extra information is about version and troubleshooting, which does not aid in tool selection.

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?

Annotations already indicate non-read-only, idempotent, and non-destructive behavior. The description adds version requirements and an error recovery suggestion ('use sei_versao if unexpected error'). This provides some additional context beyond annotations.

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 short (two sentences) but lacks structure. The first sentence conveys purpose, but the second sentence is a version/error note that could be more concisely integrated. It is not front-loaded with the most critical information.

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 an output schema exists, return values are covered elsewhere. However, the description fails to provide guidance on parameter input or usage context. For a tool with three required undocumented parameters, this is insufficient for correct invocation.

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 for its three required parameters (id_bloco, processo, descricao). The description does not explain what these parameters represent or their format, leaving the agent without sufficient information to use the tool correctly.

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 'Altera anotação de processo em um bloco interno', which clearly specifies the action (alter) and the resource (annotation of process in internal block). It distinguishes from sibling tools like sei_criar_anotacao (create) and sei_alterar_anotacao_bloco_assinatura (different block type).

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 version information and a troubleshooting tip but does not provide explicit guidance on when to use this tool versus alternatives like sei_criar_anotacao or sei_alterar_anotacao_bloco_assinatura. The agent must infer usage solely from the name.

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?

Annotations already declare idempotentHint=true and destructiveHint=false, so the description's addition of version info and error handling provides some context beyond annotations. However, it does not disclose side effects, permissions needed, or behavioral traits like whether the tool immediately persists changes. The description is consistent with annotations.

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: the primary action and a note on version/compatibility. It is front-loaded with the main purpose, and every sentence adds 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?

For a mutation tool with 2 required parameters, no parameter descriptions, and an output schema (unknown content), the description is insufficient. It lacks prerequisites (e.g., block must exist, user permissions), expected effects, or return value details. Annotations partially compensate, but the description omits critical context for correct invocation.

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%, meaning the schema provides only parameter names and types (both strings). The description does not explain what id_bloco or descricao represent, their valid formats, or any constraints. This leaves the agent with minimal semantic understanding beyond the names.

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 alters a signature block's description ("Altera descrição de um bloco de assinatura"). The verb 'alterar' and resource are specific, distinguishing it from sibling tools like criar (create) or retornar (return). However, it does not explicitly differentiate from sei_alterar_bloco_interno (internal block), but context implies it's for signature blocks.

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 version availability note and a troubleshooting step (use sei_versao on error), but provides no guidance on when to use this tool versus alternatives like sei_criar_bloco_assinatura or sei_alterar_bloco_interno. There are no explicit when-to-use, 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?

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds version compatibility and error recovery suggestions, but no deeper behavioral context beyond what annotations provide.

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 a version line, no superfluous words, and is well front-loaded.

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 2 required parameters and an output schema, the description is functional but lacks explanation of what a 'bloco interno' is and the output format. Adequate but not rich.

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 fails to explain the parameters (id_bloco, descricao). It only states the tool alters the description, leaving parameter meaning unclear.

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 'Altera' and the resource 'descrição de um bloco interno', making the tool's purpose specific and distinguishable from siblings like sei_criar_bloco_interno or sei_excluir_bloco_interno.

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 on when to use this tool versus alternatives. The description only provides version information and a troubleshooting tip, not usage context.

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?

Annotations indicate non-read-only, non-destructive, and idempotent. The description adds that the tool modifies metadata and optionally replaces the file, which aligns with annotations. It also mentions version availability and error fallback, but does not disclose authorization needs or other behavioral traits. With annotations covering the safety profile, this is adequate.

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 clear purpose sentence, followed by a bullet-like list of parameters and a separate line for version and error handling. It is concise and front-loaded with the main action, though some sentences like the error fallback could be condensed.

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 5 parameters (1 required), 0% schema coverage, and an output schema exists, the description covers purpose, parameter meaning, version, and error handling. However, it lacks context about prerequisites (e.g., document must exist, user permissions) and does not guide the agent on when this tool is appropriate relative to siblings like sei_consultar_documento_externo. It is adequate but not comprehensive.

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% (no property descriptions), so the description must fully explain parameters. It does so: id_documento (ID), descricao (new description), nivel_acesso (with enum values 0/1/2), hipotese_legal (conditional requirement), and arquivo_path (optional file replacement). This compensates well for the lack of schema descriptions.

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 'Altera metadados de um documento externo (e opcionalmente substitui o arquivo).' This is a specific verb+resource action. It distinguishes from sibling tools like sei_criar_documento_externo (create) and sei_consultar_documento_externo (read), so purpose is clear and differentiated.

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 for updating external document metadata but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned. The inclusion of version and error fallback is helpful but does not substitute for usage directives.

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?

Annotations already indicate the tool is not read-only, not destructive, and idempotent. The description adds that it modifies metadata (not content) and includes a version-check hint. No contradictions, but no deep behavioral disclosure like authorization needs or 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 structured with a lead sentence, a bullet-like list of parameters (though in paragraph form), version info, and an error hint. It is fairly concise with no redundant sentences, but could be slightly more streamlined (e.g., using actual bullets).

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) but the description does not mention what is returned. Given the annotations (idempotent, non-destructive) and the simplicity of updating metadata, the description covers usage adequately but lacks output expectations.

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 adds crucial meaning: it explains each parameter's purpose, lists allowed values for 'nivel_acesso' (0,1,2), and notes the conditional requirement for 'hipotese_legal' when level is restrito/sigiloso. This goes far 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 explicitly states 'Altera metadados de um documento interno (não o conteúdo HTML).' This clearly distinguishes it from sibling tool 'sei_editar_secao' which alters content. The verb 'alterar' and resource 'documento interno' are specific.

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 an explicit alternative: 'Para alterar o conteúdo, use sei_editar_secao.' It also hints at debugging by suggesting 'use sei_versao' on unexpected errors. However, it does not list exclusions or scenarios where this tool should not be used.

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?

Annotations already indicate non-read-only, non-destructive, idempotent. Description adds that hipotese_legal is mandatory for restricted/secret levels, a key constraint beyond annotations.

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 brief, well-structured with bulleted parameters, and front-loaded with purpose. 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 5 parameters, 1 required, and existence of output schema, the description covers all necessary information: parameter details, usage hints, and dependencies. No gaps identified.

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?

Despite 0% schema coverage, description fully documents each parameter, including format (protocolo formatado), values (nivel_acesso numeric), and prerequisite (hipotese_legal dependency).

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 'Altera metadados de um processo no SEI' with a specific verb and resource. It lists all parameters and provides examples, distinguishing it from sibling tools like sei_criar_processo.

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 'Informe apenas os campos que deseja alterar', indicating partial updates. Does not enumerate when not to use, but context is clear for a metadata update tool among 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?

Annotations already indicate non-read-only (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds version availability and a troubleshooting hint for unexpected errors, but does not disclose details like whether the annotation can be modified, deleted, or its impact on the document.

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: the first states the purpose, the second provides version and error guidance. No redundant information, and the key action is front-loaded.

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 an output schema (unseen), the description does not need to detail return values. However, it lacks parameter descriptions and usage conditions, which would improve completeness. It is minimally adequate but not comprehensive.

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% (no parameter descriptions). The description does not explicitly define id_bloco, documento, or descricao beyond what is implied by the tool's name and purpose. Users must infer meanings, which is insufficient for a tool with three required parameters.

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's purpose: 'Cria anotação em documento dentro de um bloco de assinatura.' This is a specific verb (cria) and resource (annotation on document in signature block), and it distinguishes from sibling tools like sei_criar_anotacao and sei_anotar_processo_bloco_interno.

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 for annotating a document inside a signature block but offers no explicit guidance on when to use this tool versus alternatives like sei_criar_anotacao for process-level annotations. There is no mention of when-not-to-use or workflow context.

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?

Annotations already indicate it is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds version details and error-handling advice, which provides modest transparency beyond the annotations. No behavioral 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?

The description is two short sentences without wasted words. It is front-loaded with the primary action. Slightly more structure (e.g., bullet points for parameters) could improve skimmability, but it is still 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 existence of an output schema, the description does not need to detail return values. However, for a creation tool with three undocumented required parameters, the description is incomplete in explaining the input semantics. The version and error info add some 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?

With 0% schema description coverage, the description must compensate, but it does not explain any of the three required parameters (id_bloco, processo, descricao). Their meaning is only implicit from the tool name, leaving a significant semantic gap.

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 creates an annotation (anotação) in a process within an internal block, which distinguishes it from general annotation tools like sei_criar_anotacao and modification tools like sei_alterar_anotacao_bloco_interno. However, it could more explicitly contrast with these siblings.

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 version information and an error-recovery hint ('use sei_versao') but gives no explicit guidance on when to use this tool versus alternatives like sei_criar_anotacao. Prerequisites (e.g., existence of block) are not 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 goes beyond the annotations (readOnlyHint=true, openWorldHint=true) by detailing the default backend (REST endpoint) and the optional web scraper mode with its activation condition and status. This provides useful implementation context without contradicting the read-only nature indicated by annotations.

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 the main purpose first, followed by parameter clarification, cross-reference, and implementation detail. It is concise but not overly terse; each sentence adds value. Minor improvement could be restructuring to reduce repetition about the scraper.

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 (1 parameter, output schema exists), the description covers all necessary aspects: what it does, how to specify input, alternative tools, and backend behavior. No critical omissions are apparent.

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 compensates by explaining the single parameter: it accepts a formatted protocol (with example) or IdProcedimento. This adds critical meaning beyond the schema's bare type declaration.

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 'Mostra a árvore (lista) de documentos de um processo SEI', which is a specific verb (mostra) and resource (árvore de documentos). It distinguishes itself from sibling tools like sei_ler_documento by offering a tree view rather than content reading, and from other listing tools via the focus on document hierarchy.

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 clearly indicates when to use this tool (to view the document tree) and provides an explicit alternative for reading document content ('use sei_ler_documento com o id'). It also mentions the default REST method and the scraper option with an env variable, offering context on performance. However, it does not explicitly compare to other nearby sibling tools like sei_listar_documentos or sei_consultar_processo.

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?

Annotations declare readOnlyHint=false (write operation) and destructiveHint=false. The description adds transparency about automatic authentication and the critical requirement of cargo. It does not contradict annotations.

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 (one paragraph plus bullet points) and front-loaded with the main purpose. Minor repetition of cargo being mandatory, but overall effective.

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 presence of an output schema, the description does not need to cover return values. It covers input semantics well, including authentication and parameter usage. It could mention potential failure reasons beyond missing cargo, but is sufficient for an agent.

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% and cargo is marked optional with a default, but the description clarifies cargo is effectively required and explains the fallback behavior (omitting it lists options). This adds crucial 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 states the exact action: signing all documents in a signature block. It distinguishes from signing individual documents by specifying 'TODOS os documentos de um bloco'. The verb 'assina' and resource 'bloco de assinatura' are clear and specific.

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 guidance on the cargo parameter: it is mandatory, omitting it returns options, and advises the agent to ask the user and cache the value. It does not, however, compare directly with sibling signing tools like sei_assinar_documento or sei_assinar_documentos_bloco.

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?

Annotations indicate non-readonly and non-destructive. The description adds that authentication is automatic, cargo is mandatory for signing, and omitting cargo returns a list (branching behavior). It also explains id_documento auto-resolves. This goes beyond annotations, though rate limits or permissions are not mentioned.

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 first-line summary, important notes, and a parameter list. It is front-loaded with purpose. Some redundancy exists in the IMPORTANT section and step-by-step, but the information is valuable and 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 tool's complexity (branch behavior, 3 params, output schema exists), the description covers the main flow and parameter details well. It omits authentication prerequisites (though stated as automatic) and error cases beyond cargo. Overall, it is sufficient for an agent to use 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 carries full burden. It thoroughly explains each parameter: id_documento can be internal ID or SEI number with auto-resolution, cargo is mandatory for signing and returns list if omitted, orgao defaults to a standard. This adds significant value beyond the bare 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 signs a document electronically in SEI. 'Assina eletronicamente um documento no SEI' is a specific verb+resource pair, differentiating it from siblings like sei_cancelar_assinatura or sei_assinar_bloco.

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 guidance on when to use: for signing a document. It details a workflow for handling the cargo parameter (call without it to get options, ask user, call again). It does not explicitly exclude alternatives like signing a block, but the context is clear.

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?

It discloses automatic authentication, mandatory cargo (failure if omitted), and fallback behavior (list options). Annotations (readOnlyHint false, destructiveHint false) are consistent, and the description adds useful behavioral context beyond them.

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, well-structured with a bullet list. Front-loaded with main purpose, each sentence adds value without redundancy. Ideal length for its complexity.

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 (2 parameters, no nested objects, output schema present), the description covers input behavior, usage quirks, and error recovery. It is fully complete for an agent to invoke 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter: documentos (comma-separated IDs) and cargo (mandatory, lists options if omitted). This adds significant meaning beyond the schema's type and default.

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 signs specific documents from a signature block ('Assina documentos específicos de um bloco de assinatura'). This distinguishes it from related tools like 'sei_assinar_documento' (single document) and 'sei_assinar_bloco' (whole block).

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 explains when to use: requires cargo parameter, and if unknown, call without cargo to list options. It instructs to ask the user and save the cargo for reuse. This provides explicit guidance on handling a missing parameter.

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?

Annotations already indicate non-read-only and non-destructive behavior. The description adds valuable detail: when a name is given, the tool searches for matching users and attempts assignment to each until one has permission. This clarifies the fallback behavior and side effects, which goes beyond annotations.

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 bullet points. The main verb and resource are front-loaded. Every sentence adds value, with no redundant or filler content.

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 (2 parameters, no schema descriptions), the description covers the main behavior and parameter usage. An output schema exists, so return value details are not required. It could mention whether the assignment is successful or provides feedback, but overall it is sufficiently 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?

Schema coverage is 0%, but the description fully compensates by explaining both parameters in detail: numero_processo format with an example, and usuario accepting either numeric ID or name with search logic. This provides complete semantics 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 assigns a process to a user ('Atribui um processo a um usuário da unidade'). This distinguishes it from siblings like sei_remover_atribuicao (remove assignment) and sei_listar_usuarios (list users). However, it doesn't contrast with other assignment-related tools like sei_receber_processo or sei_enviar_processo.

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 that the usuario parameter can be a numeric ID or a name (with search fallback). It does not explicitly state when not to use this tool or provide alternative tools for different scenarios, leaving the agent to infer usage context.

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?

As anotações já indicam readOnlyHint=false e destructiveHint=false, mas a descrição acrescenta comportamentos como resolução automática entre ID interno ou número SEI, limite de 10 MB, retorno de base64 + tamanho, e a restrição do flag confirmar_acesso_restrito. Há valor adicional, embora o comportamento de leitura/escrita não seja conflitante.

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?

A descrição é concisa, bem estruturada em parágrafos curtos e tópicos. Cada sentença agrega valor, sem redundâncias. A informação mais importante vem primeiro (o que a ferramenta faz), seguida de detalhes de uso e advertências.

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?

A descrição cobre a finalidade, parâmetros, comportamento (resolução automática, limite de tamanho), alternativas e advertências de segurança. Com a existência de esquema de saída, o formato de retorno é adequadamente esclarecido. Nada relevante parece faltar para o uso correto.

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?

O esquema de entrada tem 0% de cobertura de descrição, então a descrição carrega todo o peso. Ela explica que id_documento aceita tanto ID interno quanto número SEI com resolução automática, e detalha o comportamento do confirmar_acesso_restrito, incluindo quando e como deve ser usado. Isso adiciona significado crucial além do esquema.

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?

A descrição afirma claramente que a ferramenta baixa documentos externos (anexos) em base64, especifica o tipo de documento ('tipoDocumento='X'') e diferencia-se de sei_ler_documento, que é preferível para PDFs com texto.

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?

A descrição fornece orientações explícitas sobre quando usar (para anexos tipo 'X') e quando não usar (preferir sei_ler_documento para PDFs com texto), além de instruções detalhadas sobre o flag confirmar_acesso_restrito, definindo quando deve ser ativado.

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?

Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: it reveals the internal fallback strategy (textual search via Solr when no process is given) and explains the effect of providing the 'processo' parameter. It also clarifies what the function returns (internal id, type, metadata, process). No contradiction with annotations.

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: it starts with the primary purpose, uses numbered steps for the strategy, and keeps each sentence focused. There is no redundant information, and the length is appropriate for the complexity of the 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?

Given that an output schema exists (relieving the need to explain return values), the description adequately covers the main behavior and parameter effects. It explains the two search strategies and the purpose of the returned data. However, it could briefly mention potential failure modes or limitations (e.g., when the number is not found) to be fully 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?

Schema description coverage is 0%, so the description must compensate. It explains the 'numero_sei' parameter with format examples and the 'processo' parameter with acceptable formats (protocolo formatado or IdProcedimento) and its impact on query speed. This adds meaning beyond the schema, although more detail on required formats could be added.

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's purpose: to search for a document by its SEI number. It provides examples of the number format (e.g., 'SEI 2843449') and distinguishes its output (internal id) from related tools like sei_ler_documento. The description also explains the strategy used to locate the document, making the purpose specific and 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 explains when to use the tool (when you have a SEI number) and how the optional 'processo' parameter affects performance. It also notes that the returned internal id is required for 'sei_ler_documento', providing workflow guidance. However, it does not explicitly state when not to use this tool or mention alternative tools for similar tasks, missing some exclusionary guidance.

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?

Description discloses that SEI API has no direct endpoint, so the tool forces a minimal edit to trigger automatic signature removal. This adds context beyond annotations (readOnlyHint=false, destructiveHint=false) about the workaround behavior. It does not elaborate on output schema or potential 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?

Description is concise (6 lines) with clear structure: purpose, accepted parameter format, workaround explanation, limitation, and alternative action. No superfluous content, though could be slightly tighter.

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 complexity and existence of an output schema, the description covers essential behavioral aspects: what it does, how it works, parameter format, limitations, and fallback. It is complete for an agent to understand and invoke 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 has 0% description coverage for the single parameter id_documento. Description adds that it accepts 'id interno ou número SEI (protocoloFormatado)', providing format guidance that compensates for the bare 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 clearly states the tool attempts to cancel (derrubar) the signature of a document, using a specific verb and resource. It distinguishes from sibling tools like sei_assinar_documento (sign) and sei_listar_assinaturas (list signatures).

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 limitation (only works if process not sent/read) and alternative (manual cancellation via web UI). It implies when to use and what to do on failure, but does not explicitly compare to other tools or give a direct 'when to use this vs. that'.

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?

Annotations already indicate non-destructive mutation. The description adds that the block returns to open and becomes editable again, which is useful behavioral context. However, it does not disclose any authorization requirements or potential side effects, but the annotations cover the safety profile adequately.

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?

Two sentences, directly addressing the action and its consequence. Every word is valuable, no redundancy. Information is front-loaded.

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 parameter), the description covers the basic behavior. However, it lacks details on output (though output schema exists), error conditions, or prerequisites. The openWorldHint suggests side effects not mentioned. Adequate but not comprehensive.

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% and the tool description does not explain the single parameter 'id_bloco'. With no parameter documentation, an agent cannot infer its format or purpose beyond the name. The description must compensate for low coverage but fails to do so.

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 the verb 'cancels' and the resource 'availability of a signature block', and explains the effect (returns to open state for editing). This distinguishes it from siblings like 'disponibilizar_bloco_assinatura' (makes available) and 'excluir_bloco_assinatura' (deletes).

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 a clear cause-effect but lacks explicit guidance on when to use vs alternatives. It does not specify prerequisites (e.g., block must be in 'disponibilizado' state) or when not to use it. No exclusions or alternative tools 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?

Annotations already indicate this is not read-only (readOnlyHint false) and not destructive (destructiveHint false). The description adds version constraints and error handling advice but does not disclose further behavioral traits like required permissions, side effects, or reversibility.

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 short and front-loaded with the purpose. Each sentence adds value: action, version dependency, and error handling. No wasted 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 simple revoke action with 2 parameters and annotations present, the description covers the core purpose and some context. However, it lacks differentiation from sibling tools and detailed parameter handling, making it adequate but not thorough.

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%, and the description does not explain the parameters 'processo' or 'id_usuario' beyond their names. The action is described, but no additional meaning is added for proper agent 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 clearly states the specific action: revoking (cassar) a user's accreditation to a confidential process. It uses a strong verb and resource, distinguishing it from siblings like sei_conceder_credenciamento and sei_renunciar_credenciamento.

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 vs alternatives (e.g., sei_renunciar_credenciamento). It only includes version information and a troubleshooting tip, not usage context 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?

Annotations already indicate a non-read-only, non-destructive operation. The description adds version availability and an error-handling hint, but does not elaborate on behavioral details like duplicate handling or permission requirements.

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 brief and front-loaded, with two sentences that each add value. The version and error hint are useful, though slightly tangential. It could be more concise 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?

Given the tool's simplicity (2 required params, output schema exists), the description covers the basic action. However, it lacks prerequisites, output explanation, or context about what 'processo sigiloso' entails. Adequate but not 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 provides minimal extra meaning: 'processo' and 'id_usuario' are implied but not detailed. No format, constraints, or examples are given, leaving agents to rely solely on parameter names.

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 'concede' (grants) and resource 'credenciamento de acesso a um processo sigiloso para um usuário'. It effectively distinguishes from sibling tools like listar, renunciar, and cassar by specifying the granting action.

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 when-to-use or alternatives are provided. The description implies usage for granting credentials but does not contrast with other credential-related siblings. The troubleshooting tip adds context but not usage guidance.

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?

Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool modifies data but is not destructive. The description adds version availability and error suggestion but does not explain what 'concluir' entails (e.g., locks the block, changes status). There is no contradiction with annotations.

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 short sentences and a version line. The primary action is front-loaded. Every sentence provides 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?

Given the tool's simplicity (one parameter, straightforward action), the description covers the basic purpose and input format. However, it omits details about the output (though an output schema exists) and lacks guidance on when to conclude a block. It is adequate but could be more complete with usage 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 input schema has no description for the single parameter 'ids_blocos' (0% coverage). The description clarifies that IDs are separated by commas, which adds meaning beyond the schema. However, it does not specify the format of the IDs (e.g., numbers, UUIDs) or any 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 clearly states the action ('Conclui bloco(s) de assinatura') with a specific verb and resource. It adds details like comma-separated IDs and version information. However, it does not explicitly differentiate from sibling tools like 'sei_disponibilizar_bloco_assinatura' or 'sei_assinar_bloco', though the name implies a distinct concluding action.

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 does not specify when to use this tool versus alternatives (e.g., after disponibilizar or after assinar). It lacks prerequisites, postconditions, or contextual guidance. The only additional info is a version requirement and a troubleshooting tip, which are not usage guidelines.

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?

Beyond annotations which show non-read-only and non-destructive, the description adds minimal behavioral context: only comma-separated IDs and version info. It does not explain side effects, reversibility, or required permissions.

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?

Three concise sentences with no redundancy. Each sentence adds value: purpose+format, version, error fallback.

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?

Very brief description. Lacks details on what the tool returns, prerequisites, common use cases, or how to handle responses. Despite output schema existence, more context would be beneficial for an AI agent.

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%, but the description adds the comma-separated format for ids_blocos, which compensates. However, it does not specify the type of IDs (e.g., numeric) 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 clearly states the action ('Conclui bloco(s) interno(s)') and distinguishes from sibling tools like sei_concluir_bloco_assinatura by specifying 'interno'. The parameter format is also mentioned.

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 vs alternatives. It only provides an error fallback hint but does not specify prerequisites or comparison with similar tools like sei_concluir_bloco_assinatura.

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 that the process is removed from the unit's inbox but remains accessible, which adds behavioral context beyond the annotations. Annotations already indicate non-destructive and write nature, and the description confirms this with 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?

The description is two sentences, front-loaded with the main action, and contains no filler. Every sentence adds value, making it highly concise and structured.

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 parameter, no nested objects), the description covers the effect and reversibility. The mention of 'unidade atual' relies on system context, but this is reasonable given sibling tools. An output schema exists, so return values need not be 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 schema description coverage at 0%, the description does not explain the sole parameter 'numero_processo'. However, the parameter name is self-explanatory ('Numero Processo' meaning process number), and the schema provides a title. The baseline for a simple parameter is adequate.

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 specific verb 'conclui' (concludes) and the resource 'processo na unidade atual do SEI'. It distinguishes from sibling tool sei_reabrir_processo by mentioning reversal, providing clear differentiation.

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 sei_reabrir_processo para reverter' (use to revert), indicating when to use this tool versus an alternative. It implies this tool is for concluding processes, but does not list explicit when-not-to-use 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?

Annotations already provide readOnlyHint and openWorldHint. Description adds version info but no additional behavioral context (e.g., auth requirements, side effects). Not contradictory, but adds minimal value beyond annotations.

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 short and front-loaded with purpose. The troubleshooting sentence adds minor overhead but is acceptable. Could be slightly more concise by moving version info elsewhere.

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 simple schema (1 param, output schema exists), description covers the core purpose and provides a helpful error-recovery hint. Lacks mention of returned data structure, but output schema likely covers that.

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%, but the description only implies the parameter is a process identifier. No format details, valid values, or examples. Relies heavily on the parameter name 'processo'.

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 the tool consults the current assignment of a process ('quem está responsável'), using a specific verb and resource. It is distinct from siblings like sei_atribuir_processo (write) or sei_remover_atribuicao (modify).

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 on when to use this tool vs alternatives. The troubleshooting tip about sei_versao is tangential. Missing context like 'Use this to check who is currently assigned before making changes.'

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?

Beyond the readOnlyHint annotation, the description discloses ID auto-resolution via Solr, special behavior for restricted documents (including the _aviso_acesso field and explicit instructions not to change units), and version dependency. It also clarifies that the restricted document notice is informative, not an error.

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, front-loaded with the purpose, and each sentence adds value. It covers parameter details, special behavior, error handling, and alternatives 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 has one parameter, an output schema, and readOnlyHint, the description is complete. It explains parameter flexibility, return metadata summary, special return fields, and error handling. No gaps remain for agent invocation.

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 defines 'id_documento' with no description. The description adds critical semantics: it accepts both internal ID and protocol number, and auto-resolves when necessary. This fully compensates for the 0% schema description 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 first sentence clearly states the tool's purpose: 'Consulta metadados de um documento externo pelo ID.' It specifies the action (consultar metadados), resource (documento externo), and mechanism (pelo ID). The description distinguishes it from siblings like sei_ler_documento and sei_baixar_anexo, which handle content retrieval.

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 provides when-to-use guidance: 'Para baixar o conteúdo use sei_baixar_anexo ou sei_ler_documento.' It also includes version availability and error recovery advice ('Se falhar com erro inesperado, use sei_versao para verificar a versão.'), offering clear context for appropriate 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?

Annotations already declare readOnlyHint and openWorldHint, so the description adds no behavioral details. It does not contradict annotations, but it fails to provide any additional context about error handling, output format, or side effects beyond what is already in annotations.

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 concise sentence, but it lacks necessary details. It is not bloated, but it is under-specified for a production 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?

Given a simple tool with one required parameter and an output schema, the description should clarify the parameter format and possibly list return types. It does not, leaving the agent with incomplete information.

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 parameter 'processo' has no description in the schema (0% coverage) and the description does not clarify its format or expected values. The agent has no information on how to specify the process identifier.

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 'consulta' (consult) and the resource 'marcadores ativos de um processo' (active markers of a process), distinguishing it from siblings like 'sei_criar_marcador' (create marker) and 'sei_historico_marcador_processo' (history).

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 such as 'sei_pesquisar_marcadores' or 'sei_historico_marcador_processo'. No when-not-to-use or prerequisites 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 goes well beyond the readOnlyHint and openWorldHint annotations. It explains the dual-backend approach (REST and optional web scraper), fallback behavior on failure, what fields to expect from each, and the special handling for restricted processes (_aviso_acesso). This provides a comprehensive understanding of the tool's 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?

The description is structured and front-loaded with the main purpose, but it is somewhat lengthy due to detailed explanations of both backends and fallback behavior. While every sentence adds value, it could be slightly more concise without losing critical information.

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 complexity and the presence of an output schema, the description is complete. It covers all key aspects: the two backends, field lists, error handling, and special cases. There are no obvious gaps for a single-process lookup 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?

With 0% schema description coverage, the description fully compensates by providing an example protocol format ('50300.000123/2025-00') and explaining that it is a formatted protocol number. This adds essential meaning beyond the schema's bare 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?

The description clearly states 'Consulta um processo SEI pelo número de protocolo formatado', specifying the exact verb and resource. It provides an example protocol format and distinguishes from sibling tools by emphasizing that it retrieves a single process by protocol, unlike sei_listar_processos or sei_pesquisar_processos which list or search multiple processes.

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 for looking up a specific process by protocol number and gives details about the two backends. However, it does not explicitly state when to use this tool over alternatives like sei_arvore_processo or sei_listar_processos, nor does it provide exclusions or prerequisites.

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?

Annotations indicate readOnlyHint=false and destructiveHint=false, but description does not disclose side effects, return value, or undo capabilities. Given openWorldHint=true, more behavioral context is needed.

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 concise, with a clear purpose sentence followed by a bullet list of parameters. No unnecessary words, and it front-loads the main action.

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 it covers the core action and parameters, it lacks information about output (despite an output schema existing) and prerequisites. For a 3-parameter tool with annotations, it meets minimal requirements but leaves gaps for an AI agent.

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, description adds basic parameter semantics (format of processo, default priority). However, it does not explain possible values for prioridade beyond '1=normal' or describe the unique return value.

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 creates a post-it annotation on a SEI process, using specific verb and resource. It distinguishes from siblings by specifying the action (criar anotação) and target (processo).

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 vs alternatives like criar_observacao or criar_marcador. The description does not provide context for selection 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?

Annotations indicate it is not read-only and not destructive, but the description adds no behavioral context beyond the action of creation. It doesn't mention side effects, permissions, reversibility, or any state changes that may occur, which would be helpful for an agent.

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—one sentence for purpose followed by a bulleted list of parameters. No extraneous information, and the structure makes it easy to scan.

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 adequately covers the creation function but does not mention output schema (which exists) or typical usage context (e.g., blocks are used to group documents for signature). It is minimal but sufficient for a simple tool with two parameters.

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 each parameter: 'descricao' is the block description, 'unidades' accepts acronyms or IDs separated by commas and auto-resolves. This adds meaningful guidance beyond the schema's property titles.

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 'Cria um bloco de assinatura no SEI' (creates a signature block), which is a specific verb+resource. It distinguishes itself from sibling tools by the resource type (bloco_assinatura), but does not explicitly differentiate from other creation tools like sei_criar_documento or sei_criar_bloco_interno.

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. Siblings include creation tools like sei_criar_bloco_interno, but no context or prerequisites are given for using this 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds no additional behavioral context beyond stating it creates a block. It does not disclose side effects, required permissions, or lifecycle 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?

The description is very short (two sentences), but this conciseness comes at the expense of missing critical information. It is front-loaded with the key action but lacks depth.

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?

Despite having an output schema, the description is too brief. It does not explain the input parameter, and it fails to provide enough context for an agent to understand the tool's role within the larger set of block-related operations.

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 sole parameter 'descricao' has no description in the schema (0% coverage) and the tool description does not explain its meaning or format. The agent must infer it from the parameter name alone, which is insufficient.

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 creates an internal block (bloco interno) in SEI and explains it is used to organize processes in batches. However, it does not differentiate from sibling tools like sei_alterar_bloco_interno or sei_excluir_bloco_interno, which operate on the same resource.

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. The description only explains what the tool does, with no context about prerequisites, typical use cases, or when to avoid using 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?

Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds minimal behavioral context beyond the version check advice. It does not discuss side effects, required permissions, or what happens on creation (e.g., duplicates).

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 short (three sentences) but includes a version note and troubleshooting advice that, while helpful, could be better placed elsewhere. It lacks parameter explanations, which would be more impactful in the same space.

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?

With an output schema present, the description doesn't need to explain return values, but it fails to provide essential context about parameters (valid values, mandatory ones) or the creation process (e.g., error handling beyond version check). The tool feels underdescribed for a creation operation.

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 should compensate, but it mentions no parameters. The four parameters (nome, tipo, email, telefone) are left entirely for the agent to infer from names. The description adds zero semantic 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 clearly states the tool's purpose: 'Cria novo contato no SEI.' It uses a specific verb (cria) and resource (contato). Among siblings, there is a search tool (sei_pesquisar_contatos) but no other create contact tool, so it is distinct.

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. It only includes a version availability note and a troubleshooting hint about checking version on error. No context on prerequisites or when not to 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?

Annotations (readOnlyHint=false, destructiveHint=false) indicate a non-read-only, non-destructive operation. The description adds that the document is created empty, which is useful for setting expectations, but does not detail other behavioral aspects like permissions required or side effects (e.g., whether the process is modified). The description does not contradict annotations.

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 concise paragraph with a bullet list for parameters, placed after the main action statement. It front-loads the purpose. The parameter list could be integrated more tightly, but overall it is efficient with no redundant information.

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 complexity (5 parameters, optional output schema), the description covers key usage: creation of empty internal documents and hints at post-creation workflow. It does not explain the return value, but since an output schema exists (context signal), that omission is acceptable. It could mention that the tool returns the document ID for further operations.

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, but the description fully explains all 5 parameters: it specifies the format for processo, recommends sei_pesquisar_tipos_documento for id_serie, defines descricao as title, provides numeric values for nivel_acesso (0=público, 1=restrito, 2=sigiloso), and marks id_unidade as optional. This adds substantial 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?

Description clearly states 'Cria um novo documento interno (nativo) em um processo SEI.', identifying the specific verb (cria), resource (documento interno), and context (processo SEI). This distinguishes it from sibling tools like sei_criar_documento_externo, which creates external documents.

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 context: it creates an empty document and directs the user to other tools for content insertion (sei_listar_secoes, sei_editar_secao) and to fetch type codes (sei_pesquisar_tipos_documento). However, it does not explicitly state when to use this tool vs. its alternative (sei_criar_documento_externo), leaving the distinction implicit.

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?

Annotations are minimal (readOnlyHint=false, destructiveHint=false, openWorldHint=true) and consistent with description. Description adds significant behavioral details: file upload alternatives, size limit reference, naming importance, default values. No contradiction.

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 bullet points, each sentence adds value. No redundant or filler content. Front-loaded with main action.

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?

Comprehensive parameter and usage details, references other tools. Does not mention return value, but output schema exists. Could be more complete with a note on return format, but still very thorough.

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 description carries full burden. It explains each parameter in detail: processo (format), id_serie (referenced to another tool), nivel_acesso (enum values), data_elaboracao (format), file upload parameters with usage scenarios. Adds meaning beyond 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 creates an external document (upload file) in a SEI process, using specific verb and resource. It distinguishes from sibling tools like sei_criar_documento by specifying 'externo' and the upload 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?

Provides explicit guidance on when to use each file upload method (base64 vs path) and mentions using sei_pesquisar_tipos_documento for id_serie. Lacks explicit 'when not to use' but context is clear.

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?

Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds 'Cria' (creates) but does not clarify side effects (openWorldHint=true) or what 'especial' implies. No behavioral details beyond what annotations already convey.

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 (one sentence) but wastes no words. However, the brevity sacrifices necessary context. It could be expanded without becoming 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?

There is an output schema (not shown) but the description does not mention what the tool returns (e.g., created group ID). For a simple creation tool, the description should cover basic inputs and outputs. It is incomplete.

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 'nome' has no description in the schema (0% coverage) and the description does not explain its purpose, format, or constraints. The agent is left to guess that 'nome' is the group name.

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 it creates a special monitoring group ('grupo de acompanhamento especial') in SEI. The verb 'Cria' and resource are specific, and it distinguishes from sibling tools like 'sei_excluir_grupo_acompanhamento' (delete group) and 'sei_acompanhar_processo' (add process to monitoring), but doesn't explain what 'especial' means.

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 vs alternatives such as 'sei_acompanhar_processo' for process-level monitoring or 'sei_criar_bloco_interno' for internal blocks. The description provides no context for decision-making.

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?

Annotations indicate readOnlyHint=false (write) and openWorldHint=true, which the description confirms by stating creation. It adds the unique behavior of listing colors when id_cor is omitted, but no further side effects are disclosed.

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 concise, uses bullet points for parameters, and front-loads the core action. 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 (2 parameters, output schema exists), the description covers the key behavioral aspect (color listing on omission) and parameter roles. It could mention error conditions but is mostly 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 compensates by explaining both parameters: nome as the name and id_cor as the color ID with the special default behavior of listing available colors. It also directs to another tool for valid values.

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 creates a marker in the current unit, with specific verb and resource. It differentiates from siblings like excluir_marcador and desativar_marcador.

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 tool (creating a marker) and references sei_listar_cores_marcador for color options. However, it lacks explicit guidance on 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?

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral context: the observation is unit-wide and visible to all unit users, plus a note on version availability. No contradiction with annotations. It could include permission requirements but the added context is valuable.

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 brief and front-loaded with the core purpose. It includes a distinction from a sibling, version info, and an error recovery hint. No extraneous content, but could be slightly more structured with parameter details.

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 (2 required params, output schema exists), the description covers purpose, distinction, and error handling. However, the lack of parameter descriptions makes it incomplete. Annotations cover safety, so no need for that, but parameter semantics are missing.

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%. The description provides no additional meaning for the two parameters 'processo' and 'descricao' beyond their names. No format, examples, or constraints are given. This is a significant gap.

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 the verb (cria) and resource (observação da unidade em um processo). Explicitly distinguishes itself from sibling tool sei_criar_anotacao by explaining the difference: observation is linked to unit and visible to all users, whereas annotation is an individual post-it.

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 clear contextual guidance on when to use this tool vs. sei_criar_anotacao. Also includes a troubleshooting hint for failed calls (check version via sei_versao). However, it does not explicitly state when not to use the tool or mention alternative tools beyond the one sibling.

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?

Annotations declare this as a non-read-only, non-destructive mutation. Description adds that it returns IdProcedimento and ProtocoloFormatado, but doesn't elaborate on prerequisites (e.g., required unit context, permissions) or side effects beyond creation. Adequate but not extra.

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 header, parameter list, return note, and additional tip. Each sentence adds value, though the final note about assuntos could be integrated into the parameter list for brevity.

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 7 parameters and complex conditional logic (hipotese_legal), the description covers key aspects and references helper tools. Mentions output fields. Doesn't cover error scenarios or rate limits, but overall sufficient for a creation 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?

Input schema has 0% description coverage; the description fully compensates by explaining each parameter's purpose, default values, and how to obtain valid IDs (e.g., using sei_pesquisar_tipos_processo). The nivel_acesso parameter includes explicit mapping (0,1,2) and condition for hipotese_legal.

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 starts with 'Cria um novo processo no SEI,' a specific verb+resource. It clearly distinguishes from related tools like sei_alterar_processo (alter) and sei_enviar_processo (send).

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 detailed guidance on how to use each parameter, including references to helper tools (sei_pesquisar_tipos_processo, sei_pesquisar_hipoteses_legais) and conditional rules (hipotese_legal required for restrito/sigiloso). Missing explicit when-not-to-use, but context makes usage clear.

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?

Annotations indicate readOnlyHint=false (modifying state) and destructiveHint=false. The description adds no further behavioral details, such as prerequisites, idempotency, notification effects, or error conditions. For a mutation tool, more transparency is needed.

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 definition, parameter list, and two illustrative examples. Every sentence adds value, and the structure is easy to parse.

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 inputs and examples well but omits what the tool returns (success indication, errors) and any side effects. Since an output schema exists, the burden on the description for return values is reduced, but behavioral context remains incomplete.

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?

Despite 0% schema description coverage, the description thoroughly explains both parameters: 'referencia' is the SEI number or protocol, and 'tipo' has two enumerated values with examples. This adds significant meaning beyond the schema's basic titles.

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's purpose: 'Dá ciência em um documento ou processo no SEI' (gives knowledge on a document or process). Examples further clarify the intended use. However, it does not explicitly differentiate from sibling tools like sei_listar_ciencias or sei_consultar_processo, but the verb+resource combination is specific enough.

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. With many sibling tools related to processes and documents, the description lacks context for selection, leaving the agent to rely solely on the name.

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?

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds context: the tool modifies state (deactivates) but is non-destructive, and explains the effect on search and history. This goes beyond what annotations provide, giving useful behavioral detail.

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, front-loaded with the core action. Every sentence adds value: first states what it does, second explains effect and alternative. No wasted 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 simple one-parameter tool with an output schema, the description covers all necessary aspects: purpose, parameter format, effect, and relationship to sibling tools. It is self-contained and aligns with annotations.

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%, so the description must compensate. It explains that the parameter 'ids_marcadores' expects comma-separated IDs and what the tool does with them. This adds significant meaning beyond the schema's bare 'Ids Marcadores' title.

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 the action: 'Desativa marcador(es) sem excluir' (deactivates markers without deleting). It distinguishes from the sibling tool 'sei_excluir_marcador' which deletes, and explicitly mentions 'sei_reativar_marcador' for reactivation. The verb+resource is specific.

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: to deactivate markers without deletion, and that deactivated markers hide from search but retain history. It explicitly names the sibling tool for reactivation, providing an alternative. However, it does not explicitly state scenarios where this tool should not be used.

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?

Annotations indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), but the description only states the action without detailing behavioral traits such as permissions required, reversibility, or side effects (openWorldHint=true is unaddressed). The description adds minimal value beyond the annotations.

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 action. It is efficient but could benefit from including parameter details without becoming 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 the low parameter count and lack of schema descriptions, the description fails to mention prerequisites (e.g., block must exist), the meaning of 'unidades configuradas', or the output schema. The agent is left with incomplete context for correct invocation.

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 'id_bloco' has no description in the schema (coverage 0%). The tool description does not explain this parameter, relying solely on the parameter name for meaning. It should clarify what identifier is expected and how to obtain it.

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 'Disponibiliza' (makes available) and the resource 'bloco de assinatura' (signature block) for configured units. It distinguishes the action from similar sibling tools like 'criar' or 'incluir documento' by focusing on availability, but could be more explicit about how it differs from 'cancelar_disponibilizacao'.

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 context about the tool's role in the signing workflow ('Após disponibilizar, os usuários das unidades podem assinar os documentos'), implying it is used before signing. However, it offers no guidance on when not to use it or alternatives like 'assinar_bloco' or 'criar_bloco_assinatura'.

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