omie-finance-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct financial entity (fornecedor, conta a pagar, conta a receber, conta corrente, boleto, PIX, banco) with specific actions. Even similar tools like pesquisar_lancamentos_financeiros vs listar_movimentos_financeiros are clearly differentiated by scope.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in Portuguese, using verbs like listar, consultar, incluir, alterar, excluir, gerar, cancelar. The naming is uniform and predictable across all entities.
Tool Count2/5
54 tools is excessive for a single MCP server, even for a comprehensive finance integration. The surface is likely to overwhelm agents, and many list/consultar pairs could be consolidated.
Completeness4/5
The finance domain is well covered with CRUD for most entities, boleto and PIX operations, and consolidated queries. Minor gaps include missing excluir_fornecedor and no direct transfer execution.
Average 3.3/5 across 54 of 54 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'creates a new account receivable' and discloses no side effects, validation requirements, dependencies, return behavior, or potential errors. This is a significant gap for a creation tool.
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, efficient sentence that is front-loaded with the action. There is no superfluous text, but it is too sparse to be considered highly helpful. It earns its place but misses opportunities to convey essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what a 'conta a receber' entails, what results to expect, or what steps are needed for successful use. The tool is under-specified for safe 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?
Schema description coverage is 0%, and the description does not explain any of the 13 parameters, including required fields like 'codigo_cliente_fornecedor' or 'data_vencimento'. The description adds no value beyond the schema, leaving parameter meaning entirely undocumented.
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 a specific verb ('Cria') and resource ('nova conta a receber') in the OMIE system. It distinguishes from sibling tools like 'alterar_conta_receber' and 'listar_contas_receber' by indicating the creation of a new record, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use this tool versus alternatives, prerequisites, or exclusions. The single sentence only states the action without any decision guidance.
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?
With no annotations, the description carries the full disclosure burden. It merely says 'Altera dados' (changes data) without explaining whether it performs partial or full updates, what happens if the supplier doesn't exist, or any side effects or permissions required.
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 clear sentence with no filler. It is well-structured and front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters, no annotations, and no output schema, yet the description provides only a one-sentence overview. It lacks essential context like how to identify the supplier, whether fields are optional individually, and what the response contains.
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 mentions none of the 12 parameters. The agent gets no semantic help beyond the raw field names (e.g., 'cep', 'email') and cannot know which identifiers are needed to target the supplier.
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 ('Altera dados' = changes data) and the target resource ('fornecedor existente' = existing supplier), which distinguishes it from sibling tools for creating (incluir_fornecedor) or listing (listar_fornecedores) suppliers. However, it lacks any explicit differentiation beyond the resource name, so it earns a 4 rather than a 5.
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 instead of alternatives. There is no mention of prerequisites (e.g., needing an existing supplier code) or distinction from similar update tools for other entities.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states that it creates a new account payable, which is an implied mutation, but it does not mention idempotency, required permissions, side effects, or what the response contains. This is minimal for a create operation.
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, which is structurally efficient. However, it is under-specified for a tool with 11 parameters, lacking any mention of required fields or additional context. It is appropriately sized for a simple CRUD purpose but does not fully earn its place due to omitted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain what the tool returns, what the required parameters represent, or any potential error conditions. For a complex create operation, this level of detail is insufficient 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.
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 additional meaning for any of the 11 parameters. While some parameter names are self-explanatory (e.g., 'valor_documento', 'data_vencimento'), others like 'codigo_lancamento_integracao' and 'id_conta_corrente' remain ambiguous. The description does nothing to compensate for the lack of parameter 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 the tool's function: 'Cria uma nova conta a pagar no OMIE' (Creates a new accounts payable in OMIE). The verb 'cria' and resource 'conta a pagar' are specific and distinguish this tool from siblings like 'alterar_conta_pagar' and 'excluir_conta_pagar'.
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. There is no mention of exclusions, prerequisites, or relationships with sibling tools like 'alterar_conta_pagar' or 'listar_contas_pagar'. The description only states the action 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It indicates a payment write-off but does not explain side effects, such as whether the payment is reversible, how it affects the account balance, or if any validation occurs. This is insufficient for a financial mutation.
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 with no fluff, but it is under-specified for a tool with 10 parameters. It is not a tautology, but lacks the depth expected for such a complex operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, no annotations, and no output schema. The description only restates its basic purpose, omitting all contextual details needed for correct invocation, such as required parameter semantics and expected effects.
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 adds no parameter information. Parameters like 'juros', 'multa', 'desconto', and 'conciliar_documento' are left completely unexplained.
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: 'Registra o pagamento (baixa) de uma conta a pagar' (registers the payment/write-off of an accounts payable). This distinguishes it from sibling tools like 'incluir_conta_pagar' (create accounts payable) and 'lancar_recebimento' (record receivable).
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. The description does not mention prerequisites, exclusions, or scenarios where another tool (e.g., 'cancelar_pagamento_conta_pagar') would be preferable.
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?
No annotations are provided, so the description must carry behavioral transparency. It only states the action without disclosing any behavioral traits such as pagination behavior, ordering, date limits, or whether the list is filtered. It also does not mention if this is a read-only operation or if any side effects exist.
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, which is efficient and easy to parse. However, it is under-specified and does not provide enough content to be fully useful. It is not overly verbose, but the brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is far too minimal. It fails to explain the filtering, pagination, ordering, or output format. Given the tool's complexity and the rich sibling context, the description is incomplete and does not allow an agent to use it 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?
Schema description coverage is 0%, but the description offers no information about the 8 parameters (e.g., filtering by date, account, pagination). It does not compensate for the schema gap in any way. The parameter names in the schema give some hints, but the description adds no semantic 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 uses a specific verb 'Lista' and resource 'lançamentos/transações bancárias em conta corrente', clearly indicating the tool lists bank transactions in a checking account. It distinguishes from siblings like consultar_lancamento_bancario (single transaction) and listar_pix (PIX-specific).
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives such as pesquisar_lancamentos_financeiros, listar_movimentos_financeiros, or consultar_extrato_bancario. There is no context about scenarios where this specific listing is preferable.
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?
With no annotations provided, the description bears the full burden of behavioral disclosure. The word 'consulta' implies a read-only operation, but nothing is said about needing at least one identifier, potential errors, or the nature of the returned details. This leaves the agent guessing about invocation requirements.
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 with no unnecessary words, making it terse and front-loaded. However, it is under-specified rather than appropriately concise: omitting essential usage and parameter details prevents it from being fully effective.
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 no annotations, no output schema, and 0% parameter coverage, the description should provide extra context about identified parameters, invocation semantics, and expected results. It provides none of this, making it incomplete for reliable tool selection and 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?
Schema description coverage is 0%, and the description does not compensate. It does not explain 'codigo_lancamento_omie' or 'codigo_lancamento_integracao', their roles, or that at least one might be required. The agent is left without the necessary meaning to populate parameters 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 uses the specific verb 'consulta' (query) and names the resource 'conta a receber' (accounts receivable), explicitly noting 'específica' to indicate it targets a single record. This clearly distinguishes it from sibling tools like 'listar_contas_receber' which lists many.
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 does not mention that it is intended for fetching a specific account receivable, nor does it note that an identifier is needed or how to choose between the two code parameters.
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?
With no annotations, the description carries the burden of disclosing behavioral traits. It only uses the word 'Cancela' (cancels) but does not mention side effects, reversibility, required permissions, or whether the entire title is affected or just the payment slip. This is a significant gap for a destructive operation.
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 short sentence with no redundant words, making it efficient. However, its brevity omits critical details, but for what it includes, it is well-structured and front-loaded with the action.
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 no output schema, no annotations, and two undocumented optional parameters, the description is incomplete. It fails to explain the cancellation process, return behavior, or how to choose the correct identifier, which is a key usability 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%, and the description adds no information about the two parameters. It does not explain the difference between codigo_titulo and codigo_titulo_integracao, nor which should be used, whether both are accepted, or how they relate to the boleto/título.
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 ('Cancela') and the resource ('boleto de um título de contas a receber'), making its purpose unambiguous and distinct from sibling tools like gerar_boleto, prorrogar_boleto, and cancelar_pix.
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, what prerequisites exist (e.g., boleto must be unpaid), or any exclusions. The description merely states the basic action without contextualizing appropriate usage.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'cancela' (cancels) and gives no information about side effects (e.g., whether it deletes the record, requires a specific status, or is reversible), nor what happens to the 'excluir' flag.
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 single, grammatically correct sentence with no fluff. It is efficient and easy to parse, but the extreme brevity veers into under-specification rather than genuine conciseness; still, it earns a 4 for being concise without being 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?
For a tool with 3 optional parameters and no output schema, the description is minimal. It states the core action but omits essential context about parameters, preconditions, and return behavior, making it incomplete for reliable 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?
Schema description coverage is 0% and the description does not explain any of the three parameters (id_pix, excluir, codigo_integracao). The agent is left without any semantic clue beyond the bare schema field names, so this dimension is severely under-served.
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 'Cancela uma cobrança PIX' clearly states the specific action (cancel) and resource (PIX charge). It distinguishes this tool from siblings like gerar_pix, obter_pix, and cancelar_boleto by explicitly naming the PIX charge context.
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 other cancel operations (e.g., cancelar_boleto, cancelar_recebimento) or any prerequisites. It simply states the action without 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?
No annotations are provided, and the description only says 'consulta,' implying a read operation. It does not disclose required parameters, error behavior, or return format, which are critical for a tool with no structured 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 single, front-loaded sentence that is efficient and free of redundancy. It does not waste words, though it could be more informative without adding bulk.
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 two parameters, no parameter descriptions, no output schema, and no annotations, the one-sentence description is inadequate for reliable tool selection and invocation. It lacks context about return values and parameter semantics.
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 does not mention codigo_lancamento or codigo_lancamento_integracao at all. The agent gets no explanation of what these identifiers mean, whether they are mutually exclusive, or which one is needed.
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 consults details of a specific bank transaction ('Consulta detalhes de um lançamento bancário específico'), using a specific verb and resource. It distinguishes from sibling 'listar_lancamentos_bancarios' by emphasizing 'específico' (specific).
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 like listar_lancamentos_bancarios or pesquisar_lancamentos_financeiros. It does not mention which parameter to prefer or whether the two codes are alternatives.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool creates a manual entry but does not explain side effects, permission requirements, reversibility, how debit/credit is determined (e.g., sign of valor), or the role of codigo_conta_destino for transfers. This is a significant transparency gap for a mutation tool.
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 sentence that is front-loaded and contains no fluff. It competently states the core purpose. However, given the tool's complexity (10 parameters, no annotations), it could be slightly larger without becoming bloated, but it still earns its place.
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 tool with 10 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain parameter semantics, behavioral effects, or when to use it. The lack of any guidance makes it insufficient for an AI agent to invoke correctly for all but the simplest implicit use.
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 compensate. It does not explain any of the 10 parameters, including required fields like codigo_conta_corrente, data_lancamento, valor, or codigo_categoria. The mention of 'débito ou crédito' is the only hint, but it is not mapped to any parameter.
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 manual bank transaction (lançamento) in a checking account, specifying debit or credit. This distinguishes it from siblings like listar_lancamentos_bancarios, consultar_lancamento_bancario, and excluir_lancamento_bancario, and also from creation tools for contas a pagar/receber.
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. It does not mention that for accounts payable/receivable you should use incluir_conta_pagar/receber, or when to use this instead of lancar_pagamento/recebimento. There is no context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., irreversible extension), required permissions, or what happens if the boleto is already paid or canceled. The one-line description only restates the action without any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise and easy to parse, making the core purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mutation nature, three parameters, no annotations, and no output schema, the description is severely incomplete. It lacks essential context such as how to select between the two optional title identifiers, the format of the new date, and what the response indicates about success or failure.
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 by explaining parameters, but it does not mention codigo_titulo, nova_data_vencimento, or codigo_titulo_integracao at all. The agent gets no guidance on how to identify the target title or what date format to use for 'nova_data_vencimento'.
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 'Prorroga' (extends) and the resource 'data de vencimento do boleto de um título' (due date of a title's boleto), making it distinct from sibling tools like cancelar_boleto and gerar_boleto. The action is unambiguous 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for extending a boleto's due date but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions. It is enough to infer the primary use case but not to differentiate from related operations.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies a read operation ('Consulta') but does not explain error behavior, response format, or any access requirements. The non-destructive nature is implicit, not explicit, and no additional behavioral context is given.
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, tightly worded sentence that immediately conveys the action and object. There is no redundancy or extra information, making it highly concise and easy to parse.
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 two unspecified parameters and no output schema, the description is under-specified. It lacks details on how to identify the account, what data will be returned, or any contextual caveats. The short length is concise but fails to provide the necessary operational context for an AI 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.
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 two input parameters ('codigo_integracao' and 'codigo_conta_corrente'). It offers no insight into which parameter to use, whether they are alternatives or complementary, or their format, leaving the agent unable to construct a correct call from the description 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 action ('Consulta' = consult) and resource ('conta corrente específica' = specific current account), making it easy to understand what it does. The word 'específica' distinguishes it from list-all tools like 'listar_contas_correntes', and the sibling list includes many 'consultar_*' tools, but this one uniquely targets a single current account.
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 'listar_contas_correntes' or other consult tools. It does not mention prerequisites, typical use cases, or situations where another tool would be preferred.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool creates a new account, without mentioning side effects, permissions, validation rules, response format, or error behavior. This is a significant gap for a creation operation.
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, concise sentence with no wasted words. It front-loads the action ('Cadastra') and the object ('nova conta corrente/bancária'). However, it is extremely brief, which borders on under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, 2 required, no annotations, no output schema), the one-sentence description is wholly inadequate. It fails to explain required fields, parameter semantics, expected response, or any operational context needed 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?
Schema description coverage is 0%, so the description must compensate by explaining parameters. However, the description does not mention any of the 12 parameters, their meanings, or how they relate to the creation process. The parameter names are not self-explanatory beyond basic Portuguese, and no additional semantics 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 uses the specific verb 'Cadastra' (registers/creates) and clearly identifies the resource as 'nova conta corrente/bancária' (new current/bank account). This distinguishes it from sibling tools like alterar_conta_corrente (update), excluir_conta_corrente (delete), and listar_contas_correntes (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?
The description implies the tool is for creating a new bank account, but it does not explicitly state when to use it over alternatives or provide exclusions. Since the verb and resource clearly indicate the creation use case, usage is implied rather than explicitly 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates a read-only listing operation, but does not mention pagination behavior, return format, or any special side effects. This is a minimal but not misleading description.
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, front-loaded sentence with no filler. It uses a clear verb and immediately states the resource and scope, making it highly concise and well-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 the tool's simplicity, it has 4 optional parameters and no output schema. The description is only one line and fails to explain parameter meanings, pagination behavior, or the structure of the returned list. This is insufficient for an agent to invoke the tool correctly with meaningful filters.
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 schema has 0% description coverage, and the description does not explain any of the 4 parameters. While names like 'nome' and 'pagina' are somewhat self-evident, 'tipo' is ambiguous and the description adds no semantic context to help the agent form correct arguments.
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 banks/financial institutions registered in OMIE, using a specific verb and resource. However, it doesn't explicitly distinguish itself from sibling tools like consultar_banco, so it's slightly below a perfect score.
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?
There is no guidance on when to use this tool versus alternatives such as consultar_banco or other list tools. The description does not provide any context for filtering or pagination, leaving the agent without criteria for choosing this tool.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'lists accounts payable with filters.' It does not mention pagination behavior, default ordering, how filters interact, any access requirements, or the return format, and it references a filter parameter that isn't in the 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 a single concise sentence that is front-loaded and easy to parse. It earns its place by stating the core action and available filter categories, though it sacrifices detail for brevity.
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 tool with 9 optional parameters, no annotations, and no output schema, this description is too thin. It omits essential context about pagination, sorting, filter value formats, and what the returned data looks like, making it insufficient for an agent to fully understand the tool's behavior.
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 schema has 9 parameters with 0% description coverage, and the tool description provides no parameter details. Worse, it mentions a 'fornecedor' filter that does not correspond to any schema property (the closest is 'filtrar_cliente'), so it actively misleads rather than clarifying parameter semantics.
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 accounts payable (contas a pagar) with filters, distinguishing it from sibling tools like listar_contas_receber. However, it mentions a 'fornecedor' (supplier) filter that does not exist in the input schema, which introduces a minor inaccuracy.
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 this tool is for listing accounts payable when filtering by status, date, or supplier is needed, but it gives no explicit guidance on when to choose this over alternatives like consultar_conta_pagar or listar_contas_receber. There are no exclusions or alternative tool mentions.
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?
Since no annotations are provided, the description carries the full burden for behavioral disclosure. It only states that the tool 'lists' origins, with no information about return format, pagination, or anything beyond the basic action.
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, front-loaded sentence with no redundant wording. It is highly concise and easy to parse.
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 being a simple tool, the description lacks essential context. With no output schema and no annotation, the return structure is unknown, and the optional parameter is unexplained, making the description incomplete for reliable 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 schema has 0% description coverage for its single optional 'codigo' parameter, and the description does not mention this parameter at all. The agent is left without any explanation of what the code refers to or how it filters results.
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 'Lista' (lists) and the specific resource 'origens de lançamento financeiro cadastradas no OMIE'. This distinguishes it from sibling list tools that target different resources like finalidades or bandeiras.
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 does not mention any specific scenarios, prerequisites, or exclusions, leaving the agent to 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies read-only behavior via 'Consulta' but does not disclose potential errors, permissions, or what happens with invalid identifiers. There is no context beyond the basic query action.
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 immediately states the tool's purpose. There is no wasted wording or unnecessary detail.
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 three optional parameters, no output schema, and no annotations, the description is insufficient. It does not explain which parameter to use, how the parameters relate to each other, or what the response contains. More context is needed for an agent to reliably invoke the tool.
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 schema has 0% description coverage for its three parameters, and the description does not mention them at all. The agent cannot infer the meaning of id_pix, codigo_titulo, or codigo_integracao, so the description provides no semantic value for 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 retrieves details of a specific PIX charge ('Consulta os detalhes de uma cobrança PIX'). This distinguishes it from siblings like listar_pix (listing all) and cancelar_pix (canceling).
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 that this tool is for fetching a single PIX by ID, nor does it reference sibling tools for listing or canceling.
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 simply says 'deletes' without disclosing whether the operation is reversible, whether it requires any authorization, or what side effects it may have on related financial records. Since no annotations are present, the description carries the full burden, and it fails to provide this critical behavioral information.
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?
One short sentence containing only the essential action. It is not bloated, but it might be overly terse, sacrificing the clarity that longer explanations could offer.
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?
A deletion operation with no output schema and no annotation support requires the description to clarify the preconditions, the identifier requirement, and the irreversibility of the deletion. The current description does none of this, making it inadequate for an AI agent to safely invoke the tool.
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 defines two optional identifier parameters (codigo_lancamento and codigo_lancamento_integracao), but the description never mentions how to identify the transaction to delete or that at least one parameter must be supplied. With 0% schema description coverage, the description is expected to compensate, but 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 uses the verb 'Exclui' (deletes) and specifies the resource 'lançamento bancário em conta corrente' (bank transaction in checking account), clearly differentiating it from sibling tools like incluir_lancamento_bancario, listar_lancamentos_bancarios, and consultar_lancamento_bancario. The intent is unambiguous.
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 only states the action, not when to use it or alternatives. It does not mention that the tool is the appropriate choice for deleting a specific bank transaction as opposed to cancelling a Pix or payment. The context of the sibling tools implies its use, but no explicit guidance is 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?
No annotations are provided, so the description carries the full burden. It merely states the action without disclosing side effects, irreversibility, permissions, or impact on related records. For a mutation tool, this is insufficient disclosure.
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, front-loaded sentence with no filler or repetition. It efficiently communicates the core purpose in the fewest possible words, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, no annotations, and zero schema descriptions, the description is grossly inadequate. It provides only the basic action and lacks any context about prerequisites, required fields, or expected behavior, making it highly incomplete for effective tool selection and 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?
Schema description coverage is 0%, and the description does not mention any of the 10 parameters. It fails to compensate for the lack of schema documentation, leaving parameter meaning entirely to field names without any additional guidance.
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 'Registra' (registers) and the resource 'recebimento de uma conta a receber' (receipt of an accounts receivable). It distinguishes from sibling tools like 'lancar_pagamento' and 'cancelar_recebimento' by specifying the exact financial 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?
The description implies usage for recording a receivable payment but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like 'cancelar_recebimento' or contrast with other tools, so the usage context remains implicit.
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?
With no annotations provided, the description carries the full transparency burden. It only says 'Consulta' (query), implying a read operation, but does not disclose side effects, required identifier behavior, return format, or limitations. Significant behavioral context is missing.
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, front-loaded sentence with no redundant words. It is appropriately concise for a simple query tool, though it could include a bit more useful context 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 no annotations, no output schema, and three undocumented optional parameters, the description is incomplete. It defines the tool's purpose well but fails to provide enough contextual guidance on parameter usage, return expectations, or how it relates to sibling tools.
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 meaning for the three optional parameters (id_pix, codigo_titulo, codigo_integracao). The agent is left without guidance on how these parameters identify a specific PIX charge or whether at least one is required.
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 ('Consulta' = query) and resource ('status de uma cobrança PIX específica' = status of a specific PIX charge), and the word 'apenas' (only) differentiates it from sibling tools that retrieve full PIX details or list statuses.
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 this tool is for checking the status of a single PIX charge, but it does not explicitly mention alternatives or when not to use it. The 'apenas' provides some constraint but no direct comparison to obter_pix or listar_status_pix.
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?
Sem anotações, a descrição precisa demonstrar segurança e comportamento. 'Consulta' sugere operação somente leitura, mas não declara se há efeitos colaterais, nem o que ocorre se o código não existir. Falta contexto sobre o retorno.
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 é uma frase curta e direta, sem palavras redundantes. Está no formato adequado, com a informação principal no início.
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?
Para uma ferramenta simples com um parâmetro e sem schema de saída, a descrição é aceitável, mas deixa a desejar ao não informar que tipo de detalhes são retornados ou o comportamento quando o banco não é encontrado. Ainda assim, a complexidade é baixa, e a descrição cobre o básico.
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?
O único parâmetro 'codigo_banco' é autoexplicativo e a descrição menciona 'pelo código', mas não acrescenta formato ou restrições (ex.: código numérico). Com cobertura do schema em 0%, a descrição deveria detalhar mais o parâmetro, mas apenas reafirma o nome.
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?
O verbo 'consulta' e o recurso 'banco/instituição financeira' deixam claro que a ferramenta recupera detalhes de um banco. O modificador 'pelo código' distingue de 'listar_bancos', que lista todos. No entanto, não há contraste explícito com ferramentas irmãs, mas a especificidade está implícita.
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 implica o caso de uso: você precisa de um código de banco para obter detalhes. Não há alternativas ou condições explícitas, mas fica claro que é para consulta pontual. O contexto é compreensível, porém sem diretrizes de uso vs. outras ferramentas.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation via 'Consulta' but does not disclose parameter requirements, error behavior, response structure, or any side effects. This is a minimal disclosure for a query tool.
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, front-loaded sentence. It communicates the core purpose with no extraneous information, making it easy to parse quickly.
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 no output schema and sparse annotations, the description is incomplete for a usable tool. It does not clarify how the two optional parameters interact, what 'detalhes' includes, or how the agent should structure the call when both/neither parameter is provided.
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 (codigo_lancamento_omie, codigo_lancamento_integracao). It fails to compensate for the low coverage, leaving the agent to guess which identifier to provide and whether either is required.
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: 'Consulta detalhes de uma conta a pagar específica' (queries details of a specific accounts payable). The word 'específica' distinguishes this from sibling list tools like listar_contas_pagar, indicating a single-record lookup.
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 gives no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of when not to use it. It simply states the purpose without contextual or comparative information, leaving the agent to infer usage from names and schema.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('Consulta...pelo código') but does not disclose any behavioral traits such as return format, error conditions, or whether it returns a single result or a list.
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 directly states the purpose without any unnecessary words or repetition. It is perfectly sized for the tool's simplicity.
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), the description provides a basic understanding. However, it does not describe the return value or error behavior, which is especially important because no output schema exists to fill that gap.
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 mentions the parameter 'código' and its role as the lookup key, which adds slight meaning beyond the bare schema property name. However, since schema coverage is 0% and the description does not explain the code's format or any constraints, the added value is minimal.
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 ('Consulta') and the resource ('tipo de documento fiscal/financeiro') with a specific lookup key ('pelo código'). This distinguishes it from the sibling 'listar_tipos_documento' by implying a single-search operation, though it does not explicitly contrast the two.
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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention that 'listar_tipos_documento' should be used when you need all document types, nor does it state any prerequisites or conditions.
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?
With no annotations provided, the description must fully disclose the behavioral implications. It states that this is a delete operation, but it fails to mention whether deletion is permanent, any required permissions, or potential side effects. The constraint about open items is helpful but insufficient for a destructive action.
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, efficient sentence that delivers the core message without any fluff. It earns its place by stating both the action and the eligibility condition, making it easy to scan.
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?
This is a destructive delete tool with two optional parameters and no output schema. The description omits crucial context: return values, error behavior, which parameter to use, and what happens after deletion. It is far from complete for the complexity involved.
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 provides no explanation of the two parameters ('codigo_lancamento_omie' and 'codigo_lancamento_integracao'). Since neither parameter is required, the description should at least hint that one of them is needed to identify the record, but it says nothing about them.
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' = deletes) and the resource ('conta a receber' = accounts receivable) with the specific OMIE platform context. It adds a key constraint ('apenas títulos em aberto' = only open items), which distinguishes it from sibling delete tools like excluir_conta_pagar.
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 an implicit usage condition: only open accounts receivable can be deleted. However, it does not explicitly explain when to choose this over other delete tools (e.g., excluir_conta_pagar) or mention prerequisites like which identifier must be 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?
No annotations are present, so the description carries the full burden. It states the action but does not disclose whether generating a boleto has side effects (e.g., issuing a payment slip, modifying status), what the output format is, or whether it is idempotent. This leaves uncertainty about side effects and 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, focused sentence with no filler. It is front-loaded with the action ('Gera') and the object ('boleto'), making it very 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?
With two optional parameters, no output schema, and no annotations, the short description is insufficient. It lacks details about expected return values, parameter selection, and the tool's place in the boleto lifecycle relative to siblings like 'obter_boleto' and 'cancelar_boleto'.
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 for 'codigo_titulo' or 'codigo_titulo_integracao'. It is unclear which identifier to use or if they are alternatives, leaving the agent without guidance on how to specify the target 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 states a specific action: 'Gera o boleto' (generates the boleto) for 'um título de contas a receber já existente' (an existing accounts receivable title). This clearly differentiates it from sibling tools like 'obter_boleto' (which retrieves a boleto) and 'gerar_pix' (which generates a different payment method).
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 phrase 'já existente' gives an implicit constraint that the title must already exist, but it does not explicitly state when to use this tool over alternatives such as 'obter_boleto' or 'cancelar_boleto'. No exclusions or conditions 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?
With no annotations, the description must carry the disclosure burden. It does not state that the operation is read-only, nor does it mention pagination, defaults, or any side effects. The single sentence adds no behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core action and object. No wasted words, though it is sparse.
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 12 parameters, no annotations, and no output schema, this description is severely incomplete. It omits how to handle pagination, date formats, sorting, and filter combinations, making it hard 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain the 12 parameters. It only covers status, period, and client in general terms, leaving pagination, sorting, ordering, bank account, emission dates, and the open-titles flag undocumented. This partial coverage is insufficient for an agent to set parameters 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 uses 'Lista contas a receber' — a clear verb+resource statement that identifies exactly what the tool does. It adds filter dimensions (status, period, client), distinguishing it from siblings like listar_contas_pagar or listar_titulos_em_aberto.
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 choose this tool over related queries such as listar_titulos_em_aberto, pesquisar_lancamentos_financeiros, or consultar_conta_receber. There is no mention of preconditions, exclusions, or recommended contexts.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action of obtaining a link, but does not mention side effects (e.g., read-only nature), authentication requirements, or behavior when the title is not found. This minimal disclosure leaves important behavioral aspects opaque.
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 is front-loaded with the primary verb and object. It contains no filler or redundant content, making it efficient and easy to parse.
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 lack of annotations and output schema, the description must provide comprehensive guidance. It states the return is a download link, which is helpful, but it fails to explain the input parameters or the distinction between the two optional identifiers. For an agent to correctly invoke the tool, it needs to know how to specify the título, which is absent.
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 schema description coverage is 0%, and the description does not mention the parameters at all. Both 'codigo_titulo' and 'codigo_titulo_integracao' are optional and nullable, but the description fails to explain how they identify the título, their relationship, or which to use. The description adds no value in clarifying parameter 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 tool's function with a specific verb ('Obtém') and resource ('link de download do boleto de um título já gerado'). It distinguishes itself from sibling tools like 'gerar_boleto' and 'cancelar_boleto' by focusing on retrieval of an existing boleto's download link.
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 phrase 'já gerado' implies the prerequisite that the title must already exist and that this tool is not for generating new boletos. However, it does not explicitly state when to use it versus alternatives, nor does it mention exclusions (e.g., do not use before generation).
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?
No annotations are provided, so the description carries the full burden. It indicates a write operation ('Gera') but does not disclose side effects, reversibility, permissions, or any consequences of creating a charge. The optional association with a title is mentioned, but behavioral traits like idempotency or external notifications are absent.
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 with no redundant words. It is appropriately front-loaded with the core action and resource, and it does not repeat any structured data. This is an example of high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the one-sentence description is severely under-specified. It provides no information about return values, error conditions, or usage prerequisites. The tool's complexity demands a more detailed description to be adequately usable.
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 compensate. The phrase 'associada ou não a um título de contas a receber' hints that codigo_titulo is an optional receivable title ID, but the other 6 parameters (valor, cnpj_cpf, url_notificacao, etc.) are left unexplained. The description adds minimal value beyond the schema field 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 action ('Gera' = generates) and the resource ('cobrança PIX' = PIX charge), with a qualifier about associating with an accounts receivable title. This distinguishes it from siblings like cancelar_pix (cancel) or gerar_qrcode_pix_estatico (static QR code), both 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to create PIX charges, optionally linked to an account receivable title ('associada ou não a um título de contas a receber'). However, it provides no explicit when-to-use guidance or exclusions, nor does it mention alternative tools for static QR codes or other related actions.
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?
No annotations are provided, so the description carries full burden. It states the action (register) but does not disclose any potential side effects, required permissions, or behavior on duplicate CNPJ/CPF. The description adds no transparency beyond the literal meaning.
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, front-loaded sentence with no filler words. Every word contributes to the core purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), the description is severely underspecified. It does not explain what happens on success (e.g., returned ID), validation rules, or any constraints, leaving the agent without critical context.
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 mentions none of the 14 parameters. While some parameter names like 'razao_social' and 'cnpj_cpf' are self-explanatory, the description does not clarify required fields, formats, or the meaning of ambiguous ones like 'codigo_cliente_integracao'. It adds no 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 'Cadastra um novo fornecedor no OMIE' clearly states the verb (cadastra/registers), the resource (fornecedor/supplier), and the scope (OMIE). It distinguishes this tool from siblings like consultar_fornecedor and alterar_fornecedor by specifying 'novo' (new).
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 creating a new supplier via the word 'novo', but it provides no explicit guidance on when to use this versus alterar_fornecedor or any prerequisites. There are no exclusions or alternative suggestions, so the agent must infer the appropriate 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the QR code is static and without a fixed value, but it does not disclose whether the operation has side effects (e.g., creating a record), requires specific permissions, or how the output is delivered. This is insufficient for an agent to anticipate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action and includes only relevant clarifications. No unnecessary words or repetition.
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 there is no output schema or annotations, the description should explain what the tool returns or how the QR code is provided. It does not mention the output format, whether the QR code is returned as an image, a string, or a file, nor does it address any side effects. The description is too minimal for the agent to fully understand the tool's behavior and invocation consequences.
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 description coverage is 0%, and the description barely adds meaning to the single parameter 'codigo_conta_corrente'. The phrase 'para uma conta corrente' hints at the parameter's role, but it does not explicitly explain that the parameter is the account code or provide any additional details such as format, requiredness, or acceptable values. The description fails to compensate for the 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?
The description clearly states the tool's function with a specific verb and resource: 'Gera um QR Code PIX estático' (Generates a static PIX QR Code). It also clarifies the scope 'para uma conta corrente' (for a checking account) and differentiates it from dynamic PIX by adding '(sem valor fixo)' (without fixed value), which distinguishes it from the sibling tool 'gerar_pix'.
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 static PIX QR codes without a fixed amount, but it does not explicitly state when to use this tool versus alternatives like 'gerar_pix'. There is no mention of when not to use it or any prerequisites, so the guidance is only implied rather than explicit.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states what the tool does but does not mention pagination behavior, returned fields, sorting, or that it is a read-only operation. The parameters suggest pagination, but the description does not clarify any behavioral aspects.
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 with no redundant wording. It front-loads the core purpose and is appropriately sized for a simple listing 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?
The tool lacks an output schema and has no annotations. The description does not explain the return format, pagination behavior, or any filters. Given the pagination parameters, the description should at least mention that the result is paginated or describe the response structure. The current description is too sparse for a complete understanding.
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 covers 0% of parameter descriptions, and the description does not compensate by explaining the parameters 'pagina' and 'registros_por_pagina'. The parameter names are somewhat self-explanatory, but the description provides no additional meaning or usage hints for these fields.
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 ('Lista') and the resource ('contas correntes/bancárias cadastradas no OMIE'), which distinguishes it from related tools like listar_bancos (banks) and listar_tipos_conta_corrente (account types). The scope is 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need to list all registered checking accounts, use this tool. However, it does not explicitly mention when not to use it or point to alternatives such as consultar_conta_corrente for a single account. The guidance is minimal and 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?
No annotations are provided, so the description carries the full burden. It discloses the optional bank filter, but does not mention pagination behavior, response format, or explicitly state that it is a read-only operation.
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 with no wasted words, effectively front-loading the core 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?
For a simple list tool with no output schema, the description provides the essential purpose and filter option, but lacks details on pagination, return format, and relationship to the sibling consult 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 description coverage is 0%, and the description only explains one of three parameters (filtrar_por_banco). The pagination parameters (pagina, registros_por_pagina) are left to their self-explanatory names and defaults, which does not fully compensate for the lack of schema descriptions.
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 accepted transfer purposes (CNAB) and can optionally filter by bank. It uses a specific verb and resource with scope, but does not explicitly distinguish from the sibling consultar_finalidade_transferencia.
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 retrieving a list of transfer purposes, optionally filtered by bank, but provides no explicit guidance on when to prefer this over other listing tools or the sibling consultar_finalidade_transferencia.
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?
Sem anotações, a descrição carrega todo o peso da transparência comportamental. Ela menciona apenas o escopo unificado, mas não detalha como a busca funciona (paginação, filtros, formato de retorno, se há ordenação, limites, etc.). Para uma ferramenta de busca com 10 parâmetros, isso é uma lacuna significativa.
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 consiste em duas frases curtas e objetivas. A primeira estabelece o propósito, a segunda adiciona contexto de uso. Não há redundância ou informações desnecessárias, e a informação principal está no início.
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?
A ferramenta possui 10 parâmetros, não tem output schema, nem anotações. A descrição de duas frases é insuficiente para cobrir todos os aspectos necessários: comportamento de busca, filtros, paginação, formato de resposta e interação com os parâmetros. A completude contextual é baixa para a complexidade do tool.
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?
O schema tem cobertura de 0%, ou seja, nenhum parâmetro tem descrição no schema. A descrição da ferramenta também não explica nenhum parâmetro, nem mesmo os mais relevantes como status, natureza ou períodos. Nomes autoexplicativos não compensam a falta de semântica adicional, especialmente com 10 parâmetros.
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 usa verbo específico 'Pesquisa' e recurso 'lançamentos financeiros', delimitando escopo com 'unificada (contas a pagar + a receber)', o que a distingue claramente dos irmãos listar_contas_pagar e listar_contas_receber. O propósito é claro e não há ambiguidade.
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?
O texto indica o contexto de uso ('Ideal para visão consolidada das finanças'), o que sugere quando escolher esta ferramenta em vez das listagens separadas. Porém, não menciona explicitamente alternativas nem situações de não uso, apenas dá um contexto implícito de consolidação.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. 'Lista' implies a read-only operation, and the scope of accepted brands is clear, but pagination behavior and return format are not mentioned. The description adds some value but leaves room for ambiguity.
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 is front-loaded with the action and resource. It contains no fluff or redundant information, making it highly 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?
For a simple list tool with only two optional parameters, the description conveys the essential purpose. However, it omits mention of pagination behavior and does not describe the return structure, which is notable given the absence of an output schema and annotations. The gaps are moderate but not severe.
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 mention the pagination parameters at all. While the parameter names ('página' and 'registros por página') are self-explanatory, the description adds no semantic meaning beyond the schema, failing to compensate for the lack of parameter 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 the tool's function with a specific verb ('Lista') and resource ('bandeiras de cartão de crédito/débito aceitas pelo OMIE'). It uniquely identifies the purpose and differentiates from sibling tools, none of which cover card brands.
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 obtaining accepted card brands from OMIE, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. Since the purpose is straightforward and no similar sibling exists, the context is clear but lacks explicit guidance.
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?
With no annotations, the description carries the full burden for behavioral disclosure. It is a list operation, so no side effects are expected, but the description does not disclose important behavior such as the default filtering by active accounts (the parameter 'apenas_contas_ativas' defaults to 'S') or whether the list can include inactive accounts. This is a gap.
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, focused sentence that clearly conveys the tool's purpose. It is front-loaded with the action and resource, with no extraneous words. Every word contributes to meaning.
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 optional parameter, no output schema), the description provides a minimum viable context by naming the resource and its use case. However, it omits any details about the parameter's effect or default behavior, which leaves the agent with some uncertainty. It is adequate but not thorough.
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 there is one parameter ('apenas_contas_ativas'). The description does not mention or explain this parameter at all. The parameter name is somewhat self-explanatory, but the description does not compensate for the lack of schema documentation, leaving the agent to infer meaning from the parameter 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 uses the specific verb 'Lista' (lists) and clearly identifies the resource as 'as contas do DRE (Demonstração de Resultado)'. It also explains their purpose ('usadas para categorizar lançamentos'), which distinguishes this tool from other sibling list tools like listar_finalidades_transferencia or listar_bandeiras_cartao.
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 the tool should be used when you need DRE accounts to categorize financial entries, providing clear context. However, it does not explicitly mention alternatives or when not to use it, which prevents a score of 5.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it lists PIX charges and supports filters, but does not mention pagination behavior, default ordering, response format, or any side effects (e.g., read-only nature). For a list operation, the lack of detail about result limits, date format expectations, or status values leaves the agent with significant unknowns.
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, well-structured sentence that front-loads the primary action and resource, then lists the filters. It is concise, containing no unnecessary words, and every word earns its place. Length is appropriate for the tool's simplicity.
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 tool with no output schema, no annotations, and 5 optional parameters, the description is insufficiently complete. It explains 'what' but not 'how': no information about pagination defaults, maximum results, date format for filters, or the response structure. The high-calibration example shows a similar tool with richer guidance; here the agent must guess at critical usage details.
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 description coverage is 0%, so the description must compensate. It does add meaning by correlating 'período de emissão' with emissao_de/emissao_ate and 'status' with the status parameter. However, it does not explain the pagination parameters (pagina, registros_por_pagina) or any parameter formats, leaving them to be inferred from names and defaults. Partial compensation is provided, but not complete.
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 'Lista cobranças PIX geradas' uses a specific verb (Lista) and resource (cobranças PIX geradas) that clearly identifies the tool's function. It also mentions the available filters (período de emissão e status), distinguishing it from sibling tools like obter_pix (get single) or cancelar_pix (cancel). The scope 'geradas' (generated) further refines what is listed.
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 by stating the filters available, suggesting it is for listing PIX charges with optional time/status filtering. However, it does not explicitly name alternatives or provide when-not-to-use guidance, unlike the high-calibration example which references another tool. The implied context is clear but not explicitly contrasted with siblings.
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?
With no annotations, the description carries the full burden. It mentions the identifier requirement but fails to disclose irreversible side effects, authorization needs, or consequences for associated data, leaving agents without critical 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?
The description is a single, efficient sentence that front-loads the action and immediately provides the required identifier context. 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?
For a simple delete tool with no output schema or annotations, this is a minimal viable description. It covers the core purpose and identifier options but omits behavioral details like permanence, side effects, and response expectations, making it incomplete for robust agent 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 schema has zero descriptions, but the description partially compensates by indicating that the two parameters are alternative identifiers. However, it does not explain their meaning or which to prefer, relying on the parameter names themselves.
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 uma conta corrente do OMIE') with a specific verb and resource, and the verb 'excluir' distinguishes it from sibling tools like 'incluir' or 'alterar'.
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 usage hint by instructing to provide either codigo_conta_corrente or codigo_integracao, but does not explicitly contrast with alternative tools or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the scope (open items only) but omits that deletion is permanent, any side effects, and permission requirements. For a destructive operation, this is a significant gap.
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 single sentence with an essential qualifier in parentheses. It is concise, front-loaded, and free of 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 destructive tool with no annotations and undefined parameter semantics, the description leaves critical gaps about how to specify the target entry and what happens after deletion. The open-items constraint is helpful but insufficient for complete usage.
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 purpose of 'codigo_lancamento_omie' or 'codigo_lancamento_integracao', nor whether at least one is required. The parameter names offer vague hints but no operational guidance.
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 identifies the action ('Exclui') and resource ('conta a pagar do OMIE'), and adds a scope constraint ('apenas títulos em aberto'). This distinguishes it from sibling tools like 'excluir_conta_receber' and 'cancelar_pagamento_conta_pagar'.
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 parenthetical 'apenas títulos em aberto' provides clear usage guidance: only open (unpaid) payables should be deleted. This implies that other tools handle paid items or cancellations, though alternatives are not explicitly named.
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 discloses the core behavior (listing suppliers) and mentions pagination and filters, which are key behavioral traits. However, with no annotations provided, it does not address potential side effects, return format, or limitations—though the verb 'Lista' implies a safe read operation.
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, front-loaded sentence with no redundant information. Every word contributes meaning: the verb, resource, context (OMIE), and key capabilities.
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?
The tool has five parameters and no output schema, so the description is responsible for explaining behavior and return expectations. It only states that suppliers are listed with pagination and filters, omitting details such as response structure, pagination defaults, or filter behavior, making it insufficient for an agent to fully predict outcomes.
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 description only paraphrases the parameter categories ('paginação e filtros') without explaining the meaning of the parameters. It does not clarify the purpose of 'apenas_fornecedor' (default 'S') or the filtering semantics, leaving ambiguity that the schema names alone do not resolve.
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 suppliers registered in OMIE, using the specific verb 'Lista' and identifying the resource 'fornecedores'. It also mentions pagination and filters, distinguishing it from 'consultar_fornecedor' which likely retrieves a single supplier.
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 listing suppliers with pagination and filters but does not explicitly state when to use this tool vs alternatives like 'consultar_fornecedor' or other list tools. There are no exclusions 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?
With no annotations, the description carries the burden, and it does add the important caveat that OMIE calculates for a single day, not a period. However, it omits whether the operation is read-only, any permission requirements, or what the response structure looks like, leaving the agent partially informed.
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, consisting of two sentences with the purpose front-loaded. It adds the essential single-day nuance without wasting words or restating the tool name.
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?
The tool has 3 parameters and no output schema or annotations, yet the description omits parameter behavior and return value structure. While the single-day caveat is valuable, the lack of detail about the summary's composition and the flag parameters makes it incomplete for reliable 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 schema provides no descriptions for data, apenas_resumo, or exibir_categoria, and the description only indirectly references 'data de referência'. The boolean parameters are completely unexplained, so agents cannot determine their impact without external knowledge.
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 'Obtém' (gets) and the resource 'resumo financeiro consolidado' with specific components (contas a pagar, a receber, saldo bancário). It distinguishes itself from sibling tools like listar_contas_pagar or consultar_fluxo_caixa by focusing on a consolidated snapshot for one date.
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 use when a consolidated financial summary is needed, but it does not explicitly contrast with alternatives or state when not to use it. The single-day note hints at a limitation, but there is no comparison to period-based tools or other 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?
The description labels the operation as a query ('Consulta'), which implies read-only behavior, and restricts scope to a specific bank. With no annotations, it would benefit from disclosing more about return format, error behavior, or whether the code must be exact, but it provides basic 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 a single, front-loaded sentence with no filler. It efficiently communicates the action, resource, and scope.
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 is relatively simple and the description conveys its core purpose, but with no output schema or annotations, it is missing details about the response contents and the meaning of the 'codigo' parameter. It is minimally adequate but leaves noticeable 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 input schema has 0% description coverage, so the description must compensate. It only connects 'banco específico' to 'codigo_banco' and alludes to CNAB, but it does not explain what 'codigo' represents or its expected format.
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 identifies the action ('Consulta'), the resource ('finalidade de transferência (CNAB)'), and the scope ('de um banco específico'). This distinguishes it from the sibling tool 'listar_finalidades_transferencia', which implies listing all purposes rather than retrieving one.
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 the tool should be used when a single transfer purpose for a specific bank is needed. However, it does not explicitly state when to prefer this over alternatives or mention the sibling list 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?
No annotations are provided, so the description carries the responsibility. The verb 'consulta' indicates a read operation, and the description adds the core comparison behavior. However, it does not disclose return format, pagination, error conditions, or any additional side effects beyond the obvious read-only nature.
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, front-loaded sentence that directly states what the tool does. Every word contributes to meaning, with no redundant or filler content.
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 is simple, with two obvious integer parameters and no output schema. The description conveys the core function and output essence (comparison by category), which is minimally adequate. However, it omits details about the response structure, possible empty results, and any usage limitations, leaving the agent with some uncertainty.
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 0% description coverage, and the description does not explain the 'ano' and 'mes' parameters beyond referencing 'do mês'. While the parameter names are self-explanatory, the description does not enrich their semantics (e.g., format, ranges, or rationale), leaving the agent to rely solely on the schema's basic type/required fields.
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 'Consulta' (queries) and a clear resource: the month's cash flow, further refined by the unique comparison of forecast vs actual values by financial category. This distinguishes it from sibling financial query tools that focus on balances, transactions, or summaries.
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 monthly cash flow analysis with forecast vs actual comparison, but it does not explicitly mention when to choose this over alternatives like 'obter_resumo_financeiro' or 'consultar_extrato_bancario', nor does it state exclusions 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?
With no annotations, the description carries the full burden. It discloses that the tool lists accepted types and provides example values, but it does not describe the response format or pagination behavior. The read-only nature is implied by 'Lista' but not explicitly stated.
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 purpose, and includes a usage directive. Every word adds value, with no filler or repetition.
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 conveys the core purpose and usage, and references a sibling tool for context. However, it does not explain the pagination parameters or the return structure, which are not covered by the schema descriptions. Since the tool is simple, this is a minor 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?
The schema has 5 parameters with 0% description coverage, and the description does not mention any of them. Parameters like pagina, ordenar_por, and registros_por_pagina are left entirely to the schema, with no added 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 the tool lists OMIE's accepted current account types, with specific examples (CC, CX, AC). This distinguishes it from siblings like listar_contas_correntes (which lists accounts) and incluir_conta_corrente (which registers).
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?
It explicitly advises using the tool to validate the tipo_conta_corrente field before registering via incluir_conta_corrente. This provides clear context, though it does not mention when not to use it or name alternative validation 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It specifies the types of data returned (títulos, baixas, lançamentos de conta corrente), which is helpful, but it does not state whether the operation is read-only, describe pagination or sorting behavior, or mention any authentication requirements. For a listing tool, this is adequate but not comprehensive.
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, consisting of two sentences that front-load the main purpose and add a useful contrast with a sibling tool. There is no redundant or unnecessary text.
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 tool with 15 parameters, no annotations, and no output schema, the description is too brief. It clearly defines the content scope but omits details about pagination, parameter semantics, and return format, making it incomplete for an agent to correctly construct a request. The complexity of the tool demands more guidance than provided.
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 15 parameters with zero descriptions (0% coverage), so the description must compensate by explaining how filters work. However, it does not mention any parameter such as status, natureza, or date ranges, leaving their meaning and usage entirely to inference from their names. The description fails to provide the necessary parameter guidance.
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 this tool performs a unified query of financial movements, including accounts payable/receivable, write-offs, and current account entries. It distinguishes itself from the sibling tool pesquisar_lancamentos_financeiros, which only returns titles, making its scope explicit.
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 names pesquisar_lancamentos_financeiros as an alternative and explains the key difference: this tool includes baixas (effective payments/receipts) while the sibling only returns titles. This provides clear when-to-use guidance, though it does not mention all other sibling 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?
With no annotations, the description carries the full burden. It does disclose the one-type-per-call constraint and clarifies 'em aberto' as 'não liquidados'. But it omits other behavioral traits such as pagination, error behavior, or response format, which are relevant for a listing tool.
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, front-loaded with the purpose, followed by a key constraint. No filler words; every sentence earns its place.
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?
The core purpose and main parameter are clear, but the description gives no guidance on the other five parameters, pagination, or when to choose this over sibling tools. Given the moderate complexity (6 params, no output schema, no annotations), this leaves significant gaps for an agent.
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 compensate. It only clarifies the 'tipo' parameter (PAGAR or RECEBER), leaving the other five parameters (data, pagina, nome_cliente, codigo_cliente, registros_por_pagina) without any added meaning. This is insufficient for a 6-parameter tool.
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 a specific action ('Lista') on a clear resource ('títulos financeiros em aberto (não liquidados)') and scopes it by type. The phrase 'de um tipo' plus 'use PAGAR ou RECEBER' differentiates it from sibling tools that likely handle only one specific type.
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 usage instruction: OMIE handles one type per call and tells the user to use PAGAR or RECEBER. However, it does not explicitly contrast with alternatives like listar_contas_pagar or listar_contas_receber, so it stops short of a full 5.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose important behavior: only informed fields are updated (partial update) and one of two identifiers must be provided. However, it omits details about permission requirements, return format, error cases, or whether changes are reversible, which is significant for a mutation tool.
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 verb and object. It avoids unnecessary words and each sentence provides essential information: what the tool does and how to invoke it correctly. This is an ideal level of conciseness.
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?
The tool has high complexity with 14 optional parameters, no annotations, and no output schema. The description covers the critical identification and partial update logic but fails to address the return value, error scenarios, or validation rules. Given this complexity, the description is insufficient for full understanding, leaving significant gaps.
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 description coverage is 0%, so the description must compensate. It does add meaning by clarifying that codigo_lancamento_omie and codigo_lancamento_integracao are identifiers and all other fields are optional updates. However, it doesn't explain the semantics of the remaining 12 parameters, though the property names (e.g., data_vencimento, valor_documento) are somewhat self-explanatory within a financial context.
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 with a specific verb ('Altera') and resource ('conta a receber existente'). It distinguishes itself from sibling tools like incluir_conta_receber (create), excluir_conta_receber (delete), and consultar/listar (read) by implying an update operation on an existing record.
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 guidance on when to use the tool: to modify an existing accounts receivable. It specifies the required identifier condition (codigo_lancamento_omie or codigo_lancamento_integracao) and explains the partial update behavior. However, it doesn't explicitly name alternative tools or state when not to use it, which prevents a perfect score.
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?
Without annotations, the description discloses key behavior: it returns all transactions and the period balance. It also reveals the OMIE constraint requiring one of the two IDs. However, it doesn't confirm read-only behavior, error handling, or result limitations, which would be valuable given no other metadata.
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, front-loaded with the primary purpose. Each sentence is purposeful: stating what it does, what it returns, and the key input requirement.
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 the core function, return type, and a key parameter constraint, but leaves gaps on date format, the meaning of exibir_apenas_saldo, and the structure of the returned statement. With no output schema or annotations, these omissions make it 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?
Schema description coverage is 0%, and the description adds meaning only to the two ID parameters, explaining they are mandatory alternatives and how to obtain them. It does not explain data_inicio/data_fim format or exibir_apenas_saldo, leaving most parameters underspecified.
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: 'Consulta o extrato bancário de uma conta corrente em um período' and specifies the return ('Retorna todos os lançamentos e o saldo do período'). This is a specific verb+resource+scope that distinguishes it from related tools like listar_lancamentos_bancarios.
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 usage context by requiring one of two account IDs ('Informe codigo_conta_corrente ou codigo_integracao_conta') and recommending listar_contas_correntes to discover the code. It lacks an explicit 'when not to use' or direct comparison to alternatives, but the guidance is helpful.
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?
With no annotations, the description carries the transparency burden. It discloses that the tool returns only the status and is a lighter query, which is useful. However, it does not describe the output format, pagination behavior, or any filters that affect results—leaving some behavioral ambiguity for a list operation.
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, compact sentence that front-loads the core action and adds a meaningful comparison with 'listar_pix'. Every word serves a purpose, and there is no redundancy or filler.
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 list tool with no output schema and 5 parameters, the description is minimally sufficient—it covers the main purpose and the relationship to siblings. However, it lacks any hint about the meaning of filter parameters or the response structure, so an agent might need to rely on the schema names or external knowledge.
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 compensate by explaining parameter meanings. It does not mention any parameters (pagina, status, emissao_de, emissao_ate, registros_por_pagina) or how they affect results, leaving the agent to infer from names alone. This is a clear gap given the absence 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 is specific: 'Lista apenas o status das cobranças PIX geradas' clearly states the verb (lista), the resource (status das cobranças PIX), and the scope (geradas). It differentiates from siblings by explicitly naming 'listar_pix' and noting it is a 'consulta mais leve' (lighter query), which makes the tool's purpose distinct.
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 clear usage context by comparing to 'listar_pix': it is a lighter query for when only the status is needed. This explicitly names an alternative, satisfying the 'when to use vs alternatives' criterion, though it does not specify exclusions or conditions when to avoid 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?
With no annotations, the description carries the full burden. It discloses a prerequisite (at least one identifier) and implies a read-only operation via 'consulta', but does not detail error handling, response format, or behavior when multiple identifiers are provided. It adds some value but lacks rich 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?
The description is a single, concise sentence that front-loads the primary purpose and immediately follows with the key usage requirement. No filler or 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?
The tool has no output schema or annotations, so the description must cover more ground. It addresses the tool's purpose and input requirement, but omits details about return values, potential errors when no identifier is provided, and how it differs from similar query tools. It is adequate but has clear gaps.
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 description coverage is 0%, so the description must compensate. It refers to the parameters collectively as 'identificadores' and states that at least one is needed, which adds a constraint not in the schema. However, it does not explain each parameter's individual meaning or precedence, though the parameter names are self-explanatory.
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: 'Consulta detalhes de um fornecedor específico' (queries details of a specific provider). The verb 'consulta' and resource 'fornecedor específico' are specific and distinguish it from siblings like 'listar_fornecedores' (list providers) and 'incluir_fornecedor' (include provider).
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: it's for a specific provider and requires at least one identifier ('Informe ao menos um dos identificadores'). This gives usage guidance on prerequisites but does not explicitly mention when not to use it or name 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?
With no annotations, the description carries the full burden and does disclose a key behavioral trait: 'só os informados são atualizados' (only provided fields are updated), indicating PATCH-like partial update semantics. It also states the identification requirement. It omits response shape or error behavior, but the provided behavioral detail goes beyond a minimal statement.
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 well-structured sentence that leads with the primary action, then gives the identification rule, and closes with the partial-update behavior. No redundant words; every clause 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 13 parameters, no output schema, and no annotations, the description covers the essential operational aspects (how to identify, what updates occur) but is thin on validation details, return values, and error scenarios. It is minimally viable for a straightforward update operation but does not fully compensate for the lack of schema descriptions.
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 compensate. It adds meaning for the two identifier parameters (codigo_conta_corrente and codigo_integracao) and distinguishes them from updatable fields. However, it does not explain the remaining 11 parameters (e.g., saldo_data, ocultar_do_fluxo, tipo_conta_corrente), leaving the agent to infer from names 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 uses the specific verb 'Altera' (alters) with the resource 'conta corrente existente' (existing current account), clearly distinguishing it from sibling tools like incluir_conta_corrente (create), excluir_conta_corrente (delete), and consultar_conta_corrente (query). It unambiguously states the tool's function as an update operation.
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 guidance on how to identify the target account: 'Informe codigo_conta_corrente ou codigo_integracao' and clarifies that other fields are optional with partial-update semantics. It does not explicitly name alternatives or say when not to use the tool, but the context is strong enough to infer this is for existing accounts only.
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?
With no annotations provided, the description carries the full burden. It discloses that the operation reverses the baixa (write-off), which is a key behavioral trait, and clarifies the identifier source. However, it does not mention potential side effects, permission requirements, or conditions under which cancellation is allowed.
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 main purpose and followed by a crucial usage note. There is 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?
For a simple reversal tool with no output schema and only two optional parameters, the description covers the core purpose, the effect (reversing the baixa), and the input source. It could be slightly more complete by indicating the type of response or any preconditions beyond obtaining the baixa code.
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 adds that the parameters refer to the baixa, not the title, and that the baixa is obtained from lancar_pagamento. However, it does not explain the difference between codigo_baixa and codigo_baixa_integracao, leaving the agent to infer which to use.
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 cancels/stornoes the payment of an accounts payable and reverses the write-off. It distinguishes itself from related tools like lancar_pagamento and cancelar_recebimento by specifying the resource (conta a pagar) and the unique identification method (baixa, not title).
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?
It tells the agent the tool identifies the baixa (write-off) returned by lancar_pagamento, not the title, which is essential for correct use. This implies a workflow (first post payment, then cancel using the baixa code), but it does not explicitly name alternatives or state when not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the partial update behavior ('só os informados são atualizados') and the need for an identifier, which are key side effects. It does not mention return values, error behavior, reversibility, or permissions, but the partial update disclosure is substantial.
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 only two sentences, front-loaded with the primary purpose, followed by essential usage instructions. No wasted words; every clause 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?
Given no annotations, no output schema, and 12 parameters, the description covers core purpose and partial update semantics but omits return values, error conditions, and detailed parameter explanations. It is adequate for basic use but leaves gaps for a complex update operation.
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 description coverage is 0%, and the description meaningfully clarifies that codigo_lancamento_omie and codigo_lancamento_integracao are identifiers and the rest are optional. However, it does not explain the meaning, format, or relationships for the other 10 parameters beyond their surface-level names, so the compensation is partial.
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 uma conta a pagar existente' — a specific verb (alter) and resource (existing accounts payable). It distinguishes from siblings like incluir_conta_pagar, consultar_conta_pagar, and excluir_conta_pagar, and adds the identification requirement.
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?
It provides clear usage context: you must inform either codigo_lancamento_omie or codigo_lancamento_integracao to identify the record, and that other fields are optional with only specified ones updated. It does not explicitly name alternatives, but the instruction is concrete. Lacks 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey the tool's safety and side effects. It does indicate that the operation is a search (implying read-only) and reveals the behavior when the code is omitted. However, it does not explicitly state the operation is read-only, disclose any error conditions, or describe the response structure, which would be fuller disclosure.
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, consisting of two short sentences that convey the purpose and the key parameter behavior. Every word earns its place, and it is front-loaded with the 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?
For a simple list/search tool with one optional parameter and no output schema, the description is fairly complete. It tells the agent what the tool does and how to control the scope via the code parameter. It does not explicitly state the return format, but the tool name and the phrase 'lista todos' imply a list result, which is sufficient for this complexity level.
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 only defines 'codigo' with no description, so the description adds essential meaning by explaining that omitting it lists all documents. This gives the agent clear direction on how to use the parameter, though it does not specify the exact format or expected values beyond being a string.
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: 'Pesquisa os tipos de documento cadastrados no OMIE' (searches document types registered in OMIE). It also specifies that omitting the code lists all, which distinguishes it from sibling tools like 'consultar_tipo_documento' that likely retrieve a single record.
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 clear context for use: it is for searching/listing document types, and the instruction 'Omita o código para listar todos' explains when to omit the parameter. However, it does not explicitly mention alternative tools or exclusions, such as using 'consultar_tipo_documento' for a specific document type.
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?
With no annotations, the description carries the behavioral burden. It discloses that the operation reverses a write-off ('revertendo a baixa') and that it identifies the baixa rather than the title, which is key behavioral information. However, it omits details about idempotency, errors, or side effects beyond the reversal.
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 focused sentences with no filler. The description is front-loaded with the action and immediately provides the key distinction, making it easy to scan and understand.
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 core purpose is well covered, but the description leaves ambiguity around the two optional parameters—whether one is required, which takes precedence, and what happens if both are provided. There is also no output schema or mention of return behavior, though the tool is relatively simple.
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 essential meaning beyond the schema by explaining that the parameters refer to the baixa code returned by 'lancar_recebimento', not the title. This compensates for the 0% schema coverage, though it doesn't clarify the relationship between 'codigo_baixa' and 'codigo_baixa_integracao'.
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 'Cancela/estorna o recebimento de uma conta a receber' and its effect 'revertendo a baixa'. It also distinguishes from sibling tools by specifying it targets recebimento and uses the baixa identifier, not the título.
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?
It provides usage context by stating the baixa is returned by 'lancar_recebimento', implying this tool should be used after that one. The 'não o título' clause explicitly warns against using a title identifier, giving a clear when-not example.
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:

[![omie-finance-mcp MCP server](https://glama.ai/mcp/servers/denilsonpy/omie-finance-mcp/badges/card.svg)](https://glama.ai/mcp/servers/denilsonpy/omie-finance-mcp)

Score Badge

Copy to your README.md:

[![omie-finance-mcp MCP server](https://glama.ai/mcp/servers/denilsonpy/omie-finance-mcp/badges/score.svg)](https://glama.ai/mcp/servers/denilsonpy/omie-finance-mcp)

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/denilsonpy/omie-finance-mcp'

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