Server Quality Checklist

Tool Scores

• resumo_antecipacoesC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to disclose whether this is a read-only aggregation, whether it covers historical data, current pending anticipations, or both, what currency/fee conventions apply, or what the output structure looks like. For a summary/report tool with zero annotations and no output schema, 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.

  Conciseness4/5

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

  The description is a single concise sentence that efficiently enumerates what the summary covers. No wasted words, clearly front-loaded with the core purpose. However, it is under-specified rather than economically specific, which slightly reduces the score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a summary/report tool with no annotations and no output schema. The description enumerates coverable fields (installments, fees, average days, daily breakdown), but it doesn't answer key questions an agent would need: what time period values are valid, whether it aggregates all payables or filtered entities, or what the output shape is. For a tool positioned among 11 financial siblings, it needs more specificity to guide correct selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters (inicio, fim) are documented as date strings in the schema. The description implies a date-range summary but adds no additional meaning about date format semantics (inclusive/exclusive), whether both are required for correct results, or what date range is valid. With full schema coverage, baseline 3 is appropriate.

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

  Purpose3/5

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

  The description states it's a summary of anticipated payments covering antecipated installments, fees, average days anticipated, and breakdown by receipt day. It gives a clear subject and scope but uses a vague verb ('Resumo de') rather than naming a specific action like 'list' or 'calculate'. It distinguishes from siblings by focusing on anticipations, but doesn't explicitly contrast with siblings like resumo_financeiro.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use or when-not-to-use guidance is provided. The description doesn't mention which scenarios call for this tool versus alternatives like resumo_financeiro or recebiveis_periodo. Users must infer usage solely from the French/Portuguese summary nature, and the differentiation from sibling tools is absent.

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

• listar_reembolsosB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether this filters by user/workspace, whether partial refunds are separated from total refunds in the output, whether pagination exists, how many results are returned, or what format the listed orders take. For a read-list tool, this is a notable gap.

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

  Conciseness4/5

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

  A single clear sentence in Portuguese that communicates the essential purpose and scope. Efficient and front-loaded with the verb and resource. Could be slightly improved by noting the read-only nature, but there's zero waste in the sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward 2-parameter date-range list tool with complete schema coverage and no output schema, the description is mostly adequate. However, given there are no annotations and no output schema, it could add value by describing what the returned list contains (order IDs? amounts? status flags for partial vs total?), which would help an agent interpret results correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — both 'inicio' and 'fim' have descriptions naming them as start/end dates with YYYY-MM-DD format. The description's mention of 'periodo' adds the scoping context (results restricted to the date range), aligning with the parameters. Baseline 3 is appropriate since the schema does the heavy lifting and the description doesn't add syntax beyond it.

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

  Purpose4/5

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

  The description states it lists refunded orders (total or partial) within a period — a clear verb (listar) plus resource (reembolsos/pedidos reembolsados) and scope (periodo). It partially distinguishes from siblings like fluxo_pedido by focusing on refunds, though the exact relationship to buscar_pedido could be clearer.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for listing refunded orders in a date range, which is reasonably clear context. However, it doesn't explicitly state when-not-to-use or name alternatives, nor does it mention differences from fluxo_caixa or recebiveis_periodo which might also cover refund/flow scenarios.

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

• recebiveis_periodoB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what data is returned (bruto, taxas, liquido, quantidade) but doesn't disclose whether this is a read-only operation, whether it triggers synchronization, performance implications, or pagination behavior. Given the sibling 'sincronizar_payables' exists, the agent can't tell if this tool reads cached data or syncs first.

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

  Conciseness4/5

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

  A single, efficient sentence that communicates the purpose and output fields without waste. It's front-loaded with the core action and follows with the result details. No unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a filtered-list/reporting tool with 3 fully-documented parameters and no output schema, the description is reasonably adequate. However, with no annotations and no output schema, it could benefit from stating whether results are ordered by date, whether 'data de recebimento' differs from the period filter dates, and what 'bruto/taxas/liquido' mean financially. The lack of any behavioral or output-format disclosure leaves some gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so all three parameters (inicio, fim, status) are documented in the input schema with format hints and the status default. The description adds the meaning of the output grouping (por dia, por data de recebimento) but doesn't add parameter-level nuance beyond what the schema provides. Baseline 3 applies since schema handles the descriptions well.

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

  Purpose4/5

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

  The description clearly states it shows receivables grouped by day within a period, returning gross, fees, net, and quantity per receipt date. The verb 'Mostra' + resource 'recebiveis' is specific. It somewhat distinguishes from siblings like recebiveis_futuros (future receivables) by specifying period-based daily grouping, though it doesn't explicitly contrast with them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for viewing daily-grouped receivable amounts in a period, and the required params (inicio, fim) establish a date range context. However, it doesn't explicitly state when to use this over recebiveis_futuros or fluxo_caixa, nor does it mention exclusions or alternative tools. The status parameter's filter options are in the schema but not reinforced with usage guidance.

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

• sincronizar_payablesB
  3.2/5.0
  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 explains the tool pulls data from Pagar.me and saves to SQLite, which gives some behavioral context. However, it doesn't disclose potential side effects (e.g., whether existing records are overwritten, whether this is destructive to local data, rate-limit concerns, or the time scope of the operation given 'dias'). The write-to-SQLite aspect is implied but not elaborated.

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

  Conciseness4/5

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

  Two sentences, front-loaded with the main action and then scope. Zero wasted words and conveys the core functionality efficiently. It's appropriately concise for a simple sync tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter sync tool with 100% schema coverage and no output schema, the description is reasonably complete for the core action. However, given zero annotations, it could benefit from noting side effects (overwrite behavior, idempotency) and return values since there's no output schema to document these. The absence of these details leaves some uncertainty for a mutating sync operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for the single 'dias' parameter, with a clear default and description in the schema. The tool description itself repeats the 'periodo' concept mentioned in the schema ('de um periodo'), matching the 'dias' parameter, but adds no new meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description states a specific verb+resource ('Sincroniza payables da Pagar.me para o banco local') and mentions the scope ('Puxa todos os payables de um periodo'). It's clear this pulls payables from an external source into a local database. However, it doesn't explicitly differentiate from siblings like 'sincronizar_shopify' or 'sincronizar_tudo', though the payables-specific focus is fairly distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives. There's an implicit sense it's for sync operations, but no explicit direction on when to prefer this over 'sincronizar_tudo' or other sync tools, nor any prerequisites mentioned (e.g., need for API credentials, prior configuration).

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

• fluxo_pedidoB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden of behavioral disclosure. It does disclose the local-DB-vs-API fallback behavior, which is useful, but it doesn't disclose whether this is a read-only operation, any auth/permission needs, or latency implications of API fallback. For a tool with zero annotation coverage, more context is needed.

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

  Conciseness4/5

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

  Two concise sentences, front-loaded with the primary purpose, ending with the data-source fallback note. No wasted words, though it could add alternative-tool differentiation without much length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, read-oriented view tool, the description covers the essence. However, lacking annotations and output schema, it would benefit from noting whether results include all historical parcels, any pagination/sorting, and clearer mutation-safety implications - leaving some gaps for a tool with no annotation safety net.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and there's only 1 required parameter ('pedido'). The description adds meaning by clarifying the parameter is a specific order number and that the response includes parcelas, taxas, and status - value beyond the schema's bare field description.

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

  Purpose4/5

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

  Description states specific verb ('Mostra') + resource ('fluxo de recebimento de um pedido especifico') and enumerates content (parcelas, taxas, datas, status). It's distinct from siblings like buscar_pedido (order lookup) and fluxo_caixa (cash flow), though it doesn't explicitly differentiate from them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implicitly conveys usage (when you want installment/settlement flow for a specific order), but provides no explicit when-to-use vs alternatives guidance or exclusions. The line about local DB vs API is a data-source note, not usage direction.

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

• conciliar_diaB
  3.4/5.0
  Behavior2/5

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

  No annotations, so description carries the burden. It lists output contents but doesn't disclose whether reconciliation writes to the local database or only reads. The cross-check with local bank implies possible writes but this is not stated.

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

  Conciseness5/5

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

  Two sentences, zero waste. The first sentence states the core function and key outputs; the second adds the charge-vs-local-database cross-check. Efficient and front-loaded with the verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is moderately complex (reconciliation across two systems with multiple output categories) and has no output schema. The description summarizes the output scope but doesn't specify return structure, how unmatched items are presented, or whether the operation has any written side effects. Acceptable for a simple single-param tool but leaves some gaps for a reconciliation workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the single param (data) is described as YYYY-MM-DD format in the schema. The description adds context that this is a day-scoped reconciliation, reinforcing the parameter's meaning without needing much elaboration. With one well-documented param, baseline 3-4 is appropriate.

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

  Purpose4/5

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

  Clear verb+resource: reconciles Shopify orders with Pagar.me charges for a day. Specifies what it shows (reconciled orders, installments fees, fees, net, unmatched orders). Somewhat distinct from siblings which focus on syncing, refunds, and financial summaries, though the reconciliation overlap with resumo_financeiro isn't explicitly differentiated.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies day-range usage ('de um dia') and the data parameter requirement. It mentions it crosses charges without orders against the local database, giving some context. However, it doesn't explicitly state when to use this vs alternatives like sincronizar_* or resumo_financeiro, and gives no exclusion guidance.

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

• fluxo_caixaB
  3.4/5.0
  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 aggregation granularity (daily, by payment day) and the content categories included, but doesn't mention response format, timezone assumptions, whether it spans a range endpoint-inclusive, or any rate/volume caveats. Adequate but not richly transparent for an unannotated financial reporting tool.

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

  Conciseness4/5

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

  Single compact sentence listing all content dimensions (entradas, saidas, taxas, antecipacoes, liquido) and grouping rule (por dia de pagamento). Zero waste and efficient for what it conveys. Not quite 5 since ordering/clarity of the many content items could be slightly improved with structural formatting.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no annotations, the description must fully explain behavior and return semantics. It lists the financial components and grouping but doesn't describe the output structure, totals behavior, or edge cases (e.g., days with no activity). For a financial reporting tool among many similar siblings, this is adequate but leaves room for more.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters (inicio, fim, dates in YYYY-MM-DD) are fully documented in the schema. The description adds the date-range framing context ('por dia de pagamento') which clarifies how the range is used. Baseline 3 is appropriate since the schema already handles parameter documentation.

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

  Purpose4/5

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

  The description states a specific resource (daily cash flow) with clear content scope: gross inflows, outflows (reversals/chargebacks), fees, advances, and net, grouped by payment day. It's clear and differentiates from siblings like recebiveis_periodo (period receivables) by focusing on daily cash flow aggregation. However, it doesn't explicitly contrast with sibling tools, so not a full 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The use case is implied via 'fluxo de caixa diario... agrupado por dia de pagamento' — it's clear this is for daily cash flow reporting. But there are no explicit when/when-not exclusions or alternative-tool guidance, despite a rich set of financial siblings (recebiveis_futuros, resumo_financeiro) that could cause selection ambiguity.

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

• sincronizar_shopifyB
  3.4/5.0
  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 what data is included (transactions, refunds, financial status) and the dual behavior modes, which is useful. However, it doesn't disclose idempotency, whether it overwrites local data, whether it creates duplicates, or auth requirements. For a sync/write operation with no annotation coverage, more behavioral context would be valuable.

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

  Conciseness4/5

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

  Two sentences, efficient and front-loaded with the core action. Each sentence adds value: the first states the purpose, the second states modes and coverage. No wasted words, though the structure could benefit from explicit paragraph separation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a sync tool with 2 params, full schema coverage, and no output schema, the description covers the core behavior and date logic. However, it's a state-changing sync operation with no annotations, and it doesn't address concurrency, return value, or failure semantics. Given no output schema exists, describing what the function returns would improve completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so both parameters (inicio, fim) are already documented in the schema. The description adds the behavioral context that omitting inicio uses the last 7 days of updates, which is genuinely additive. This slightly exceeds the baseline 3 for full schema coverage.

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

  Purpose4/5

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

  The description uses a specific verb+resource ('Sincroniza pedidos Shopify para o banco local') and clearly states scope (by period or recently modified). It mentions including transactions, refunds, and financial status, which adds specificity. It doesn't explicitly distinguish from similar synchronization siblings like sincronizar_payables or sincronizar_tudo, but the focus on Shopify orders is reasonably clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it ('sincronizar pedidos Shopify') and offers two modes (by period or recently modified). However, it does not explicitly address when NOT to use it or contrast with alternatives like sincronizar_payables (which likely syncs similar payables data). The guidance is clear in context but lacks explicit exclusions.

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

• buscar_pedidoA
  3.5/5.0
  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 indicates a read operation ('Busca informacoes') sourcing from a local database rather than Shopify directly, which adds useful context. However, it doesn't disclose return format, whether the data is cached/stale, or failure behavior when the order doesn't exist locally.

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

  Conciseness5/5

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

  Single sentence, front-loaded with the action, enumerates the retrieved fields efficiently. Zero wasted words while conveying the key scope (Shopify, local DB) and data categories.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple lookup tool with 1 parameter, 100% schema coverage, and no output schema, the description covers the essentials. However, it's ambiguous whether it includes refunds (reembolsos is listed as retrieved data but there's a dedicated sibling tool listar_reembolsos) and doesn't clarify the relationship with siblings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% — the single parameter (pedido) is described with an example format (#14328). The description confirms this is an order number but doesn't add meaning beyond the schema. With 100% coverage and only 1 parameter, baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the verb (Busca), the resource (pedido Shopify), and the specific data retrieved (cliente, valores, status financeiro, reembolsos, gateway). It doesn't explicitly differentiate from siblings like listar_reembolsos or fluxo_pedido, but naming the Shopify localization and local database provides reasonable scope distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is for looking up individual order information, but doesn't explicitly state when to use it versus alternatives like fluxo_pedido, listar_reembolsos, or resumo_financeiro. The Portuguese name and context suggest order lookup, but no explicit when/when-not guidance or alternative naming is given.

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

• recebiveis_futurosA
  3.5/5.0
  Behavior3/5

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

  The description discloses that it filters by waiting_funds status and groups by day. It presents a read-only informational view. With no annotations provided, the description carries the burden, and while it explains the filtering behavior, it doesn't state whether this is a safe read-only operation or any rate/performance characteristics.

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

  Conciseness4/5

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

  The description is a single sentence with a second sentence providing practical context. It is efficient and front-loaded with the core purpose. Slightly more could be said but it earns its place with minimal waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with an explanatory description, this is fairly complete. The 'waiting_funds' status filter and daily grouping are explained. However, it doesn't describe the output format or whether data is shown for a default time window (e.g., all time vs. a specific range), which could be ambiguous for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0 parameters, the baseline is 4 per the rubric. There is nothing to document beyond what's already in the schema, and the description correctly explains the default behavior (grouped by day, waiting_funds filter) since there are no parameters to configure.

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

  Purpose4/5

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

  The description clearly states the tool shows receivables with 'waiting_funds' status grouped by day. It uses a specific verb ('Mostra'/'Shows') with a clear resource (receivables grouped by day). It distinguishes itself from siblings like recebiveis_periodo by specifying the waiting_funds status filter and daily grouping.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives practical context ('Util para ver o que esta programado para cair na conta'), implying this is for viewing scheduled incoming funds. However, it does not explicitly mention when NOT to use it or name alternative tools like recebiveis_periodo, though sibling names suggest such alternatives exist.

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

• resumo_financeiroA
  3.5/5.0
  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 of behavioral disclosure. It lists what the summary contains (a useful aggregation detail), but doesn't disclose whether this is a read-only aggregation, whether data comes from cached/synced sources (relevant given 'sincronizar_*' siblings exist), or any side effects. The content breakdown is helpful but misses operational traits like freshness/currency of data.

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

  Conciseness4/5

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

  Single sentence, dense with information, no wasted words. The content list is efficiently enumerated. Could be more concise structurally but it's appropriately compact for the breadth of content it covers.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a summary/report tool with fully-described parameters (100% coverage) and no output schema, the description adequately enumerates the report's contents. The listed fields (entradas, saidas, taxas, antecipacoes, liquido, method/type breakdown) give a solid expectation of what's returned. Slightly more could be said about how the summary relates to other financial tools, but completeness is decent for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, meaning both parameters (inicio, fim) already have descriptions in the schema ('Data inicio (YYYY-MM-DD)'). The tool description adds no parameter-level meaning beyond what the schema provides. Per the baseline rule for >80% schema coverage, a 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the verb+resource scope: provides a 'resumo financeiro completo' (complete financial summary) for a period, listing exact contents (entradas, saidas, taxas, antecipacoes, liquido, operacoes, dias com movimento, method/type breakdown). The specificity of the listed fields distinguishes it from general tools, though it doesn't explicitly name a sibling it differs from.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for a date-period (inicio/fim) financial summary, which gives clear context. However, it doesn't explicitly say when to prefer this over siblings like 'fluxo_caixa', 'recebiveis_periodo', or 'resumo_antecipacoes'. With many financial sibling tools, explicit differentiation would be valuable but is absent.

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

• sincronizar_tudoA
  3.9/5.0
  Behavior3/5

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

  No annotations were provided, so the description carries this burden. It discloses the specific date ranges (30 days for payables, 7 days for Shopify) which is useful behavioral detail about scope. However, it doesn't disclose side effects, error behavior, rate limits, or what happens on partial failure. For a synchronization tool (mutation) with no annotations, more behavioral disclosure would be expected.

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

  Conciseness5/5

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

  The description is a compact two-sentence statement with zero wasted words. It front-loads the purpose and efficiently conveys the scope and equivalence to other tools. Every element earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter, no-output-schema, no-annotation tool, the description is reasonably complete: it states scope, date ranges, and the relation to sibling tools. It could note what the output/confirmation looks like after running, but overall it provides sufficient context for an agent to select and invoke it. The equivalence to the two individual syncs is valuable context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are 0 parameters and 100% schema coverage (naturally, since no params exist), so the schema requires no compensation. The description adds scope detail (date ranges for each system) beyond what an empty schema could convey. For a zero-parameter tool, the baseline is 4 and the description meets it by clarifying what exactly gets synchronized.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: it synchronizes Pagar.me payables (30 days) and Shopify orders (updated 7 days) in one action. It distinguishes from siblings by noting it's equivalent to running both 'sincronizar_payables' and 'sincronizar_shopify' tools together, giving specific verb+resource+scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies 'use this when you want both synchronizations at once' by stating it's equivalent to running both individual synchronizations. It doesn't explicitly state when NOT to use it (e.g., when you only need one sync), but the sibling tool names make the alternatives obvious and the context is reasonably clear.

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