mcp-seipro

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.1
Disambiguation3/5
Many tools have similar purposes (e.g., listar, pesquisar, consultar for processes) and the sheer number (116) creates overlap, but detailed descriptions help differentiate specific use cases.
Naming Consistency4/5
All tools start with 'sei_' and follow snake_case with verb_noun pattern, mostly consistent Portuguese verbs (listar, criar, excluir). Minor mix of 'consultar' vs 'listar' for similar actions.
Tool Count2/5
116 tools is excessive for a typical MCP server; it overwhelms agents and includes many edge-case or administrative functions that could be consolidated.
Completeness4/5
The tool set extensively covers process, document, bloc, marker, signature, and credential management, with only minor missing bulk or advanced operations.
Average 3.8/5 across 116 of 116 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds minimal behavioral context (e.g., it lists within the unit) but does not elaborate on pagination behavior, authorization needs, or response characteristics. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. However, the troubleshooting line ('Se falhar com erro inesperado...') could be considered extraneous and might be better placed elsewhere. Overall, it is mostly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which may document return values), the description lacks context about what 'acompanhamento especial' means, pagination behavior, and how this tool differs from similar listing tools. Given the complexity (many siblings), the description is incomplete for an agent to make an informed decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (limit and pagina) with no descriptions, and the description provides no information about them. Schema description coverage is 0%, so the description completely fails to add parameter semantics. The agent would have to infer meaning from names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists processes with special monitoring in the current unit ('Lista processos com acompanhamento especial na unidade atual'). This gives a specific verb and resource. However, it does not explicitly distinguish it from the similar sibling tool 'sei_listar_meus_acompanhamentos', which lists the user's own monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides version availability and a troubleshooting hint, but no guidance on when to use this tool versus alternatives like sei_listar_meus_acompanhamentos. Given the many sibling tools, the lack of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true and openWorldHint=true. The description adds no further behavioral context (e.g., listing only groups the user can access, or that the filter is partial). Acceptable given annotations, but could be improved by clarifying scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one short sentence), but at the cost of omitting important details about parameters and usage. Conciseness is positive, but structure lacks essential info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and existence of output schema and annotations, the description is too sparse. It could explain the relationship to other monitoring tools or specify that groups are used for 'acompanhar processo' actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 information about the 'filtro' parameter. It defaults to empty string but its purpose or expected format is not explained, which is critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists available monitoring groups ('grupos de acompanhamento disponíveis'). Verb 'listar' and resource 'grupos de acompanhamento' are specific. However, it does not differentiate from sibling tools like 'sei_listar_meus_acompanhamentos' or 'sei_listar_acompanhamentos_unidade'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other listing tools or related tools like 'sei_criar_grupo_acompanhamento'. Agent must infer context from name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds no behavioral context beyond that, but does not contradict annotations. It is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it omits critical details about parameters and usage. Conciseness is good, but not at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description is too sparse for a search tool with two parameters. It does not explain what contacts are returned, how filtering works, or what the limit parameter controls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description fails to explain the purpose or usage of the two parameters ('limit' and 'filtro'). Agents must rely solely on parameter names, which may be insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search contacts registered in SEI,' clearly specifying the verb (search) and resource (contacts). However, it does not differentiate from other search tools like sei_pesquisar_processos or sei_pesquisar_usuarios, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, typical use cases, or scenarios where other tools are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is expected to modify state (reopening). However, the description adds no further behavioral details, such as whether the block becomes available for signing again, what happens to existing signatures, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, and the first sentence immediately states the purpose. It is front-loaded and efficient, though it sacrifices crucial details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having a single parameter and presumably a simple output, the description omits parameter semantics and return value context. The version error note adds minor value, but overall the description is insufficient for an agent to use the tool confidently without prior knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id_bloco' receives no explanation in the description. Schema coverage is 0%, meaning the agent has no clue what this ID represents or how to obtain it. The description should at least mention it is the ID of the concluded block to reopen.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reabre' (reopens) and the resource 'bloco de assinatura concluído' (completed signature block), making the purpose immediately obvious. It distinguishes from sibling tools like sei_concluir_bloco_assinatura and sei_excluir_bloco_assinatura.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool vs. alternatives. The description does not mention prerequisites, context, or what to do after reopening. The version note is tangential and does not guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds no further behavioral context, such as prerequisites, side effects, or what reopening entails. Minimal value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short (three lines) and front-loaded with the action. However, the version note and error tip add minor value and could be removed or relegated to a notes section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown) and simple parameter, the description lacks essential context: what is a 'bloco interno', what state must it be in, what reopening achieves, and what the output contains. An agent would need external knowledge to use this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description provides zero information about the required parameter 'id_bloco'. No guidance on format, source, or semantics, leaving the agent completely uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's action clearly: 'Reabre bloco interno concluído' (reopens concluded internal block). The verb 'reabre' and resource 'bloco interno concluído' are specific, and it distinguishes from sibling tools like 'sei_concluir_bloco_interno' (concludes) and 'sei_reabrir_bloco_assinatura' (reopens signature block).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'sei_concluir_bloco_interno' or 'sei_reabrir_bloco_assinatura'. The version info and error tip are technical but do not help an agent decide context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('retorna'), but annotations have readOnlyHint=false, indicating possible side effects. This contradiction reduces trust. No other behavioral details are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes version info and troubleshooting advice. It could be more concise by removing version details, but it remains focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to detail return values. However, it lacks context about what the block represents and potential error conditions beyond version checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (id_bloco) with no description, and the tool description does not elaborate on its meaning or format. With 0% schema description coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the signature block for the source unit. However, it does not differentiate from sibling tools like sei_listar_documentos_bloco_assinatura which lists documents within a block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. It mentions troubleshooting for version issues but no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context beyond stating the action. It is consistent with annotations but adds no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but minimal. It lacks structure but gets the point across without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one parameter and an output schema (present but not shown), the description is adequate. However, it could benefit from mentioning the expected output or the nature of 'interessados'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'processo' has no description in the input schema (0% coverage) and the tool description does not elaborate on its meaning or format. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists interested parties of a process, a specific verb+resource. However, it does not differentiate from sibling list tools like sei_listar_documentos or sei_listar_secoes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description lacks usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat that. It adds version context and a fallback instruction for errors. However, it does not disclose any other behavioral traits such as permissions, pagination, or what happens if the block does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the primary purpose, and the second provides a helpful troubleshooting note. No unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, read-only) and the presence of an output schema, the description is minimally adequate. However, it does not mention the output schema or any information about the returned data, which would be helpful for understanding the tool's results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its only parameter 'id_bloco', and the description does not explain what this parameter represents or how to obtain it. The description adds no semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lista processos de um bloco interno' clearly indicates the action (list) and resource (processes of an internal block). The purpose is specific and unambiguous, but it does not explicitly differentiate from the sibling 'sei_listar_processos' which lists all processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes version information and a troubleshooting suggestion, but it lacks guidance on when to use this tool versus alternatives like 'sei_listar_processos'. No prerequisites or context for invocation are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only and open-world behavior. The description adds no behavioral context such as pagination limits, result ordering, or side effects. It does not clarify what 'pesquisar' entails beyond a basic search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but fails to include necessary details. It is not well-structured; it only states purpose without layering information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with no schema descriptions and an output schema (unknown), the description is insufficient. It does not cover return format, filtering logic, or limit behavior, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not. 'limit' and 'filtro' are left to inference, with no details on format, allowed values, or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for existing signature blocks ('Pesquisa blocos de assinatura existentes'), with a specific verb and resource. It distinguishes from sibling tools that create, modify, or list specific aspects of signature blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like sei_listar_blocos_documento or sei_listar_documentos_bloco_assinatura. There is no mention of use cases, prerequisites, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, indicating safe read behavior. The description adds version availability and suggests a fallback for unexpected errors, offering some context beyond annotations, but doesn't elaborate on side effects or return structure (though output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose. It avoids unnecessary words, though the version and error hint could be positioned later. Overall effective use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists to describe return values, the tool's simplicity is undermined by missing parameter explanations. The description fails to cover essential input details, making it incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the three parameters (limit, filtro, pagina). With 0% schema coverage, the description fails to compensate, leaving agents without guidance on how to use these inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for conference types for external documents, and explains what 'tipo de conferência' means. It distinguishes from sibling tools like sei_pesquisar_tipos_documento by its specific focus on external document conference types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as sei_pesquisar_tipos_documento or sei_pesquisar_hipoteses_legais. The description only provides version info and an error fallback, but lacks context about suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context beyond the fact it lists documents. It does not mention pagination, permissions, or other constraints, but annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. Every word is necessary and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one parameter and an output schema, the description is minimal. It does not explain what a signature block is or provide any context about the output, but it is adequate for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for parameter description, and the tool description does not explain the parameter 'id_bloco'. Although the name is somewhat self-explanatory, the lack of description limits an agent's ability to correctly format or select the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists documents of a signature block, using specific verb and resource. While it doesn't differentiate from similar list tools like 'sei_listar_documentos', the context of sibling tools implies it is specific to bloco_assinatura, thus overall clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support among many sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds version availability and an error handling suggestion, which provides some additional behavioral context but does not elaborate on pagination, data scope, or order.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus version info, front-loaded with the main purpose. Every sentence adds value without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters and the presence of an output schema (not shown), the description is adequate but not fully complete. It lacks explanation of output format, pagination behavior, and the meaning of 'acompanhamento especial'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mention or explain the parameters (limit, pagina). The agent must rely solely on parameter names and defaults, which are somewhat self-explanatory but lack context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists processes the user is following (acompanhamento especial). The name 'meus_acompanhamentos' and the description align. However, it does not differentiate from siblings like sei_listar_acompanhamentos_unidade, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides version information and a fallback tip for errors, but does not explain when to use this tool versus alternatives (e.g., sei_listar_processos or sei_acompanhar_processo). No when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds that the tool first queries active monitoring before removal, which provides useful behavioral context beyond annotations. However, it does not disclose potential side effects (e.g., if monitoring does not exist) or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the primary action. No unnecessary words, and every sentence adds value by clarifying the two-step process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema needed for understanding the action), the description covers the core functionality. However, it omits handling of edge cases (e.g., no active monitoring to remove) and does not reference the output schema, which could help agents understand the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'processo' with no description. The tool description does not elaborate on the parameter's format, meaning, or constraints. With 0% schema description coverage, the description fails to compensate, leaving the agent to infer from the parameter title alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove acompanhamento especial de um processo') and resource. It distinguishes from siblings like sei_acompanhar_processo (add) and sei_listar_acompanhamentos (list), but does not explicitly contrast with them, leaving some ambiguity for new users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description only states what it does; it does not mention prerequisites, nor when to choose remove over list or add. Users must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description doesn't need to emphasize safety. However, the description adds no behavioral details beyond the obvious (e.g., whether empty results are possible).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence directly stating the function, with no extraneous words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter, read-only nature and existing output schema, the description covers the essential purpose. However, missing parameter guidance slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id_documento' has 0% schema description coverage and the description provides no explanation of its format or usage, forcing agents to infer from the name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (listar) and resource (assinaturas de um documento), distinguishing it from sibling tools like sei_listar_documentos which list documents broadly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; no mention of prerequisites or exclusion criteria. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds only a version note and a fallback for errors, with no additional behavioral context like pagination, limits, or side effects. Very minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The core purpose is in the first sentence, and the second adds a useful version note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. Annotations handle safety. The description lacks details about error cases (e.g., empty list) or prerequisites, but for a simple read-only lookup with one parameter, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the parameter. It does indicate that id_documento is the document whose blocks are listed, but no format, constraints, or how to obtain it. Minimal semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool lists signature blocks (blocos de assinatura) that contain a given document. The verb 'Lista' and resource 'blocos de assinatura' are specific, and it distinguishes from sibling tools like sei_listar_documentos_bloco_assinatura that list documents in a block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It only provides version information and a generic error suggestion. Among siblings, sei_listar_documentos_bloco_assinatura is the inverse, but this is not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the description adds minimal value. It clarifies it lists a 'history', but doesn't elaborate on scope (e.g., only active suspensions) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no waste. However, it could be more verbose to include additional context without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, annotations, and existence of an output schema, the description is adequate but lacks usage guidelines and param details, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should compensate but only mentions 'processo' implicitly. The parameter name is self-explanatory, but no format or value constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('listar'), resource ('sobrestamentos'), and target ('processo'), and it distinguishes from siblings like 'sei_sobrestar_processo' and 'sei_remover_sobrestamento' which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'sei_consultar_processo' or 'sei_pesquisar_processos'. No exclusion criteria or contextual hints are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's mention of listing open units adds minimal behavioral context. No additional details like permissions, side effects, or output structure are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no extraneous words. It is front-loaded and concise, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (unseen), the description does not mention what the output contains (e.g., unit names, IDs). Given the tool's simplicity and annotations covering safety, the description is barely adequate—missing return value context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'processo' is explained as the process identifier, which adds some meaning beyond the schema (which has no description). However, no format, length, or example is given. With 0% schema coverage, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists units where a process is open (verb 'listar', resource 'unidades'). It distinguishes from sibling 'sei_listar_unidades' by specifying the process context, but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a process and want to know its associated units, but gives no guidance on when to avoid it or compare with alternatives like 'sei_listar_unidades' or 'sei_listar_orgaos'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (destructiveHint: true) but adds no extra behavioral context beyond what annotations already provide. It does not disclose results, side effects, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one short sentence) and front-loaded with the primary action. However, it could include a brief note on usage or behavior without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no nested objects, output schema exists), the description is adequate. However, it omits details like whether non-existent IDs are handled gracefully, or if the operation is irreversible (though destructiveHint suggests it).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'ids_marcadores' is described as 'IDs separados por vírgula', clarifying the expected format (comma-separated) and cardinality (multiple IDs allowed). The schema only specifies type string, so the description adds valuable semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (excluir) and resource (marcador), with additional detail on the input format (IDs separados por vírgula). It distinguishes itself from sibling tools like sei_criar_marcador and sei_marcar_processo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., sei_desativar_marcador for deactivation), nor any prerequisites or contexts. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutating) and destructiveHint=false, but the description adds no behavioral details such as side effects, permission requirements, or limits. It only explains parameter format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two lines of purpose and two lines of parameter info. It is front-loaded and to the point, though the parameter info could be integrated more elegantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (2 required params) and has an output schema, the description covers the basics but lacks context about success/error behavior, block existence requirements, or output meaning. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaningful parameter explanations: id_bloco is explicitly 'ID do bloco' and processos is 'IdProcedimento(s) separados por vírgula', which clarifies the comma-separated format beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inclui processo(s) em um bloco interno' (includes process(es) in an internal block), using a specific verb and resource. It distinguishes from sibling tools like sei_retirar_processo_bloco_interno (remove) and sei_criar_bloco_interno (create block).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., block must exist) or context. Sibling tools like sei_criar_bloco_interno are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds version requirements and an error troubleshooting suggestion but does not disclose details about behavior on missing inputs, permission failures, or side effects. This meets baseline with minor added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences plus version and error lines. It is front-loaded with the main action. The version info is slightly tangential but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, output schema exists), the description adequately covers purpose and version context. It omits prerequisites (e.g., user access) but is otherwise sufficient for a straightforward read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no property descriptions. The description only implies that 'processo' identifies the process, but provides no format, requirements, or additional meaning. This is insufficient compensation for the missing schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists access credentials for a confidential process. It uses a specific verb (lista) and resource (credenciamentos de acesso a um processo sigiloso), distinguishing it from siblings that grant, renounce, or revoke credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like sei_conceder_credenciamento or sei_listar_assinaturas. There is no explicit when-to-use or when-not-to-use information, only a version note and error handling tip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds version dependency info but does not elaborate on other behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 lines) and front-loaded with the main purpose. Every sentence adds value: purpose, version info, error handling advice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is adequate but lacks parameter semantics, which is a gap for a tool with two optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 purpose or syntax of the two parameters ('limit' and 'pagina'). The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available document model groups ('grupos de modelos de documento'), with a specific verb and resource. It distinguishes from the sibling tool 'sei_listar_modelos' which likely lists individual models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions version availability and error recovery but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like 'sei_listar_modelos'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=false, destructiveHint=false) but adds no extra behavioral context beyond the basic action. It does not disclose side effects, required permissions, or error scenarios. With annotations covering safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and one bullet for a parameter. It is front-loaded and wastes no words, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and many siblings, the description is too minimal. It does not explain return values (though output schema exists), error handling, or the block's state. More context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the 'documentos' parameter, specifying 'ID(s) de documento(s) separados por vírgula', which clarifies the format. However, the 'id_bloco' parameter is not described. Since schema coverage is 0%, the description partially compensates but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retira documento(s) de um bloco de assinatura' which clearly specifies the action, resource, and scope. It distinguishes from sibling tools like sei_incluir_documento_bloco_assinatura (add) and sei_listar_documentos_bloco_assinatura (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites (e.g., block must exist), conditions for removal, or when not to use it. The description lacks context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive behavior, which matches the description. The description adds detail about the optional linked process parameter, but does not disclose other behavioral traits like permission requirements or side effects beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, front-loading the main action and listing parameters clearly. A minor improvement could be condensing the parameter listing further, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no nested objects) and the presence of an output schema, the description covers the essential logic and parameter details. It does not explain return values, but the output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the full burden. It explains the format of 'processo', that 'motivo' is required, and the effect of 'processo_vinculado', adding meaning beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sobresta um processo no SEI') with a specific verb and resource. It lists parameters but does not explicitly differentiate from sibling tools like 'sei_remover_sobrestamento', though the name itself provides distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., sei_remover_sobrestamento for removing suspension). No context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with annotations (readOnlyHint=true) and adds useful behavioral context: version dependency, error handling tip, and that the result ID is used for creating processes. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each adding value: purpose, usage, version info, and an error handling tip. Front-loaded with purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no param descriptions, the description does not cover how pagination works or what the output contains beyond mentioning the ID. However, existence of an output schema and annotations partly compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it does not define 'limit', 'filtro', or 'pagina'. Only default values are in the schema, leaving the agent without guidance on filtering or pagination behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for available subjects for processes and explains how to use the returned ID. It distinguishes the tool implicitly as the only one dealing with 'assuntos' among many siblings, but lacks explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on using the result ('Use o ID retornado...') and error handling, but does not compare this tool to similar search tools like sei_pesquisar_hipoteses_legais or sei_pesquisar_tipos_processo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. Description adds version info and troubleshooting for unexpected errors, but no additional behavioral traits beyond annotations. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (5 lines) and front-loaded with core purpose. Version and troubleshooting info add value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists to document return values. Description covers purpose, differentiation, version, and a fallback. However, parameter details are missing, leaving gaps for a search tool with 4 undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description does not explain any of the four parameters (limit, filtro, pagina, id_orgao) beyond their names, failing to compensate for lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'Pesquisa' and resource 'usuários' with scope 'por palavra-chave no órgão'. Clearly distinguishes from sibling sei_listar_usuarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with sei_listar_usuarios (unit-based vs. organ-wide search). Provides version availability and troubleshooting hint. Lacks explicit when-not-to-use but adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool writes data (registers an activity), aligning with readOnlyHint=false and destructiveHint=false. However, it does not disclose side effects beyond the basic action, such as whether the activity is immediately visible or if it triggers notifications. The annotations already provide the safety profile, so the description adds minimal behavioral context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence and two bullet points. It is front-loaded with the main action. However, the structure could be improved by separating usage guidelines from parameter descriptions, and the bullet points are slightly informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, an output schema (present but not shown), and annotations, the description covers the basics. However, it lacks any mention of return value, behavior upon duplicate activities, or integration with other process operations. With many sibling tools, a brief usage hint would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully compensates for the 0% schema parameter description coverage by clearly explaining the meaning and format of each parameter: 'processo: protocolo formatado ou IdProcedimento' and 'descricao: texto do andamento'. This goes beyond the schema, which only provides titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Registra um andamento') and resource ('processo'), making the purpose evident. However, it does not explicitly distinguish this tool from sibling tools like sei_alterar_processo or sei_criar_processo, missing an opportunity to clarify differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., sei_consultar_processo for reading, sei_alterar_processo for modifying metadata). The description only states what the tool does, without any context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds context: it filters the current unit, availability since a specific version, and a troubleshooting step for unexpected errors. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences. The main purpose is front-loaded. However, it includes version information and troubleshooting which, while useful, could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters are undocumented in both schema and description, the description is incomplete. An output schema exists, so return values are handled, but parameter semantics are missing, which is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description does not explain any of the three parameters (limit, filtro, pagina), leaving the agent without guidance on their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Pesquisa unidades excluindo a unidade atual' (search units excluding the current unit), which is a specific verb and resource. It distinguishes from sibling tool sei_pesquisar_unidades which likely includes the current unit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is useful for processing ('tramitação') and that it already filters the user's unit. It also provides a troubleshooting hint for version checks. However, it does not explicitly exclude alternatives or state 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries less burden. It adds that the tool is needed for certain access levels, but doesn't detail pagination or other behavioral traits. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and to the point, with examples. No unnecessary words. Could integrate parameter examples more clearly but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values are covered. Description explains purpose and usage context. Missing parameter details for pagination, which is important for a search tool. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage for 3 parameters. The description provides example search terms ("pessoal", "controle interno"), which helps with 'filtro' but does not explain 'limit' or 'pagina'. Partial compensation but significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches legal hypotheses available in SEI, with specific verb (pesquisa) and resource (hipóteses legais). It distinguishes from sibling tools like sei_pesquisar_processos by focusing on legal hypotheses for restricted access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when creating processes/documents with restricted or secret access. Also explains how to use the result (pass 'id' to sei_criar_processo). Does not list alternatives 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, so the agent knows this is a delete operation. The description adds that IDs are comma-separated and suggests checking version on failure. However, it does not elaborate on consequences (e.g., cascading effects or irreversibility) beyond what annotations indicate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences. The first sentence states the purpose and input format. The second provides version context. The third gives a troubleshooting hint. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, high annotation coverage, output schema exists), the description is mostly sufficient. It covers purpose, parameter format, and version constraints. It does not describe the output, but the presence of an output schema reduces that need. A slight improvement would be to mention that deletion is permanent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It specifies 'IDs separados por vírgula', which clarifies the format for the single parameter 'ids_blocos'. It does not explain what these IDs represent, but most agents can infer from the tool name. This provides minimal but adequate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Exclui bloco(s) de assinatura' (deletes signature blocks), which is a specific verb+resource. The comma-separated IDs detail clarifies the input format. This distinguishes it from sibling tools like 'sei_retirar_documentos_bloco_assinatura' or 'sei_concluir_bloco_assinatura'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the version requirement (mod-wssei 2.0.0) and a troubleshooting fallback, but it does not explicitly state when to prefer this tool over alternatives (e.g., when to use 'sei_excluir_bloco_interno' vs this). The usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as destructive (destructiveHint=true). Description adds that it deletes blocks and mentions version requirements, but does not detail side effects (e.g., impact on enclosed processes). Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus version line, front-loaded with the main action. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values are not needed. One parameter explained. However, lacks information on error conditions or idempotency. Mostly complete for a simple destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds 'IDs separados por vírgula' clarifying the input format for ids_blocos. This adds meaning beyond the schema's bare title but could be more explicit (e.g., 'IDs dos blocos internos').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Exclui bloco(s) interno(s)' (deletes internal block(s)), specifying the action and resource. Differentiates from sibling tools like sei_excluir_bloco_assinatura and block manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides version availability and a troubleshooting hint, but no explicit guidance on when to use this tool vs alternatives (e.g., when to delete vs conclude or reabrir a block). Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds contextual info about listing markers in the current unit without contradicting annotations. It adds moderate value beyond what's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences: the first states the purpose, the second provides a usage hint. No superfluous information, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. However, the lack of parameter explanations is a significant gap, and the description does not fully compensate for the low schema coverage. Annotations provide safety info but not parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description should compensate by explaining the 'limit' and 'filtro' parameters, but it does not mention them at all, leaving the agent with no guidance on their purpose or syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists available markers in the current unit, using specific verb 'lista' and resource 'marcadores', and distinguishes from sibling tools like sei_criar_marcador or sei_excluir_marcador.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear hint about using the returned 'id' in sei_marcar_processo, giving context for usage, but does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false. Description adds that it removes from 'any user', which is useful context. However, it doesn't elaborate on permissions, side effects, or reversibility. With annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-line description with a bullet for the parameter. Front-loaded with purpose. Every sentence earns its place. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool and presence of an output schema, the description covers the action and parameter format adequately. However, adding a comparative hint to sei_atribuir_processo would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It states 'processo: protocolo formatado ou IdProcedimento', which adds format semantics (protocol vs internal ID) beyond the schema's bare string type. This is valuable but could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Remove a atribuição de um processo (desatribui de qualquer usuário)' – a specific verb and resource. It distinguishes from sibling tools like sei_atribuir_processo (assign) and sei_consultar_atribuicao (consult).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like sei_atribuir_processo or sei_cancelar_assinatura. No when-to-use or when-not-to-use information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms deletion ('exclui'), which aligns with the destructiveHint=true annotation. However, it adds no additional behavioral context beyond what annotations already provide, such as side effects 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences: one for the action and one for the input format. No redundant information, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple delete action and annotations, the description covers the basic purpose and input format. However, it omits details like whether the deletion is permanent, what happens to associated data, or any confirmation requirements. An improved description could add more context for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for the single parameter, the description adds crucial format information: IDs are comma-separated. This compensates for the schema gap and clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Exclui grupo(s) de acompanhamento especial') and distinguishes it from sibling tools like creating or listing groups. The verb 'Excluir' and the resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using comma-separated IDs but provides no explicit guidance on when to use this tool versus alternatives. The context implies deletion, but lacks when-not or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds the version requirement and failure handling. It does not elaborate on what 'related' means or return format. With annotations providing the safety profile, the description contributes some behavioral context but not extensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three lines) and front-loads the main purpose. Each sentence adds value: purpose, version requirement, and failure check. It could combine the last two lines for even greater conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, annotations, and an output schema (not shown but exists), the description provides essential information. It explains the tool's action, version dependency, and recovery. It lacks output details, but the schema likely covers that, making it sufficiently complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'processos relacionados a um processo', implying the parameter 'processo' identifies the process. This adds meaning but lacks format or example specifics. For a single required parameter, the context is partially helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lista processos relacionados a um processo' (Lists processes related to a process), providing a specific verb and resource. It distinguishes itself from siblings like sei_listar_processos (general list) and sei_consultar_processo (detail view) by focusing on related processes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a version requirement ('REQUER mod-wssei 3.0.2+') and failure recovery guidance ('Se falhar, use sei_versao para verificar'). It does not explicitly state when to use this versus alternatives, but the context provides reasonable clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the tool is known to be read-only and open-world. The description adds version availability and an error recovery suggestion, which is useful beyond annotations. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, each adding value: purpose, definition of term, version info, error handling. It is appropriately sized and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values are not needed. However, the description omits information about pagination behavior or how filters work, leaving some gaps for a search tool with pagination parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explain or add meaning to any of the three parameters (limit, filtro, pagina). Although the parameters are somewhat self-explanatory, the description should compensate for the lack of schema descriptions, which it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for internal standard texts (textos padrão) available in the unit, and explains what those are (reusable templates for filling documents automatically). This distinguishes it from sibling tools like sei_pesquisar_processos or sei_pesquisar_contatos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when the tool is available (mod-wssei 2.0.0+) and includes error-handling guidance (use sei_versao to check version if failure). It does not explicitly state when not to use it or compare to alternatives, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate that the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the mutation action ('Remove'), which is consistent. However, it does not disclose additional behavioral traits like reversibility or permission requirements. The parameter format hint is useful but not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the main action. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (present but not shown), the description covers the action and parameter format. It could be improved by clarifying prerequisites or side effects, but it is mostly complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides crucial format guidance for the 'processo' parameter ('protocolo formatado (ex: 50300.018905/2018-67) ou IdProcedimento'). Since the schema only specifies type 'string' with no format, the description compensates fully for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove o sobrestamento') and the resource ('um processo no SEI'). The verb 'Remove' and noun 'sobrestamento' are specific, and it distinguishes from related tools like sei_sobrestar_processo (which adds suspension) and sei_listar_sobrestamentos (lists suspensions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as sei_sobrestar_processo or sei_listar_sobrestamentos. The description does not mention prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not clarify the impact of removal (e.g., whether processes are permanently removed or just unlinked). No behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: one-line action followed by bullet-point parameter definitions. No superfluous text, front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple removal operation with output schema present. Lacks details on preconditions, error handling, or confirmation, but sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds essential meaning: id_bloco is identified as 'ID do bloco' and processos as 'IdProcedimento(s) separados por vírgula', specifying the required format beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Remove' and resource 'processo(s) de um bloco interno', clearly distinguishing from sibling tools like 'sei_incluir_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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description clearly states the action (removal from an internal block), implying when to use it, but does not explicitly mention alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=true) already indicate safety and possible external data access. The description adds version availability and a troubleshooting step but does not detail failure modes or response behavior. The description is consistent with annotations and adds marginal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose. No unnecessary words. Every sentence provides value: purpose, usage guidance, version info, troubleshooting. Very efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple access-check tool with an output schema (not shown but exists), the description covers purpose, usage, and version. It could mention return type briefly, but the output schema fills that gap. Given context signals (1 param, annotations, siblings), it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no information about the 'processo' parameter beyond its inferred purpose. The parameter name is clear, but the description does not clarify format, constraints, or valid values. With only one parameter and no param docs, a baseline of 2 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks user access to a process ('Verifica se o usuário tem acesso a um processo'). This distinguishes it from siblings like sei_consultar_processo (retrieve details) or sei_alterar_processo (modify). The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it before operations on restricted processes ('Útil para checar permissão antes de operações em processos restritos'). It also provides a troubleshooting hint (use sei_versao on error). While explicit when-not-to-use or alternatives are missing, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by explaining the historical (time-series) nature of the output, and provides version-specific availability and error recovery guidance. This goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three efficient sentences: purpose, what it shows, and version/error handling. No extraneous information; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema, the description covers purpose, behavior, version constraints, and a fallback action. It is sufficiently complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'processo' has no description in the schema (0% coverage), and the tool description does not clarify its format or constraints (e.g., expected input pattern). The description implies it's the process identifier, but lacks additional semantics that would aid correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the history of markers for a process, specifying it shows which markers were applied/removed over time. This distinguishes it from sibling tools like sei_pesquisar_marcadores (search markers) and sei_consultar_marcador_processo (current marker state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides version availability and a troubleshooting hint, but does not explicitly state when to use this tool vs. alternatives like sei_consultar_marcador_processo. Usage context is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description's verb 'inclui' (include) is consistent. However, the description adds no further behavioral context beyond what annotations provide, such as side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences for the tool purpose and a bulleted parameter list. No unnecessary words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write tool with two required parameters and an output schema, the description covers purpose and parameter semantics adequately. It could mention the prerequisite that the signature block must exist, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds valuable detail: it explains the id_bloco parameter as 'ID do bloco de assinatura' and documentos as 'ID(s) de documento(s) separados por vírgula', clarifying the input format for the comma-separated list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Inclui documento(s) em um bloco de assinatura' (include documents in a signature block) and the target resource. It distinguishes from sibling tools like sei_retirar_documentos_bloco_assinatura (remove) and sei_listar_documentos_bloco_assinatura (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for adding documents to an existing block, but does not mention prerequisites, when not to use, or relationships with other tools like sei_criar_bloco_assinatura.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds version context and a specific error recovery action (use sei_versao), which provides value beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence states purpose immediately. Second provides version and error guidance. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one required parameter, output schema present, and annotations covering safety, the description provides sufficient context: what it does, version requirement, and a fallback. Minimal gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id_orgao' has no description in the schema and the description only vaguely implies its role ('para um órgão'). No format or source guidance is given, so description adds little meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Lista os contextos disponíveis para um órgão' with specific verb (listar) and resource (contextos). No sibling tool has 'contextos' in name, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides version requirement and a fallback error suggestion, but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and result variability. Description adds version availability and error recovery, but does not elaborate on return format or side effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, version availability, error recovery. Concise and front-loaded with purpose, but the version note could be separated or moved to metadata. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, annotations, and an output schema, the description covers purpose, availability context, and a recovery action. Fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so the description does not need to add parameter details. Baseline for 0 params is 4; description provides no extra param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb 'Lista' (lists) and resource 'órgãos cadastrados' (registered organs), distinguishing it from siblings like sei_listar_unidades (units).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides basic usage context (listing organs) but no guidance on when to use versus alternatives like sei_listar_unidades. Includes a troubleshooting tip for version check but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds version information and a troubleshooting hint for errors, which provides minor behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, version requirement, and error resolution hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existing annotations, the description covers the essential purpose, version dependency, and error handling. The output schema provides return structure, so completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the input schema is empty with 100% coverage. The description does not need to add parameter semantics; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lista órgãos disponíveis para assinatura', specifying the action (list) and the resource (organs available for signature). This distinguishes it from sibling 'sei_listar_orgaos' which likely lists all organs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The version requirement and error fallback provide some context, but alternatives like sei_listar_orgaos are not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds version dependency and error handling advice (use sei_versao). No contradiction. Missing details on rate limits or other behaviors, but adequate given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding distinct value: main purpose, sibling differentiation, version/error info. No redundant or filler content. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (3 optional params, output schema exists) and low schema coverage, description is incomplete. It covers purpose and version but omits parameter semantics. Output schema exists but parameters are undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 3 parameters with 0% description coverage. The tool description does not explain any parameter (limit, filtro, pagina). With low schema coverage, description should compensate, but it fails to add meaning beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches document types for external documents, and explicitly distinguishes from sibling sei_pesquisar_tipos_documento by noting scope difference. Uses specific verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for external document types vs general. Includes version availability and troubleshooting tip. However, no explicit when-not-to-use or alternative suggestions beyond the sibling name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds context about pagination and parameter usage but does not go into deeper behavioral details like rate limits or result structure, which are partially covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences cover purpose, parameters, and usage guidance. Every sentence adds value, and the format is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 optional params, pagination) and the presence of an output schema, the description adequately covers usage patterns and parameter roles. It does not explain return fields, but that is delegated to the schema. A minor gap is the lack of explicit mention that all parameters are optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden. It explains 'filtro' with examples, mentions 'favoritos' expects 'S', and describes 'limit/pagina' as pagination. However, it does not detail default values or possible values for 'favoritos' beyond 'S', leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for process types in SEI and explicitly mentions using the returned 'id' in sei_criar_processo, distinguishing it from other search tools like sei_pesquisar_processos or sei_pesquisar_hipoteses_legais.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the result's 'id' should be used in sei_criar_processo, providing clear context for when to use this tool. It does not explicitly mention when not to use it, but the sibling list contains no duplicate functionality, making the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint false) and non-destructive (destructiveHint false). The description adds that it reactivates, which is consistent but adds limited additional behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with the verb. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description provides enough context. It could mention prerequisites or error cases but is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the parameter format (IDs separated by commas), adding meaning beyond the schema's title alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reactivating deactivated markers. It uses a specific verb and resource, and the context of siblings (e.g., sei_desativar_marcador) distinguishes it perfectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to reactivate markers) but provides no explicit guidance on when not to use or alternatives. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (mutations) and destructiveHint=false. The description adds that it 'confirms receipt,' which is consistent. However, it does not elaborate on side effects or permissions, so it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose, one for parameter explanation. No wasted words, front-loaded, and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 1 parameter and an output schema, the description is adequate. It covers the core action and parameter format. Minor lack of detail on what 'recebimento' entails, but sufficient for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains that 'processo' can be a formatted protocol or IdProcedimento, giving crucial format guidance that the schema lacks. This compensation merits a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('confirms the receipt') and resource ('process'), clearly stating the tool's action. Among siblings (e.g., sei_enviar_processo, sei_concluir_processo), this stands out as the receipt confirmation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use it ('to confirm receipt in the current unit') but provides no explicit when-not-to-use or alternative tools. Context is clear, but guidance on exclusion is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description explains that the user loses access and provides error recovery advice ('Se falhar com erro inesperado, use sei_versao para verificar a versão instalada'). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences: purpose, effect, and error recovery hint. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, effect, and error handling but omits parameter details and return value (output schema exists but is not described). Adequate for a simple tool but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not elaborate on the 'processo' parameter (e.g., format or identifier type). The parameter name is self-explanatory given context, but the lack of explicit semantics for an AI agent is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'renunciar' (renounce) and resource 'credenciamento de acesso a um processo sigiloso'. It distinguishes from siblings like sei_conceder_credenciamento and sei_cassar_credenciamento by specifying self-renunciation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for voluntary self-renunciation ('O próprio usuário perde o acesso'), but does not explicitly state when not to use or mention alternatives. Sibling tools provide context, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with listing. Description adds version availability info and a troubleshooting note. No contradictions. Adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three meaningful lines plus bullet points. Front-loaded with purpose. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters (none required), output schema exists, and annotations present, the description covers filtering and version info. Missing a brief explanation of pagination parameters (limit, pagina), but otherwise complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description only mentions two parameters (id_grupo, filtro) briefly. It does not explain limit or pagina parameters. The description does not compensate for the lack of schema documentation for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available document models. It provides specific verbs ('lista') and resource ('modelos de documento'), distinguishing it clearly from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for using filters (link to sei_listar_grupos_modelos for groups) and troubleshooting (check version). It implies usage for listing models, but no explicit 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, confirming it's a read operation. It adds behavioral context by explaining the parameters and their effects, going 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence followed by a bullet list of parameters. No redundant information, and the key usage of the output is highlighted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameters and output usage. Since an output schema exists, it does not need to detail the return format. However, it could mention pagination behavior or default limits for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains all five parameters (filtro, favoritos, aplicabilidade, limit, pagina) in detail, adding significant meaning that the schema alone lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for document types (séries) in SEI. The verb 'Pesquisa' and resource 'tipos de documento' are specific. However, it does not differentiate from the sibling tool sei_pesquisar_tipos_processo, which serves a similar purpose for process types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions how to use the returned 'id' as parameter in sei_criar_documento, providing some usage guidance. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., sei_pesquisar_tipos_processo) and does not state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As anotações indicam readOnlyHint=false (modificação) e destructiveHint=false (não destrutivo). A descrição adiciona contexto comportamental: explica que manter_aberto='N' fecha na unidade atual, remover_anotacao remove anotações, e o uso de sigla resolve ID automaticamente. Isso vai além das anotações, embora não detalhe todos os efeitos colaterais.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A descrição é estruturada com uma linha de propósito seguida por uma lista de parâmetros. É razoavelmente concisa, mas poderia ser mais sucinta ao remover repetições (ex: 'só se o usuário pedir' aparece para enviar_email e datas). No geral, bem organizada.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considerando que existe um esquema de saída (não mostrado, mas presente) e anotações básicas, a descrição cobre os principais aspectos de entrada e comportamento. Não menciona pré-requisitos como permissões ou estado do processo, mas é completa o suficiente para o uso típico. A complexidade moderada justifica a nota 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
A cobertura da descrição do esquema é 0%, então a descrição carrega todo o peso semântico. Ela explica cada um dos 7 parâmetros: numero_processo com formato, unidades_destino com sintaxe (vírgula e resolução automática), manter_aberto, remover_anotacao, enviar_email, data_retorno (formato DD/MM/AAAA), e dias_retorno (alternativa). Exemplos e padrões são fornecidos, tornando-a muito informativa.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição inicia com 'Envia (tramita) um processo para outra(s) unidade(s) no SEI', o que fornece verbo específico e recurso claro. Isso distingue de ferramentas irmãs como sei_atribuir_processo (atribuir a usuário) e sei_consultar_processo (apenas leitura). O propósito é inequívoco.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A descrição detalha como usar os parâmetros (exemplo: separar unidades por vírgula, usar sigla ou ID), mas não fornece orientações sobre quando usar esta ferramenta em detrimento de alternativas como sei_atribuir_processo ou sei_concluir_processo. A ausência de contexto de seleção limita a pontuação.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the workaround: 'envia o processo para a própria unidade, o que faz o SEI tratar como novo recebimento (não lido).' This goes beyond annotations (readOnlyHint=false, destructiveHint=false) by explaining the side effect. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short paragraphs and a parameter detail. It is front-loaded with the main action, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (workaround) and the presence of an output schema (not shown), the description covers the main behavioral caveat and parameter format. It could mention that the operation is relative to the current unit, but it is already implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the single parameter 'numero_processo' with an example format (ex: 50300.012639/2023-26). Schema coverage is 0%, so the description compensates well, though it could include more format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Marca um processo como não lido na unidade atual.' It explains the workaround, distinguishing it from other process actions. The verb 'marcar' and resource 'processo' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for marking processes as unread, but it does not explicitly state when to use it versus alternatives (e.g., other process modification tools). No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool fetches all processes from the current unit and groups them, which is consistent and provides extra context. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose sentence, then an explanation, a clear bullet list of available fields, and illustrative examples. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is adequately explained for its purpose with good examples, but missing documentation for two parameters (filtro, apenas_meus) prevents full completeness, especially given output schema exists but is not shown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It thoroughly documents agrupar_por and agrupar_por_2 with a list of allowed values and examples, but fails to explain filtro and apenas_meus, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a grouped summary of processes from the current unit's inbox, using specific verb 'Gera um resumo agrupado'. It distinguishes from sibling tools like sei_listar_processos or sei_pesquisar_processos by focusing on aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples show different grouping scenarios, providing clear context for when to use the tool. However, it lacks explicit guidance on when not to use it or direct comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's addition of 'resolve o id interno e retorna o snippet HTML' provides some behavioral context without contradicting. However, it does not disclose error handling or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and uses minimal sentences to convey necessary information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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) and the presence of an output schema, the description fully covers the required context, including example usage and integration into workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (numero_sei) with 0% description coverage. The description adds meaning by explaining it expects a number ('ex: 2599818') and how it's used, compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a reference HTML hyperlink for a SEI document, using specific verbs and resource. It distinguishes from sibling tools by its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use ao citar documentos SEI no texto de Despachos, Notas Técnicas, etc.' and gives an example, though it does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by explaining that OCR is applied for scanned PDFs and that the tool returns text in various formats. It does not contradict annotations, so it scores well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for parameters and clear separation of concerns. It is fairly concise given the amount of information, though some redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, access control, OCR, multiple output formats) and the presence of an output schema, the description provides sufficient context for proper usage. It covers all necessary aspects without relying on the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter's meaning, default values, and enum options. It provides clear, actionable guidance for 'tipo_documento', 'formato', and the critical 'confirmar_acesso_restrito' flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a document and returns readable text. It specifies that it accepts both internal IDs and formatted protocol numbers, which distinguishes it from generic retrieval tools. However, it does not explicitly differentiate from similar sibling tools like sei_buscar_documento, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides good usage guidance through parameter explanations, especially for 'confirmar_acesso_restrito' with clear instructions on when to set it. However, it lacks explicit comparison with alternative tools or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds no behavioral details beyond listing, which is consistent. It does not negative contradict annotations, but adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence stating purpose followed by parameter details. No unnecessary words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, one required, and an output schema available, the description fully covers what the agent needs to know to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description expands on the input schema by explaining that 'referencia' can be a document SEI number or process protocol/ID, and 'tipo' has values 'documento' or 'processo'. This adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lista as ciências registradas em um documento ou processo,' specifying the action (list) and resource (ciências), distinguishing it from sibling list tools that list other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the required 'referencia' parameter and optional 'tipo' with default, providing usage context. It lacks explicit when-not-to-use guidance but is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds no behavioral traits beyond stating it returns id, sigla, nome. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the purpose and immediately provide actionable information. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, comprehensive annotations, and an output schema, the description is fully adequate. It explains the tool's function, output fields, and how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the input schema, so the baseline is 4. The description does not need to add parameter information and appropriately focuses on the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists units accessible to the authenticated user, specifying the returned fields (id, sigla, nome). It also distinguishes itself from sibling sei_trocar_unidade by explaining the purpose of the id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool (list user's units) and mentions how to use the result with a sibling tool. However, it does not explicitly state when not to use it or list alternatives beyond sei_trocar_unidade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description confirms read-only behavior by stating it 'Lista'. It adds version availability and error handling context, but does not elaborate on potential limitations like pagination or result constraints, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each serving a clear purpose: stating functionality, providing a prerequisite, and noting version/troubleshooting. No unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one required parameter and an output schema exists, the description adequately covers purpose, prerequisite, versioning, and error handling. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter id_serie has no description in the schema (0% coverage), but the description compensates by explaining that it should be obtained from sei_pesquisar_tipos_documento, adding meaningful context beyond the schema's 'Id Serie' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists subject suggestions for a document type (série), using the verb 'Lista' and specifying the resource 'sugestões de assuntos para um tipo de documento'. It also distinguishes itself from sibling sei_sugestao_assuntos_processo by targeting documentos instead of processos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisite: 'Use o id_serie obtido via sei_pesquisar_tipos_documento', guiding the agent on how to obtain the required parameter. It also mentions version availability and a troubleshooting step, but lacks explicit 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read, non-destructive mutation. Description adds behavioral context: it can add or alter, and removal via empty marker or marking with another. For a simple write tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a parameter list. No fluff, front-loaded purpose, every sentence earns its place. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description need not explain return values. Covers purpose, parameters, and removal behavior. Could mention overwriting behavior but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries full burden. It explains all three parameters: processo (formatted protocol or ID), marcador (use sei_pesquisar_marcadores), texto (optional comment). Adds meaning beyond schema, though format of processo could be more precise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it adds or changes a colored marker on a process. Explicit verb and resource, and distinguishes from siblings like sei_consultar_marcador_processo (read) and sei_criar_marcador (create new marker).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (add/change marker) and provides removal guidance (use empty or another marker). References sei_pesquisar_marcadores for finding IDs. Lacks explicit 'when not to use' but context with siblings implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description aligns with a read-only search. It adds behavioral details beyond annotations: explains pagination (pagina=0 is first page) and parameter dependencies (e.g., custom date range requires data_inicio/data_fim).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: overall purpose first, then bullet points for filters and pagination. Every sentence adds value without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and presence of output schema, the description covers the essential usage context (filters, pagination, date format, ID dependencies). It does not describe the output schema, but that's acceptable since the schema itself exists. It is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does so for most parameters: palavras_chave, busca_rapida, sta_tipo_data, id_unidade_geradora, id_assunto, grupo, pagina, data_inicio, data_fim, and date format. However, it omits 'limit' and doesn't detail 'descricao' beyond the first line.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches processes by text, description, dates, unit, or subject, and distinguishes it from sibling tools like sei_listar_processos (listing vs searching) by specifying various filter parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using keywords vs quick search, date format, pagination, and references to other tools for obtaining IDs (sei_listar_unidades, sei_pesquisar_assuntos, sei_listar_grupos_acompanhamento). It does not explicitly state when not to use the tool, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds pagination details (page numbering starting at 0) and search scope, providing useful behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a pagination note. Every sentence adds value—purpose, use case, and pagination detail—with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is mostly complete. It covers purpose, use case, and pagination, though it doesn't explicitly describe the output content (e.g., unit IDs and names).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that the search is by name or acronym (implying 'filtro' is the search term) and mentions pagination parameters 'limit' and 'pagina'. However, it could be more explicit in mapping parameters to their meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for units by name or acronym, and specifies it is useful for finding the destination unit ID when routing processes. This distinguishes it from siblings like 'sei_listar_unidades'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use (finding unit ID for process routing) and explains pagination behavior. However, it does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds value by detailing categories and conventions, and explaining that omitting parameters returns shortcuts. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and includes necessary details like categories and conventions. Every sentence adds value, but it is slightly longer than necessary; still, it is well structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no required params) and the presence of an output schema, the description covers purpose, parameter behavior, and formatting conventions comprehensively. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'categoria' with no description (0% coverage). The description fully compensates by listing the valid categories ('texto', 'titulo', 'lista', 'tabela', 'destaque', 'todos') and explaining behavior when the parameter is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists available CSS styles for formatting documents, and specifically says to use it to discover the correct class for each paragraph type. It distinguishes from sibling tools which handle processes, documents, units, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to find CSS classes) and provides a hint about behavior without parameters (returns quick shortcuts). However, it does not explicitly state when not to use it or mention alternatives, though 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context: listing signatories for the current unit, a dependency on sei_assinar_documento, version constraints, and a troubleshooting tip for unexpected errors. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, all necessary: main purpose, usage context, version info, and error recovery. It is front-loaded with the most critical information and contains no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (no parameters, with output schema and annotations), the description is comprehensive. It covers purpose, related tool, version requirements, and error handling. The output schema documents return values, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (input schema is empty), so schema coverage is 100%. The description does not need to add parameter information and correctly implies no parameters are required. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lista signatários (cargos/funções) disponíveis na unidade atual' specifying the verb (lista) and resource (signatários). It further clarifies that these are roles used in sei_assinar_documento, distinguishing it from sibling list tools like sei_listar_unidades or sei_listar_processos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool: before calling sei_assinar_documento to obtain available signatory roles. It provides version availability and error recovery steps. However, it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds behavioral details: pagination behavior, filtering options, counting mode, detail inclusion, and the fact that some processes are hidden. No contradictions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: purpose first, then an important prerequisite note, then parameter details, then output format. Every sentence adds value, but could be more concise by merging some parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, all optional, filtering, pagination, counting), the description is thorough: covers prerequisites, all parameters, output fields, and exclusions. An output schema exists, so return values are already formalized, but the description still provides useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the full burden. It explains every parameter in detail (pagina, limit, apenas_meus, filtro, tipo, apenas_contar, incluir_detalhe) with meanings, defaults, and effects. This adds significant value beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists processos from the current unit's box in a lightweight, typed format. It distinguishes itself from sibling tools like sei_pesquisar_processos (search) and sei_resumo_processos (aggregation) by mentioning its specific format and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite (sei_trocar_unidade before using to resolve atribuido_unidade_atual) and exclusions (sobrados and concluded processes not shown). Suggests sei_resumo_processos for statistical grouping. However, it does not compare to all similar sibling tools (e.g., when to use sei_listar_processos vs sei_pesquisar_processos).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description explains input resolution, the difference between protocoloFormatado and internal id, and the inclusion of _documento_resolvido for verification. It adds useful behavioral context without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short paragraphs in Portuguese, front-loaded with purpose, then input details, then output details. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, read-only, output schema exists), the description covers the essential aspects: input format, output content, and relation to editing. It could mention error cases or default behavior but is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining that id_documento accepts both protocoloFormatado and internal id, and warns about their difference. This adds critical meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists editable sections of an internal SEI document. It specifies the input (protocoloFormatado or internal id) and output (section IDs, HTML content, version). It distinguishes itself from siblings like sei_editar_secao by noting the version is needed for editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that the returned version is necessary for using sei_editar_secao, guiding when to use this tool. It does not provide explicit exclusions or comparisons to other read tools like sei_ler_documento, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint; the description adds context about returning suggestions and error handling, but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers essential behavioral and usage aspects, though it omits details about the output format which is provided by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the parameter 'id_tipo_processo' as the id from 'sei_pesquisar_tipos_processo', adding meaning beyond the schema title, compensating for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists suggestions for a process type, differentiating it from the sibling tool 'sei_sugestao_assuntos_documento' which targets document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to use the id from 'sei_pesquisar_tipos_processo' and includes version info and error handling advice, but lacks explicit 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds behavioral context: after switching, list operations show the new unit's inbox. This aligns with annotations and provides useful detail about 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the primary action, followed by key consequences and a related tool hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, prerequisite (sei_listar_unidades), and effect. With an output schema present, return values are documented separately, so no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by referencing sei_listar_unidades to obtain the id_unidade. It explains the parameter's source and purpose beyond the schema's bare definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Troca a unidade ativa do usuário no SEI.' This is a specific verb+resource pair that distinguishes it from siblings like sei_listar_unidades (lists units) or sei_editar_secao (edits sections).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use sei_listar_unidades to see available units and IDs, and notes the effect on subsequent operations like sei_listar_processos. This provides good context for when to use the tool, though it doesn't include explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that it is a simple version retrieval, no side effects, and provides availability constraints. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences, each adding unique value: what it does, why it's useful, availability info, and troubleshooting hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description fully explains the tool's purpose and usage. It covers the essential information for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description adds context about the tool's output (version info) without needing to describe parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the version of SEI and the wssei module, and mentions its utility for compatibility checking. This distinguishes it from sibling tools which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use it: for version checking and troubleshooting unexpected errors. It mentions availability since mod-wssei 2.0.0. However, it does not explicitly contrast with alternatives, but given the tool's simplicity, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: 'O processo volta para a caixa da unidade atual' (the process returns to the current unit's inbox). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences front-loading purpose and parameter hint. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, good annotations, output schema exists), the description covers all necessary information: action, condition (completed process), effect (return to unit box), and parameter format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides essential parameter guidance: format example (50300.018905/2018-67) and alternative (IdProcedimento). This fully compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reabre' (reopens) and the resource 'processo que foi concluído' (completed process), distinguishing it from siblings like sei_concluir_processo or sei_reabrir_bloco_interno.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for completed processes only ('processo que foi concluído'), but does not explicitly exclude other scenarios or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, 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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds value by specifying the exact data returned (extensions, sizes) and error handling advice ('Se falhar com erro inesperado, use sei_versao...'), which are not covered 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. Front-loaded with purpose, then usage, then error handling. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and informative annotations, the description covers the tool's purpose, usage, and error handling. The output schema (not shown) likely details return fields, so the description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% trivially. The description does not need to elaborate on parameters. With no parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retorna parâmetros de upload do SEI (extensões permitidas, tamanhos máximos)', specifying the verb 'retorna' and resource 'parâmetros de upload'. It distinguishes from sibling tools by its unique focus on upload limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Útil antes de criar documentos externos para saber os limites.', providing clear when-to-use guidance. It also mentions version availability and error recovery, offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds that the tool reads data (histórico) without mutation, and discloses the inactive scraper backend (since SSO), which is important for understanding behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3-4 sentences) with all information front-loaded. Every sentence is informative: purpose, content, parameter format, and backend modes. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema exists, the description adequately covers purpose, parameter semantics, and behavioral nuances. No missing information for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 adds critical meaning: it specifies that 'processo' accepts formatted protocol (e.g., 50300.000123/2025-00) or IdProcedimento. This fully compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the history of activities/andamentos of a process, with specific examples of actions (tramitações, assinaturas, etc.). It distinguishes from sibling list tools by focusing on activities rather than documents, units, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on parameter format (protocol or ID) and two backend modes (REST vs scraper), but does not explicitly state when to prefer this tool over alternatives like sei_listar_documentos. However, the implicit distinction is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write), idempotentHint=true, destructiveHint=false. The description adds: automatic normalization of all sections, HTML entity conversion, Cloudflare retry logic, and echo of resolved document to prevent writing to wrong document. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but slightly long; however, it is well-structured with paragraphs and bullet points in plain text. Every sentence adds value for a complex tool, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, presence of output schema (though not shown), and annotations, the description covers all necessary aspects: purpose, parameter details, behavioral notes (entity conversion, retry), and output fields like _documento_resolvido and _avisos. It is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter: id_documento (SEI number or internal ID), secoes (with subfields idSecaoModelo and conteudo), versao (auto if omitted), dry_run (test mode), validar_referencias (checks anchors). It adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Altera' (modifies) and the resource 'seções editáveis de um documento interno SEI'. It distinguishes from sibling tools like sei_listar_secoes (list sections) and sei_ler_documento (read document) by specifying it edits content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: how to obtain idSecaoModelo via sei_listar_secoes, that only changed sections need to be sent, use of dry_run for testing, HTML entity handling, Cloudflare WAF retry, and id_documento resolving. Alternatives like dry_run vs. actual write are clearly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. Description adds: read-only listing, pagination semantics, resumido flag verbosity warning, behavior change with scraper. No contradiction; adds 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points, front-loaded purpose. Slightly long but each sentence adds value. The scraper note might be edge case but useful. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input, pagination, ordering, resumido output fields, response structure (total, retornados, truncado), date absence and alternatives, scraper edge case. With output schema present, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates fully. Explains each parameter: ordem (asc/desc, desc for recent), limite/offset (item-based pagination), resumido (fields for true vs false, context warning), protocolo_formatado (accepts protocol or IdProcedimento).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists documents of a SEI process with ordering and pagination. It distinguishes from sibling tools like sei_ler_documento (reading content) and sei_consultar_documento_interno (getting date). The verb 'listar' and resource 'documentos' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: listing documents with ordering/pagination. Gives alternatives: use sei_ler_documento for content, sei_consultar_documento_interno for date. Notes that with SEI_WEB_SCRAPER=1 the parameters don't apply. Complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds context on filtering behavior and the effect of the apenas_unidade flag, which is beyond what annotations provide. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a bulleted list. Each part earns its place, and the main purpose is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list users with two params) and existence of an output schema, the description fully covers what an agent needs. It explains input, behavior, and how to use the output. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 that filtro filters by name or abbreviation and that apenas_unidade controls scope, including default behavior. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists users in SEI with optional filtering by name or abbreviation. It distinguishes itself from siblings by explicitly linking the output to process assignment via sei_atribuir_processo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two modes of the apenas_unidade parameter and their ideal use cases (true for assignment, false for all users). It also tells the agent to use id_usuario for sei_atribuir_processo, providing clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-seipro MCP server](https://glama.ai/mcp/servers/SEI-Pro/mcp-seipro/badges/card.svg)](https://glama.ai/mcp/servers/SEI-Pro/mcp-seipro)

Score Badge

Copy to your README.md:

[![mcp-seipro MCP server](https://glama.ai/mcp/servers/SEI-Pro/mcp-seipro/badges/score.svg)](https://glama.ai/mcp/servers/SEI-Pro/mcp-seipro)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SEI-Pro/mcp-seipro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server