omie-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools target distinct resources and actions, but there is some overlap between listar_titulos_em_aberto and listar_contas_pagar/receber, and between pesquisar_lancamentos_financeiros and the individual list tools. Detailed descriptions help clarify intended use, so confusion is limited.
Naming Consistency5/5All tool names follow a consistent Portuguese verb-infinitive + noun pattern (listar_, consultar_, incluir_, alterar_, excluir_, lancar_, cancelar_) using snake_case. This provides a predictable and clear naming scheme across the entire set.
Tool Count2/5With 41 tools, this server significantly exceeds the typical well-scoped range of 3-15 tools. While the financial domain is broad, the count feels heavy and may overwhelm agents, especially with many closely related list/consult operations.
Completeness3/5The tool surface covers most core financial workflows: suppliers, accounts payable/receivable, bank entries, categories, and DRE. However, there are notable gaps: no update/delete for contas pagar/receber, no ability to create or update bank accounts, and no delete for suppliers. This leaves some lifecycle stages incomplete.
Average 3.5/5 across 41 of 41 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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.jsonto 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?
With no annotations, the description must disclose behavioral traits but only states the action. It fails to mention side effects, required permissions, duplicate handling, return values, or idempotency. For a create operation with 14 parameters, this is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified and provides minimal value beyond the tool name. It lacks detail or structure that would help an agent understand the tool's use, making it more under-specification than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given 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 annotations, no output schema), the description is drastically incomplete. It does not mention return values, required field formats, or any operational context, making it very difficult 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.
Parameters1/5Does 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 14 parameters. It does not compensate for the lack of schema details, leaving the agent without guidance on required formats (e.g., CNPJ/CPF) or optional fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cadastra um novo fornecedor no OMIE.' clearly specifies a create/register operation for a supplier, using the verb 'Cadastra' (registers) and resource 'fornecedor'. This distinguishes it from siblings like listar_fornecedores (list) and alterar_fornecedor (update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as alterar_fornecedor for modifications. There is no mention of prerequisites, integration context, or situations where this tool is not appropriate. Usage is only implied by the verb 'Cadastra'.
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 but only says 'consulta' (query). It does not disclose behavior when no record is found, whether permissions are needed, or that exactly one of the two codes should be provided. This is minimal for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose without any wasted words. However, the extreme brevity limits the explanatory content, which is a trade-off that prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, no annotations, and no output schema, the description is woefully incomplete. It fails to explain parameter usage, expected response, or error scenarios, making it inadequate for reliable invocation by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two optional parameters with 0% description coverage, and the tool description does not mention them at all. The agent receives no help understanding the distinction between codigo_lancamento_omie and codigo_lancamento_integracao or how they should be used, making this a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries details of a specific accounts payable record ('Consulta detalhes de uma conta a pagar específica'). It uses a specific verb (consulta) and a clear resource, but does not explicitly differentiate from sibling tools like listar_contas_pagar, so it falls short of full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 listing tools or how to supply the identifier. The word 'específica' hints at single-record use, but no explicit conditions, alternatives, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it creates a payable, which is already implied by the tool name. It does not mention write side effects, permission requirements, idempotency, response behavior, or potential validation errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of fluff, but it is severely under-specified for a tool with 11 parameters and 5 required fields. The brevity is more omission than concision, lacking any essential contextual information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no annotations, no output schema), the description is grossly incomplete. It fails to explain required input semantics, return values, error behavior, or any constraints, leaving the agent without sufficient information 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage across 11 parameters, and the description mentions no parameter details at all. The agent must rely on field names like codigo_categoria and data_previsao, which are not fully self-explanatory, and the description adds no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cria uma nova conta a pagar no OMIE' clearly states a specific action (create) and resource (conta a pagar), and it naturally distinguishes the tool from siblings like incluir_conta_receber and consultar_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, no prerequisites (e.g., needing a supplier/client code or valid category), and no mention of related lookup tools like consultar_conta_pagar. The usage context is only 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, the description carries the full burden for behavioral disclosure. 'Consulta' implies a read-only operation, but it does not explain behavior on not-found, required permissions, or return format. Minimal information beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and efficient, though it omits necessary details, which is under-specification rather than a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and two optional parameters, the description is too sparse to support correct invocation. It does not explain return values, parameter usage, or when to choose this over similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions neither parameter. The field names are somewhat self-explanatory, but the description adds no meaning about which to use, whether one is required, or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'consulta' and resource 'lançamento bancário específico', clearly indicating it is a read operation for a single bank entry. It distinguishes from sibling tools like listar_lancamentos_bancarios and incluir_lancamento_bancario, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor on how to choose between the two optional parameters. The description only states what it does, not when to invoke it or what prerequisites exist.
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 full responsibility for behavioral disclosure. It only says 'creates', which implies mutation, but does not mention required permissions, reversibility, duplicates, error handling, or the response format. This is a significant gap for a write 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and easy to read, but it is under-specified, which limits the value of its conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters, 5 required, no annotations, and no output schema, this minimal description is inadequate. It does not cover return values, prerequisites, validation behavior, or any other contextual information needed by 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.
Parameters1/5Does 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. Most parameter names are not self-explanatory for a non-domain expert, and the description adds no value to the schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool creates a new 'conta a receber' (accounts receivable) in OMIE, using the verb 'cria' (creates). This distinguishes it from sibling tools that consult, list, or delete contas a receber. However, it adds no extra scope or detail beyond a direct translation of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 simply states the action without mentioning prerequisites, exclusions, or alternative tools for related tasks.
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 the action without mentioning side effects (e.g., marking the receivable as paid), reversibility, or required authorizations. This is a significant 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, which is economical. However, it lacks any structure such as examples, parameter hints, or links to related tools. While not wordy, it is so sparse that it offers little beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial operation with 10 parameters and no output schema, the description is severely incomplete. It fails to explain the operation's effect on the accounts receivable, the meaning of required fields, or any validation rules. This is far below the minimum viable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description was expected to compensate. It adds no information about the 10 parameters, leaving fields like 'juros', 'multa', 'desconto' unexplained in context. The agent must rely on names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Registra' - registers) and clearly identifies the resource ('recebimento (baixa) de uma conta a receber' - receipt/write-off of an accounts receivable). This distinguishes it from sibling tools like 'lancar_pagamento' (register payment) and 'cancelar_recebimento' (cancel receipt), 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the receivable must exist) or provide context such as 'use after payment is received.' No exclusions or alternative references are given, so the agent lacks decision support.
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, and the description only states the action 'exclui' without disclosing side effects, irreversibility, or required permissions. It does not clarify whether this is a hard delete or if it affects related financial records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, but it is under-specified rather than efficiently complete; additional sentences are needed to describe parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations and no output schema, the description lacks essential context about parameter selection criteria, consequences, and relationship to other deletion tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the two parameters (codigo_lancamento and codigo_lancamento_integracao), leaving the agent to infer their meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Exclui' (deletes) and resource 'lançamento bancário em conta corrente' (bank entry in checking account), clearly distinguishing it from sibling tools like listar/consultar/incluir_lancamento_bancario 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cancelar_pagamento_conta_pagar or excluir_conta_pagar; no context or exclusions 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?
Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It only mentions that listing is possible with filters, but does not disclose pagination behavior, default ordering, return format, or whether filters are exact or partial matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the main action and resource. There is no filler or unnecessary details. However, it is almost too terse, failing to include essential usage or parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 9 optional parameters, no output schema, and no annotations. The description is too minimal to provide a complete understanding of the tool's capabilities and behavior, such as pagination, sorting, and filter semantics. It is adequate only for a very basic listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not compensate by explaining parameter meanings. It names three filter dimensions (status, period, supplier) but does not map them to actual parameter names like 'filtrar_por_status' or 'filtrar_cliente', nor does it explain formats for dates and ordering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' and the resource 'contas a pagar', specifying it lists accounts payable with filter options. This distinguishes it from sibling tools like 'listar_contas_receber' (accounts receivable). However, there is a slight mismatch: it mentions 'fornecedor' while the schema uses 'filtrar_cliente', which may confuse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'consultar_conta_pagar' for a single account or 'listar_contas_receber' for receivables. The description only states what it does, not when it should 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 must disclose behavioral traits, but it only states the query action. It does not mention whether the operation is read-only, whether exactly one of the two identifier parameters must be provided, what happens if both are omitted, or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or repetition. It is efficiently structured, though minimal in content; conciseness is appropriate but not exceptional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with two optional parameters, no output schema, and no annotations, the description is too sparse. It fails to explain how to identify the account, what 'detalhes' includes, or the expected response shape, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the two parameters (codigo_integracao and codigo_conta_corrente). It does not explain that either identifier can be used, their relationship, or which one is preferred.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Consulta' and resource 'detalhes de uma conta corrente específica', clearly indicating it queries details of a single current account. The word 'específica' differentiates it from sibling list tools like 'listar_contas_correntes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that listar_contas_correntes should be used for listing multiple accounts, nor does it clarify that this tool is for retrieving details given a specific account identifier.
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 full responsibility for disclosing behavior. It does not mention pagination, return format, or the read-only nature of the operation. The pagination parameters in the schema suggest behaviors that are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is efficient and directly states the tool's purpose. It is not verbose, though it sacrifices important detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits the pagination behavior implied by the input schema. With no annotations and no output schema, the description is not complete enough 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'pagina' or 'registros_por_pagina' parameters. With 0% schema description coverage, it fails to compensate for the schema's minimal information, leaving the agent without any parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists all bank/checking accounts registered in OMIE, using a specific verb and resource. It is clearly distinct from sibling tools that list other entities or consult single accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'consultar_conta_corrente' or 'listar_tipos_conta_corrente'. The description only states what it does, not the appropriate context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states the list action without mentioning pagination, read-only nature, ordering, or any side effects. This is insufficient for a tool with 8 optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action, and contains no fluff. However, it sacrifices important details, so it's concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema, many siblings), the one-line description is incomplete. It lacks information on return format, filtering, sorting, and usage alongside other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description does not elaborate on any of the 8 parameters (dates, account code, pagination, ordering). The agent receives no help understanding what values to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lista lançamentos/transações bancárias em conta corrente' (Lists bank entries/transactions in current account). It specifies the verb (lista) and resource (lançamentos/transações bancárias) and scope (conta corrente). This distinguishes it from sibling 'consultar_lancamento_bancario' which implies retrieving 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description doesn't explain when to use this tool over alternatives like 'pesquisar_lancamentos_financeiros' or 'consultar_extrato_bancario', nor does it mention any filters or options like date ranges or account codes.
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 of behavioral disclosure. It only states that the tool consults details, without addressing parameter requirements, return format, or potential side effects. 'Consulta' implies a read-only operation, but the description adds no meaningful behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's action and object. It contains no filler, redundancy, or extraneous information, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters, no output schema, and no annotations, this description is under-specified. It fails to clarify that at least one identifier code must be provided, what the response contains, or how it differs from related query tools like pesquisar_lancamentos_financeiros.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention either parameter (codigo_lancamento_omie or codigo_lancamento_integracao), leaving their roles entirely to the schema names. With 0% schema description coverage, the agent receives no guidance on which code to supply, whether one is required, or how they relate, making parameter use ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Consulta detalhes') and the resource ('uma conta a receber específica'). It distinguishes itself from sibling tools like listar_contas_receber (list) and consultar_conta_pagar (different resource), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention listar_contas_receber for multiple records or indicate any prerequisites, exclusions, or conditions for use. The agent must infer usage from the tool name and sibling 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool mutates an existing supplier, but it does not explain which parameter(s) identify the target supplier (e.g., codigo_cliente_omie or codigo_cliente_integracao), whether the update is partial or full, or what happens if the supplier does not exist. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose without wasted words. While minimal, it is appropriately concise for the basic action it defines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 optional params, no required fields, no output schema, no annotations), the description is severely incomplete. It does not explain the required identifier, update semantics, or success/failure behavior, making it insufficient for an agent to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level information. With 12 nullable parameters, including two possible identifier fields (codigo_cliente_omie, codigo_cliente_integracao), the description does not clarify which fields are necessary or how they relate. This leaves critical ambiguity about how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Altera dados') and the resource ('fornecedor existente no OMIE'). It distinguishes itself from siblings like 'incluir_fornecedor' (create) and 'consultar_fornecedor' (read) by specifying alteration of an existing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Altera' and phrase 'fornecedor existente' imply it is for updating already-created suppliers, but there is no explicit when-to-use or exclusion guidance, nor any mention of alternatives like 'incluir_fornecedor' or 'consultar_fornecedor.' The context is enough to infer basic usage, but not to disambiguate specific situations.
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 (records payment) and does not mention side effects such as whether the account payable is marked as paid, whether the operation is irreversible, or whether it validates amounts. For a financial mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no unnecessary words and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no annotations, and no output schema, the one-sentence description is severely inadequate. It does not explain the purpose of each parameter, expected return values, preconditions, or side effects, making it difficult 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.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description provides no parameter information at all. It fails to clarify the meaning or usage of fields like 'conciliar_documento', 'codigo_lancamento_omie', or 'codigo_lancamento_integracao', leaving the agent without the necessary context to correctly populate parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Registra o pagamento (baixa) de uma conta a pagar' clearly identifies the action (register payment/settlement) and resource (accounts payable). It distinguishes from sibling tools like 'lancar_recebimento' (record receipt) and 'cancelar_pagamento_conta_pagar' (cancel payment), 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to record a payment against an accounts payable. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites (e.g., the account payable must already exist) or exclusions (e.g., not for receivables).
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?
There are no annotations, so the description carries the full burden. It only mentions 'Cria' (creates) but does not disclose side effects, reversibility, required permissions, or how debit/credit is determined. This is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is easy to parse and front-loaded with the action. It contains no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, 4 required, and no output schema, the description is too sparse. It does not explain return values, error conditions, or parameter semantics, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation for any of the 10 parameters. Schema description coverage is 0%, and the description only hints at debit/credit without linking it to a specific parameter like 'valor' or 'tipo_documento'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cria') and the resource ('lançamento manual em conta corrente'), and specifies the scope ('débito ou crédito'). This distinguishes it from sibling read/delete tools like listar_lancamentos_bancarios or excluir_lancamento_bancario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives such as 'lancar_pagamento' or 'lancar_recebimento'. The description only states what the tool does, not the context or conditions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full disclosure burden. It mentions listing with filters but fails to disclose pagination behavior, default filters, output format, or the distinction between due-date and issue-date filtering. The agent is left 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb and resource. No fluff or redundant 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 12 optional parameters and no output schema or annotations, the description is only one sentence long. It does not explain default behavior, pagination, return structure, or the meaning of the two date-range filters, making it insufficient for correct invocation in many scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only mentions status, period, and client filters (approximately 3 of 12 parameters), ignoring pagination, sorting, order direction, conta corrente, and issue-date filters. The schema titles provide basic labels, but the description adds minimal value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists accounts receivable ('contas a receber') with filters for status, period, and client. It uses a specific verb and resource, making it easy to distinguish from related tools like consultar_conta_receber or listar_contas_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as listar_contas_pagar, consultar_conta_receber, or listar_titulos_em_aberto. The description only states what the tool does, leaving the selection decision to the agent without any exclusions or alternative hints.
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 of behavioral disclosure. It states the open-title restriction but reveals nothing about side effects, irreversibility, required permissions, or consequences (e.g., whether deletion cascades to related movements). For a destructive action, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently conveys the action and a key restriction, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no annotations, no output schema, and minimal parameter explanation, the description is inadequate. It lacks return value details, idempotency, or references to related tools in a rich sibling context. The open-title parenthetical helps but is insufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description should compensate. It adds no explanation of the two identifiers ('codigo_lancamento_omie' and 'codigo_lancamento_integracao'), their relationship, or the need to provide at least one. The parameter names offer some hint but are not enough to guide correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Exclui' - deletes) and resource ('conta a receber do OMIE'), distinguishing it from sibling tools like 'excluir_conta_pagar'. The parenthetical 'apenas títulos em aberto' further clarifies the scope, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The constraint 'apenas títulos em aberto' implies this tool is for open receivables, giving context on when it is applicable. However, it does not explicitly mention alternatives (e.g., 'cancelar_recebimento' for received payments) or when not to use it, so guidance is 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It discloses response fields (codigo_dre/dadosDRE, categoria_superior, flags) and the OMIE code convention, which is useful. However, it does not disclose pagination behavior, default ordering, or how filtering parameters like 'tipo' or 'apenas_ativas' affect results, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the primary purpose, then details the returned fields, and provides a helpful code convention. There is no redundancy or fluff; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description explains part of the response structure but omits parameter semantics and pagination/filtering behavior. This is incomplete for an agent to correctly invoke the tool, especially since all parameters are optional and their behavior is undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description does not mention any of them. The agent cannot infer what 'tipo', 'descricao', 'apenas_ativas', 'pagina', or 'registros_por_pagina' mean from the description. The code convention might loosely relate to 'tipo', but it is not explicit, making this a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the financial category plan of OMIE (revenues and expenses), using the specific verb 'Lista' and identifying the resource. It distinguishes from sibling listing tools by focusing on 'categorias' (categories) rather than groups or types, and the additional field details reinforce its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus siblings like listar_grupos_categoria or consultar_categoria. However, the description implies its use for listing categories, and the code convention may aid interpretation. It lacks explicit when/when-not guidance, but the context is clear enough for a basic list operation.
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 full burden. It mentions pagination and filters but lacks specifics on response format, pagination mechanics, default filter behavior, or the effect of 'apenas_fornecedor'. No read-only or safety hints are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource. It is concise with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, this description is too sparse. It does not cover return values, pagination limits, filter combination semantics, or prerequisites. It is minimal viable but not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It groups parameters as 'paginação e filtros' but does not explain each parameter's meaning, defaults, or allowed values. Parameter names are partially self-explanatory, but the description adds minimal distinct value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lista fornecedores cadastrados no OMIE com paginação e filtros'—a specific verb (Lista) and resource (fornecedores cadastrados no OMIE). It distinguishes from sibling tools like '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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for listing suppliers with pagination and filters, but does not explicitly contrast with alternatives like 'consultar_fornecedor' for single-supplier lookups. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the destructive nature ('Exclui') and the open-title constraint, which are useful. However, it lacks details about irreversibility, required permissions, or effects on related records, leaving significant behavioral gaps for a delete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the primary action and the conditional scope. 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description is too thin. It does not explain how to identify the target, what happens after deletion, or any return/error behavior, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 either parameter. The two parameters (codigo_lancamento_omie and codigo_lancamento_integracao) are the sole means of identifying the target, and the description gives no guidance on which to use or that at least one is required, leaving the agent unable to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Exclui uma conta a pagar do OMIE') with a specific verb and resource, and includes a scope delimiter ('apenas títulos em aberto') that distinguishes this from related tools like consultar_conta_pagar or 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys a clear condition for use ('apenas títulos em aberto'), implying that closed or paid titles should not be deleted via this tool. It does not explicitly name alternatives, but the open-title restriction provides usable guidance for when to apply 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 of behavioral disclosure. It does add useful context by disclosing that OMIE auto-generates the group code ('1.xx' for receita, '2.xx' for despesa) and returns it in 'codigo'. However, it omits other behavioral aspects like permission requirements, idempotency, or error handling, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences), front-loaded with the primary action, and every word adds value. It introduces the core function, clarifies the group's role in the hierarchy, and notes the auto-generated code behavior without any wasteful filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple create operation with 3 parameters and no output schema or annotations, so the description must compensate. It explains the purpose and the auto-generated code, but it fails to define what 'tipo_grupo' or 'natureza' mean, what valid values they accept, or how they relate to the revenue/expense distinction. This leaves significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 parameters (descricao, tipo_grupo, natureza). It only mentions the auto-generated 'codigo' output, which is not a parameter. The description offers virtually no help in understanding what values to provide for each parameter, leaving the agent to guess from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 'grupo totalizador de categorias' (a totalizing category group), which is distinct from creating a simple category (incluir_categoria). It uses a specific verb ('Cria') and resource, and explains the group's role as a future 'categoria_superior', effectively distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by explaining that the group is the level used as 'categoria_superior' for categories. This gives clear context that it is for parent groups, not individual categories. However, it does not explicitly name an alternative tool (like incluir_categoria) or state 'when not to use', so it falls short of a 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 transparency burden. It discloses that the tool lists only unsettled titles and that only one type can be processed per call, which is useful. However, it does not mention read-only behavior, pagination, or any filters beyond tipo, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences. It front-loads the core purpose and immediately follows with the essential usage constraint. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, yet the description only covers the 'tipo' parameter. It lacks details on pagination, filters, result format, or behavior with null values, making it incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies the 'tipo' parameter by specifying valid values (PAGAR or RECEBER), but it does not explain 'data', 'pagina', 'nome_cliente', 'codigo_cliente', or 'registros_por_pagina'. This leaves most parameters semantically unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing outstanding financial titles of a given type. It specifies the resource ('títulos financeiros em aberto') and the scope ('de um tipo'), and the explicit mention of PAGAR/RECEBER distinguishes it from sibling tools that focus on a single direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage instruction: one type per call, using PAGAR or RECEBER. However, it does not explicitly state when to prefer this tool over siblings like listar_contas_pagar or listar_contas_receber, leaving that comparison 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, the description carries the full burden of behavioral disclosure. It reveals that the tool searches both payables and receivables, but omits important behaviors such as pagination, filtering semantics, sorting, date range handling, or return format. This is a significant gap for a search tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler. The first sentence states the core action and scope, and the second provides practical guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 filter parameters and no output schema, the description is too thin. It does not describe pagination controls, available filters, or the shape of results. The sibling context clarifies its niche, but the description alone leaves the agent without enough information to use the tool confidently beyond basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not. It adds no details about parameter meaning beyond what the raw schema already shows. The mention of 'contas a pagar + a receber' hints at the 'natureza' parameter but does not explain any of the other filters or their acceptable values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Pesquisa' clearly indicates a search action, and the resource is specified as 'lançamentos financeiros' (financial transactions). The explicit scope 'unificada (contas a pagar + a receber)' distinguishes it from sibling tools like listar_contas_pagar and listar_contas_receber, which address each type separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Ideal para visão consolidada das finanças', providing clear context for when to use this tool: when a consolidated view of payables and receivables is needed. It implies the alternative of using separate list tools for each type, though it does not explicitly name alternatives 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose a non-obvious limitation (type change not allowed), which adds value beyond the schema. However, it omits other important traits such as permissions, error behavior, or reversibility, so it's only moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. It front-loads the primary action and adds a crucial caveat. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and undocumented parameters, the description is too sparse. It lacks parameter explanations, error conditions, and any return value details, making it incomplete for an agent to invoke correctly without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It indirectly explains 'natureza' by stating the type change restriction, but it says nothing about 'codigo' or 'descricao'. This is a significant gap, providing minimal semantic help beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Altera um grupo totalizador de categorias' (Alters a totalizer group of categories). This distinguishes it from sibling tools like 'alterar_categoria' by specifying the entity type ('grupo totalizador').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use (altering a totalizer group) and explicitly states a key exclusion: the tool cannot change the type (receita/despesa) of an existing group. This gives useful guidance on when not to use the tool, though it doesn't mention alternative 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 for behavioral disclosure. It discloses the mutating effect ('revertendo a baixa') but does not mention permissions, idempotency, side effects on associated records, or error conditions. This is a partial disclosure, adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The key distinction (identifies 'baixa', not 'título') is front-loaded, making the description efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a mutation tool with no annotations and no output schema, the description captures the essential purpose and input source. However, it omits guidance on parameter selection (both are optional in the schema) and result expectations, leaving gaps for an agent to properly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not name the parameters 'codigo_baixa' or 'codigo_baixa_integracao'. It only hints that the 'baixa' code is the identifier, leaving ambiguity about which parameter to use and their relationship. The description inadequately compensates for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cancels/reverses the receipt of an accounts receivable and reverts the write-off, with a specific verb ('Cancela/estorna') and resource ('conta a receber'). It distinguishes itself from siblings like 'lancar_recebimento' and 'cancelar_pagamento_conta_pagar' by explicitly clarifying it targets the 'baixa' (write-off), not the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating the tool identifies the 'baixa' returned by 'lancar_recebimento', guiding the agent on when to use it (to reverse a receipt) and what input to supply. It does not explicitly exclude alternative reversal tools, but the reference to 'lancar_recebimento' gives a strong contextual signal.
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 core behavior—comparing forecast vs actual across financial categories—but doesn't mention side effects, permissions, or return format. The read-only nature is implied by the name and 'consulta', 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with two required parameters and no output schema, the description is adequate: it explains what the tool does and the comparison logic. However, it could be more complete by noting what data is included (e.g., all categories) or that it is read-only, especially given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 references 'month' but doesn't explicitly explain the ano (year) and mes (month) parameters beyond their names, which are somewhat self-explanatory. The description adds context that the tool is for monthly cash flow, but not the expected formats/ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (query monthly cash flow) and resource (fluxo de caixa), with detail on comparing forecast vs actual by category. This distinguishes it from sibling consult tools like consultar_conta_receber or consultar_extrato_bancario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a monthly cash flow comparison) but provides no explicit references to alternatives or exclusions among the many sibling tools. It gives clear context but no 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?
No annotations are provided, so the description carries the burden. It discloses the need for at least one identifier, which is not evident from the schema. However, it does not describe behaviors such as error handling, result format, or whether multiple identifiers are combined, and 'consulta' only implicitly conveys read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core purpose. Every word earns its place, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with no annotations and no output schema, the description is minimally viable: it states the goal and a key constraint. But it lacks guidance on choosing among the three identifiers, possible error/not-found behavior, and expected return content, leaving gaps for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 individual parameters beyond their self-explanatory names. It only says 'at least one identifier' without detailing precedence, formatting, or which identifier to prefer, adding little semantic value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Consulta detalhes de um fornecedor específico' (queries details of a specific supplier), which is a specific verb+resource combination. It differentiates from siblings like listar_fornecedores (listing) and incluir/alterar_fornecedor (create/update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Informe ao menos um dos identificadores' provides clear context that at least one identifier is required, which is useful because the schema lists all parameters as optional. However, it does not explicitly mention when not to use the tool or point to alternatives like listar_fornecedores for broader searches.
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 indicates a read-only query operation and adds context about the included 'dadosDRE' field, but it does not describe the return type, error behavior, or required permissions, leaving some ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every part adds value: the action, the resource, the identifying parameter, and the specific linked data included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), so the description covers the core purpose and a key part of the response ('dadosDRE'). However, with no output schema, the description is incomplete regarding the full set of returned details and does not address not-found or error scenarios, which a fully transparent description would include.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'codigo' as a required string; the description adds meaning by stating the category is identified 'pelo código' (by code), clarifying how the parameter is used. While it does not detail format or constraints, for a single parameter this is a meaningful enhancement over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta') and resource ('categoria pelo código'), clearly stating the tool's function: query details of a single category by its code. It also mentions the inclusion of linked DRE account data, which distinguishes it from sibling tools like listar_categorias (listing all categories) or incluir_categoria/alterar_categoria (mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving one category's details by code, providing clear context for its primary use. However, it does not explicitly mention alternatives or cases where another tool (e.g., listar_categorias) would be more appropriate, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a non-obvious error behavior: for a non-existent code, OMIE returns 'Código do banco não informado na tag [codigo]' instead of saying the bank doesn't exist. This is a significant behavioral warning. It also indicates the output contains integration fields, though it doesn't cover response format or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff: purpose and output fields, use case, and error warning. All sentences add value and the description is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, a use case, and a critical error handling note, which is good for a simple lookup tool. However, without an output schema, it doesn't describe the response structure, and it leaves the input parameter format ambiguous. 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'codigo', with no description (0% schema coverage). The description only says it queries 'pelo código', which adds little beyond the parameter name. It doesn't specify the code format, provide examples, or clarify if it's the bank number, ISPB, etc. The integration details listed are output fields, not input guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a financial institution by code ('Consulta uma instituição financeira pelo código') and lists the integration details returned (obank_*, cnab_*, cwr_*, cod_ispb, cod_compen). This distinguishes it from sibling tools like listar_bancos, which lists all banks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: checking if a bank supports automated statements or collection before configuring a checking account ('Útil para saber se um banco suporta extrato ou cobrança automática...'). It doesn't explicitly name alternative tools or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return result (all transactions and balance) and the OMIE requirement for an account code. However, it does not mention behavior like date format expectations, pagination, potential errors when neither code is provided, or the meaning of exibir_apenas_saldo.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and contains no filler. Every sentence adds value: purpose, return content, and parameter prerequisite/discovery.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with no output schema, the description covers the main use case, return values, and required parameter alternatives. It falls short only on minor details like date format and the exibir_apenas_saldo flag, but overall it is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 clarifies the purpose of codigo_conta_corrente and codigo_integracao_conta (alternatives, one required) and how to obtain them. It only vaguely ties data_inicio/data_fim to 'período' and does not explain exibir_apenas_saldo, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Consulta'), the resource ('extrato bancário de uma conta corrente'), and the scope ('em um período'), plus the return content ('todos os lançamentos e o saldo do período'). It distinguishes itself from sibling tools like consultar_conta_corrente by focusing on the statement/transactions over a period.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions: inform one of the two account codes because OMIE requires one, and use listar_contas_correntes to discover the code (nCodCC). It does not explicitly contrast with alternatives like listar_lancamentos_bancarios, but the requirement and prerequisite are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly implies a read operation ('Obtém') and importantly discloses the single-day calculation quirk, which is a non-obvious behavioral trait. It lacks detail on permissions or errors, but this is adequate for a simple read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The main purpose is stated first, followed by a necessary caveat. Every word contributes value, and the structure is clean and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return contents (totals of payables, receivables, bank balance) and the single-day limitation, which is useful. However, the two boolean parameters could significantly alter the output and are undocumented. Since there is no output schema, this is a meaningful completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 provides meaning for the 'data' parameter via 'data de referência'. The boolean parameters 'apenas_resumo' and 'exibir_categoria' are entirely unexplained, leaving the agent without guidance on their purpose or effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Obtém' clearly indicates retrieval, and the resource 'resumo financeiro consolidado' is specific. It enumerates included components (contas a pagar, a receber, saldo bancário), which distinguishes it from sibling tools that list individual financial items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The note that OMIE calculates the summary for a single day (not a period) provides a clear contextual limitation, implicitly telling the agent not to use this for date-range queries. However, it does not explicitly name alternatives such as consultar_fluxo_caixa, so it falls short of a 5.
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 provided, the description carries the full burden and does well: it explicitly states the API is read-only ('somente leitura'), describes the returned fields ('codigo', 'nome', 'tipo'), and discloses that the table is maintained by OMIE. It also reveals that the 'nome' filter is a server-side partial search, adding behavioral insight beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. Every sentence adds value: the resource being listed, usage guidance about filtering, the return field structure, and the read-only nature. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is fairly complete: it explains the tool's purpose, suggests filtering, lists the return fields, and clarifies read-only behavior. The main gap is the lack of explanation for the 'tipo' filter values and pagination parameters, but for a simple list tool this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains the 'nome' filter (partial search) and implies pagination ('em vez de paginar tudo'), but it does not explain the 'tipo' parameter or the exact semantics of 'pagina' and 'registros_por_pagina' beyond what their names and defaults suggest. This is a partial but not complete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Lista os bancos e instituições financeiras do OMIE' (lists banks and financial institutions), with a specific resource and context. It also distinguishes itself from sibling tools by explaining that this table is the source of bank codes for checking account registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage guidance: because the base has over 1,200 institutions, users should filter by 'nome' rather than paginating through everything, and notes that OMIE performs a partial match. It does not explicitly name alternative tools (e.g., 'consultar_banco' for single lookups), so it misses the 'when-not-to-use' aspect.
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 full burden. It discloses the response item structure (cCodigo, cDescricao, cGrupo, cTipo) and important compatibility rules between cTipo and the category code prefix, which is beyond a simple 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a clear structure. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the return structure and domain constraints. It lacks explicit pagination behavior but the schema parameters imply it, making it reasonably complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the parameter names (pagina, registros_por_pagina) and defaults are self-explanatory. The description does not add any extra context for parameters, but they require little clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists category types, specifically the accepted values for `tipo_categoria` when including or altering a category. It's a specific verb+resource and distinguishes from siblings like listar_categorias and listar_grupos_categoria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: before including or altering a category, to know accepted values for `tipo_categoria`. It does not explicitly exclude alternatives or name them, but the context is clear enough.
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?
It discloses the core behavior (reverts the baixa) and clarifies that the identifier is the baixa, not the título. No annotations are provided, so the description carries the full burden; it adds meaningful context but does not cover potential side effects or prerequisites like permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two concise sentences, each with clear purpose: the first states the action, the second clarifies the input identifier. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the description covers the main operation and input. However, it lacks parameter semantics and return value details, which are relevant given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two undocumented parameters with 0% description coverage. The description only states that the tool identifies the baixa, providing minimal context for the parameters, and does not differentiate 'codigo_baixa' from 'codigo_baixa_integracao'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Cancela/estorna o pagamento') and the resource ('conta a pagar'), and clarifies the effect ('revertendo a baixa'). It distinguishes itself from sibling tools like 'cancelar_recebimento' by focusing on accounts payable and the baixa identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to identify the 'baixa' returned by 'lancar_pagamento' rather than the 'título', providing a clear when-not rule. This guidance helps the agent select the right input and avoid confusion with other 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?
No annotations are provided, so the description carries the burden. It discloses the exact-match behavior, which is useful. However, it does not mention return format, error cases, or explicitly confirm read-only nature, though 'consulta' implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The primary purpose is stated first, followed by an alternative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description provides essential usage guidance and an alternative path. It omits details about return value, but the simplicity and sibling context mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for `codigo`, and coverage is 0%. The description compensates by stating 'código exato', clarifying the parameter must be an exact code. It also indirectly explains how to discover the code via the sibling tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a document type by exact code, using a specific verb and resource. It distinguishes itself from sibling listar_tipos_documento by emphasizing exact code lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use `listar_tipos_documento` with the `descricao` filter when the code is unknown, providing clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that OMIE validates links and rejects inclusion if they don't close, details specific constraints for parameters, and lists return fields (codigo_status, descricao_status, codigo). It lacks mention of permissions or side effects but sufficiently reveals the tool's validation and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, bullet points for validation rules, and a closing return-value note. It is slightly long but each sentence carries useful information, making it appropriately concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given minimal schema, no annotations, and no output schema, the description fully covers what the tool does, when to validate, how parameters interact, and what to expect in the response. It is complete enough 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description compensates by adding detailed semantics for three parameters (categoria_superior, tipo_categoria, codigo_dre) including validation rules and related tools. The remaining parameters (descricao, natureza) are not explained beyond their names, but descricao is self-evident and natureza is optional, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Cria uma nova categoria financeira no OMIE' (Creates a new financial category in OMIE), which is a specific verb and resource. It distinguishes this tool from siblings like alterar_categoria and incluir_grupo_categoria by focusing on creating a financial category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit validation prerequisites and directs the agent to use sibling tools (listar_grupos_categoria, listar_tipos_categoria, listar_contas_dre) for checking links. However, it does not explicitly state when to prefer incluir_grupo_categoria over this tool or when not to use it, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool scans the category plan because OMIE lacks a native filter, and it describes the exact inclusion criteria (totalizadora = S, 4-character code in '9.99' format). This goes beyond a simple 'lists categories' statement, though it doesn't mention potential performance or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately front-loaded with the purpose, and every sentence contributes useful information. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is complete: it states the purpose, the exact context for use, the source data, and the filtering criteria. An agent can invoke this tool and interpret the result without additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on output semantics rather than parameters, which is appropriate. No param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Lista os grupos totalizadores de categoria' (lists the totalizing category groups) and immediately distinguishes it from siblings by noting it returns exactly the accepted values for `categoria_superior` when creating a category. This specific verb + resource + purpose makes it easy for an agent to know what this tool does and how it differs from listar_categorias or listar_tipos_categoria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: when you need the valid values for `categoria_superior` when creating a category. It also explains that OMIE doesn't offer a filter, which justifies its existence. However, it doesn't explicitly mention alternatives or when not to use it, so a small gap remains.
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 explicitly states the API is read-only for this table, discloses that it has 13 records and fits on one page (no pagination), and explains the output fields. This adds meaningful behavioral context beyond the structured 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences front-load the main purpose, include helpful examples, and add details without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers purpose, output fields, group semantics, read-only nature, and scale. It is complete for the agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so there is nothing to describe. The description compensates by explaining the meaning of output fields (cCodigo, cDescricao, cGrupo) and the group code domain, which helps the agent interpret results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists current account types from OMIE, specifically the accepted values for the type field. It distinguishes from siblings like listar_contas_correntes by focusing on types rather than accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use these values (when registering a current account) and references the same domain as listar_bancos, giving clear context. It does not explicitly name alternative tools but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it is not paginated, returns the entire structure in 'dreLista', lists all returned fields with meanings, and explains level semantics. It also notes the read-only limitation, providing comprehensive behavioral context beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding necessary information: purpose, response shape, level semantics and filter usage, and read-only note. It is front-loaded with the main purpose and avoids fluff, making it both concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers the essential aspects: it explains what is returned, the meaning of levels, the availability of a filter for other operations, and the read-only constraint. This is sufficient for an agent to select and invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only explains 'apenas_vinculaveis' (for getting valid codes for other tools), while leaving 'apenas_ativas' unexplained. The schema provides only titles and defaults, so the description adds some value but does not fully compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lista a estrutura de contas do DRE', clearly identifying the tool's function. It further distinguishes itself by specifying the non-paginated nature and the detailed fields returned, setting it apart from sibling listing tools like listar_categorias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use apenas_vinculaveis=True para obter direto os códigos válidos em incluir_categoria/alterar_categoria', directly telling when to use the filter. It also states the API is read-only for DRE, implying it should not be used for modifications, which is a clear when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the endpoint returns ~290 records, has no server-side filter, applies filter/limit in memory, reports total_encontrado before cutoff, and is strictly read-only with no mutation operations. This is thorough and helps the agent predict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states purpose and examples, the second paragraph explains operational behavior and limits, and the third clarifies read-only status. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with two simple parameters and no output schema, the description covers all essential aspects: what is listed, how filtering/limiting works, the meaning of total_encontrado, and the externally maintained read-only nature. It is complete enough for safe and effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the mechanics behind the parameters: 'filtro e o limite são aplicados aqui' and 'corte por limite'. It specifies that `limite` truncates results and `total_encontrado` reflects matches before that cutoff. It does not detail exact matching rules for `descricao`, but it provides meaningful context beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Lista os tipos de documento do OMIE' — a specific verb and resource — and immediately explains the practical use case (codes used when posting accounts payable/receivable and bank entries). Concrete examples (BOL, NF, ADI) further disambiguate the tool from sibling listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly establishes that this tool lists all document types and that server-side filtering is unavailable, so filter/limit are applied locally. It does not explicitly name alternative tools like consultar_tipo_documento, but the context is sufficient for an agent to distinguish a bulk-list use case from a lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses partial update behavior ('Apenas os campos informados são enviados'), validation rules for codigo and codigo_dre, and the workaround for deletion via inativar. This is rich behavioral context beyond basic 'update' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action, followed by critical behavioral notes. Each sentence serves a purpose: stating the operation, explaining partial updates, giving validation rules, and noting the inativar workaround. There is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter update tool with no output schema or annotations, the description covers the essential aspects: operation, field behavior, validation constraints, and deletion alternative. It doesn't specify return values or side effects, but those are often not crucial for an update operation. The cross-reference to incluir_categoria adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 0% of parameters in its descriptions, so the tool description must compensate. It does add meaning for codigo (prefix-based type rules), codigo_dre (DRE level constraints), and inativar (purpose as deletion workaround). natureza and descricao are not detailed, but their names and schema titles make them reasonably self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Altera uma categoria existente' (Alters an existing category), which clearly states the verb and resource. It further distinguishes itself from siblings like incluir_categoria by implying an update operation, and the title 'alterar_categoria' is self-reinforcing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly references incluir_categoria for binding rules, and importantly states that since there is no delete method, one should call this tool with inativar=True to remove a category from use. This provides clear guidance on when to use this tool over alternatives.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/lucassampsouza/omie-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server