mcp-server-efi

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Despite the large number of tools, descriptions are detailed and clearly distinguish each one's purpose. However, some Pix-related tools have very similar names that might cause initial confusion without careful reading, e.g., `pix_create_charge` vs `pix_create_immediate_charge` but descriptions resolve ambiguity.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (e.g., `create_charge`, `detail_subscription`, `pix_create_due_charge`). Minor exceptions like `pix_qr_code_pay` still match the pattern. This consistency helps an agent predict tool names.
Tool Count2/5
With 173 tools, the server far exceeds typical scopes. While the domain (payment gateway) is broad, many tools could be consolidated or the API could be more abstracted. The high number risks overwhelming agents and increases selection errors.
Completeness5/5
The tool set covers virtually all lifecycle operations for charges, subscriptions, carnets, Pix, Open Finance, and account management. It includes create, read, update, delete, settle, refund, webhook config, and reporting, leaving no obvious gaps for the domain.
Average 4.1/5 across 170 of 173 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true (mutation) and readOnlyHint=false. The description does not expand on behavioral traits such as whether the operation is reversible, what side effects occur, or any authorization requirements. It adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the key action. No wasted words. However, it could be structured with clearer separation of purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, nested schema, and many sibling tools, the description provides essential purpose and usage but lacks details on prerequisites (e.g., charge must exist in correct state) and side effects. Output schema likely covers return values.
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% with each parameter and subfield described. The description adds no extra meaning beyond the schema. Baseline of 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 tool's purpose: associating a payment method and payer data with a previously created transaction. It specifies the context (second step of charge) and the output (generates payment instrument). However, it does not explicitly distinguish from sibling tools like define_subscription_pay_method or define_link_pay_method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use para concluir a segunda etapa da cobrança' implies when to use it. However, no when-not-to-use or alternative tools are mentioned. Siblings like define_link_pay_method exist for similar purposes but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds no extra behavioral context, such as whether it overwrites existing metadata or if it requires specific authentication or permissions. It does not contradict annotations, but also does not supplement them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one clearly defines what the tool does, the other provides a usage guideline. No unnecessary words, and information is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to explain return values. However, it lacks information about prerequisites (e.g., charge must exist, status requirements) and the effect of updates on other fields, which would be helpful for a destructive mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description mentions 'referência própria' and 'URL de notificação', which correspond to the schema parameters custom_id and notification_url. Since schema coverage is 100% and the schema already describes these parameters, the description adds no additional semantic value beyond what the schema provides.
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 updates integration metadata of an existing charge, specifically referencing custom_id and notification_url. It distinguishes from sibling tools like update_charge_link or update_carnet_metadata by focusing on metadata fields, but could be more explicit about which tools 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 provides an explicit use case: 'Use para corrigir o vínculo com o sistema integrador.' However, it does not mention when not to use this tool or suggest alternatives among the many sibling update tools, leaving usage guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is a write operation (readOnlyHint=false). The description adds that each parcel can be tracked separately, which is useful but not critical. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with the main purpose. Every sentence adds value, though it could be more structured with bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, many siblings), the description is minimal. It explains creation but lacks details on return values or process, though output schema may compensate. Adequate but not rich.
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%, but many parameter descriptions are generic and not informative. The tool description does not add further parameter details. 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?
Description clearly states it creates a carnet with multiple installments for the same payer. It distinguishes from other tools by emphasizing batch periodic charges, but does not explicitly mention sibling tools like create_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage scenario: 'Use when the sale requires periodic charges already defined in batch.' However, it does not specify when not to use or list 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?
Annotations already indicate write, non-idempotent, and destructive behavior. The description adds that it 'submits' the charge, implying an action that will charge the customer, but does not disclose additional traits like side effects, error conditions, or idempotency specifics beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that fronts the purpose. It is concise, though could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, many siblings), the description is brief. It relies on annotations and output schema for completeness, but could better address when to choose this over similar tools like create_one_step_charge.
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 the schema already documents each parameter. The description adds no specific parameter meaning beyond the overall context, meeting the baseline for high 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 clearly states the tool creates and submits a credit card charge. It specifies the resource and action, but does not explicitly distinguish from sibling tools like create_one_step_charge or create_charge, leaving some ambiguity about when to use this specific route.
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 advises use when a payment token and required data are available, providing a usage condition. However, it lacks explicit exclusions, alternatives, or when-not-to-use guidance, limiting its help for an agent comparing multiple charge tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds context about 'authorization journey' but does not elaborate on behavioral traits such as permission requirements, side effects, or error conditions beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and provide a use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema and presence of an output schema, the description is adequate but does not explain return values, error states, or the overall workflow beyond a brief mention of 'authorization journey'.
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 the schema already documents parameters fully. The description adds no additional parameter-level meaning, earning the baseline score of 3.
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 initiates a series of recurring Pix payments via Open Finance ("Solicita a iniciação de uma série de pagamentos Pix recorrentes") and mentions creating an authorization journey. It distinguishes itself from listing or canceling tools, but does not explicitly differentiate from siblings.
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 a use case ("Use para criar a jornada de autorização de pagamentos programados") but lacks explicit guidance on when not to use the tool or mention of alternatives like of_list_recurrency_pix_payment or of_cancel_recurrency_pix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description uses the term 'revisar' (review), which understates the destructive nature indicated by the annotation destructiveHint=true. It does not disclose potential side effects, such as cancellation or irreversible changes, nor explain what 'state still allows modification' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently conveying purpose and usage condition without unnecessary words. It is front-loaded with the action 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?
Given the presence of an output schema, the description does not need to explain return values. However, the tool is destructive and has complex parameters; the description could include more details on prerequisites or consequences to be fully complete.
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 the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions, which are already in Portuguese and sufficiently detailed.
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 reviews allowed fields of an Automatic Pix recurrence and adjusts an existing agreement. It specifies the resource (Pix Automático recurrence) and the action (revisar campos), distinguishing it from creation or detail tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a condition for use: when the existing agreement needs adjustment and its state still allows modification. This gives clear context, though it does not explicitly name sibling tools or 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?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds context that the operation modifies the charge and is contingent on the billet's state. This is useful but does not disclose additional behavioral traits like authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that cover purpose and usage context. It is front-loaded with the main action, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values. However, it does not fully specify what fields are modifiable beyond the implied 'expire_at' from the schema. The state condition is mentioned, but the tool's overall impact could be clearer.
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 the baseline is 3. The description does not add meaning beyond the schema's property descriptions. It uses the vague phrase 'dados permitidos' without listing which parameters are involved.
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 that it reviews (updates) allowed data of a billet associated with a charge. The verb 'Revisa' is somewhat vague but the context of updating is clear. Among siblings, it distinguishes itself as the only tool explicitly for updating a billet.
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 tells when to use the tool ('while its state allows change'), but does not specify when not to use it or provide alternatives. It implies the use case 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write, non-destructive operation (readOnlyHint=false, destructiveHint=false). The description adds that the enrollment requires an authorization journey, which is useful context. However, it does not disclose whether the operation is synchronous or asynchronous, or describe error states. Given annotation coverage, the description adds some value but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no redundancy. The first sentence states the purpose directly, and the second provides usage context. It is well-structured for quick agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested schema and many siblings, the description is adequate but sparse. It covers the essential purpose and prerequisite, but does not summarize key required fields or the output schema. The input schema's fullness compensates partially, but the description could be more informative for an agent navigating many options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the description does not need to add details. It does not elaborate on parameter semantics beyond the overall purpose, meeting the baseline but not adding extra value.
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 identifies the tool's action (creating an enrollment) and resource (automatic payments via Open Finance). It partially distinguishes from siblings by noting it is a prerequisite for starting payments, but does not explicitly contrast with update or list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context ('Use before starting payments of this modality') and mentions the authorization journey. However, it does not specify when not to use this tool nor explicitly contrast with sibling tools like of_update_automatic_enrollment or of_list_automatic_enrollment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false; the description adds only 'a operação pode movimentar recursos', which repeats the destructive nature without further detail on side effects, authorization, or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a short instruction, with no wasted words. It effectively communicates the core purpose and precondition in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested parameters, Open Finance context), the description is too sparse. It omits details about the relationship between parameters, the meaning of 'pagamento' fields, and the flow of the automatic enrollment process. The output schema exists but the description lacks complementary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the parameter descriptions are generic and redundant (e.g., 'Valor do campo...'), adding no meaningful semantics beyond the schema. The tool description does not compensate by clarifying the purpose of parameters like 'identificadorAdesao' or 'pagamento'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates an automatic Pix payment backed by a pre-authorized enrollment. It specifies the verb 'solicitar' and the resource 'pagamento Pix automático', distinguishing it from other payment tools that require different prerequisites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool after validating enrollment, receiver, and amount, and warns that it moves funds. While it does not explicitly list alternatives or when not to use, it provides sufficient context for correct invocation among similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is destructive (destructiveHint=true) and not read-only. The description adds that the charge must be in a state that admits alteration, which is useful but not detailed. It does not contradict annotations, but the description could better convey that the operation effectively cancels the charge (status must be 'CANCELADA').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, each serving a clear purpose: defining the tool's function and providing usage context. No unnecessary words, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers the basic function. However, it does not explicitly state that the tool only cancels automatic charges, nor does it specify the required charge state or consequences of cancellation. This lack of detail could lead to misuse, making it only moderately complete.
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?
Both parameters have schema descriptions (txíd and status), providing sufficient context. The description does not add extra meaning beyond the schema. With 100% schema coverage, a score of 3 is appropriate as the parameters are well-defined but the tool description offers no additional semantic value.
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 that the tool reviews and adjusts allowed fields of a Pix Automatic charge, and it is used to modify the recurring charge while its state permits. This distinguishes it from sibling tools like 'pix_create_automatic_charge' and 'pix_detail_automatic_charge'. However, it could be more explicit that the only allowed modification is cancellation, as hinted by the schema.
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 advises using this tool to adjust the recurring charge when its state allows alteration, which provides some contextual guidance. However, it does not specify when not to use it, nor does it mention alternative tools for other modifications (e.g., creating or detailing charges). The guidance is adequate but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description mentions create or update, which implies potential modification. However, it does not detail what happens to existing configurations, whether the operation is idempotent, or any side effects. The description adds some context but not enough for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and followed by a usage hint. Every sentence adds value with no unnecessary words. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and a key prerequisite, but it omits details about the output schema (which exists) and does not explain the two body alternatives. For a simple create/update tool, it is mostly complete but could provide more context on parameter structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description does not explain the two alternatives in the body schema (anyOf), nor does it add meaning beyond what the schema already provides. The schema itself has some confusing descriptions (e.g., 'not' fields), but the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates or updates a webhook configuration for account opening events. However, it does not explicitly differentiate from similar sibling tools like pix_config_webhook or pay_config_webhook, which could confuse the agent when selecting the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('após preparar o endpoint com a segurança exigida') and a use case ('para acompanhar o onboarding'), but it does not specify when not to use this tool or mention alternatives. The guidance is implied 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description states 'remove sua configuração', which confirms destruction but adds no further behavioral details (e.g., effect on existing subscriptions). It is consistent but not additive beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and include a usage hint. Every word contributes value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool, the description covers the core action and usage context. However, it does not mention what happens to subscriptions linked to the plan or any return value. Since an output schema exists (not shown), the return format may be documented there, so this is acceptable.
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% with one required parameter 'id' described as 'Identificador do recurso.' The description does not add any semantic meaning beyond the schema, so it meets the baseline without improvement.
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 'Exclui um plano de assinatura existente' which clearly identifies the verb (delete) and resource (plan). The conditional phrase 'quando a Efí permitir a remoção' slightly muddles clarity but still conveys the main purpose. Among sibling tools, this is distinct as the only plan deletion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use apenas se o plano não deve mais receber novas assinaturas', providing explicit context for when to use. However, it does not mention alternatives (e.g., update_plan) or when not to use it, leaving gaps in decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint, openWorldHint, and idempotentHint to true. The description reinforces the read-only nature by stating 'sem modificar seus estados', adding some value. No additional behavioral traits (e.g., rate limits, auth) are disclosed, but annotations cover the main safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no unnecessary words. First sentence states purpose and scope, second sentence provides usage guidance. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many parameters, many sibling tools) and the existence of an output schema, the description covers the essential purpose and usage context. It lacks details about pagination behavior or default sorting, but these are partially addressed by the schema and output schema. Overall adequate for an agent to understand when and how to use it.
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 the schema already explains each parameter. The tool description does not add extra meaning or nuance beyond what the schema provides, nor does it explain interactions between filters.
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 'list' and resource 'charges' and provides specific use cases (reconciliation, monitoring, locating transactions). It implicitly differentiates from sibling tools like pix_list_charges by focusing on 'cobranças' (billet, carnet, subscription, card) rather than PIX charges, but it does not explicitly name alternatives.
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 advises use for reconciliation, monitoring, and locating transactions without modifying states, which gives clear context. However, it does not specify when not to use the tool or provide alternative tools for other purposes (e.g., modification tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description reinforces that charges are not modified, but it does not add details about pagination, rate limits, or other behavioral aspects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, and contains no redundant information. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations (readOnly, idempotent) and an output schema, the description is mostly complete for a list tool. It lacks explicit mention of pagination behavior, but the schema includes pagination parameters, mitigating the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description does not add extra meaning to specific parameters beyond the schema. Baseline 3 is appropriate since the schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists charges associated with Pix Automático recurrences using filters, specifying the verb 'list' and resource. It provides use cases (monitoring and reconciliation) but does not explicitly differentiate it from sibling list tools like pix_list_charges or pix_list_due_charges.
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 advises using the tool for monitoring and reconciliation without modifying charges, implying a read-only use case. However, it does not provide explicit guidance on when to use it vs alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds 'sem modificar suas associações' reinforcing read-only nature. No contradiction, but no extra behavioral details beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences front-load purpose and usage. Every word adds value with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested params, output schema exists), the description is adequate but doesn't explain return format, pagination behavior, or what a 'location' is. Output schema may compensate, but textual cues are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but parameter descriptions are generic placeholders (e.g., 'Valor do campo “inicio” usado na entrada da operação'). The tool description adds no additional meaning or format guidance for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists locations for automatic Pix recurrences, specifying the resource and verb. It uses 'Lista locations destinadas a recorrências de Pix Automático' and distinguishes from siblings like pix_list_recurrence_automatic by focusing on locations.
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 says 'Use para localizar e acompanhar payloads recorrentes sem modificar suas associações', indicating when to use (read-only observation). However, it does not explicitly mention when not to use or name alternatives like detail or unlink tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly and non-destructive. The description adds value by explicitly stating async generation and that the response includes a process identifier to track progress, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no filler, efficiently conveying the core purpose and usage. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested input schema and many sibling tools, the description is minimal. It does not explain how to select tipoRegistros fields or the specific return format, though output schema exists. More context would help.
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% with descriptions for all parameters. The tool description does not add additional parameter meaning beyond the schema, so 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 the tool requests async generation of a Pix reconciliation report, which clearly indicates the action and resource. It does not explicitly distinguish from sibling tools like detail_report, but the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a usage scenario ('consolidate transactions for verification') but does not mention alternatives or when not to use. Sibling tools include detail_report for checking status, but no contrast is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, and the description adds that its conclusion can move values ('sua conclusão pode movimentar valores'), which aligns. However, it doesn't elaborate on other behavioral aspects like authorization steps or potential side effects, so it adds only marginal context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, no wasted words, and front-loads the core purpose. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, high parameter count) and the presence of an output schema, the description could benefit from mentioning the output or the authorization journey flow. It is adequate but leaves gaps about what happens after initiation.
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 the baseline is 3. The description does not provide additional meaning beyond what the schema already documents, such as explaining the structure of nested objects or the significance of specific fields like 'idParticipante'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: initiating an immediate Pix payment via Open Finance and producing the corresponding authorization journey. It uses a specific verb ('Solicita a iniciação') and resource, distinguishing it from sibling tools like 'of_start_schedule_pix_payment'.
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 a hint about when to use it ('Use após definir o pagamento'), but does not explicitly mention when not to use it or provide alternatives like scheduled or recurring Pix payments. Without contrasting with siblings, the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds no further behavioral details, such as whether the webhook replaces an existing one or requires authentication. It does not contradict annotations but adds minimal value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that efficiently convey purpose and usage without superfluous words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple webhook configuration tool with annotations and an output schema, the description covers purpose and usage. However, it lacks details on behavioral effects (e.g., destructive overwriting) and verification steps, leaving some gaps in contextual 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 coverage is 100%, so the schema already describes the parameters. The description only mentions 'URL' generically without adding meaning beyond the schema's 'Endereço eletrônico usado pela operação.' This meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Configura a URL que receberá atualizações sobre pagamentos de contas', specifying the action (configures URL) and domain (bill payments). It distinguishes from sibling webhook tools like pix_config_webhook by focusing on 'pagamentos de contas'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use após preparar o endpoint de callback seguro para acompanhar mudanças de estado', providing a clear prerequisite. It does not mention when not to use or alternatives, but the context is sufficient for the agent to understand the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by noting that it moves account balance, which is a key behavioral insight. Annotations already indicate destructive and idempotent nature, so the description complements well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the schema with nested objects and an existing output schema, the description is brief and does not explain the different favorecido variants or idempotency. It is adequate but could be more complete for a complex financial transaction.
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 the description does not need to repeat parameter details. It mentions the identifier parameter correlating to idEnvio, but adds little semantic value beyond that.
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 initiates a Pix transfer using a sending identifier. However, it does not explicitly differentiate from similar sibling tools like pix_send_same_ownership, though the identifier usage is distinctive.
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 advises to verify payer, beneficiary, and value before use, which is a usage guideline. However, it does not specify when to use this tool over alternatives or include exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint as true and idempotentHint as true. The description adds valuable context about checking the effect on linked subscriptions, which goes beyond the annotations. However, it omits other behavioral details like reversibility or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose concisely, the second provides essential usage guidance and a warning. Every sentence is efficient and front-loaded without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. The description covers purpose and a key warning about linked subscriptions, but it does not mention prerequisites (e.g., valid plan ID) or clarify that only 'name' is updatable, leaving some gaps for 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 the input schema already explains each parameter. The description does not add any additional meaning or usage tips for the parameters, resulting in adequate but not enhanced semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing subscription plan's allowed data and mentions reviewing recurrence configuration. However, 'allowed data' is vague and the input schema only shows a 'name' field, so it's not fully specific about what can be updated.
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 advises checking effects on linked subscriptions before altering, implying caution. It does not explicitly state when not to use this tool or suggest alternatives, such as create_plan or delete_plan, though the context of sibling tools provides some distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds behavioral context by specifying that the tool does not modify event reception and confirms specific fields (URL, creation date). However, it doesn't disclose other behavioral aspects like response size or pagination. Given the strong annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the action and resource, then provide usage guidance. Every sentence earns its place; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is functionally complete given the presence of an output schema and strong annotations. It covers the purpose, usage context, and safety (non-modification). It doesn't explicitly describe the return structure, but the output schema likely covers that. A minor gap is that it doesn't mention what happens if the webhook doesn't exist, but that's acceptable. Score 4.
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%, with clear descriptions for the required parameter. The tool description does not add additional parameter semantics beyond what the schema already provides, so the default score of 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 tool's action (query a webhook configuration by identifier) and its purpose (confirm URL and creation date without modifying event reception). It distinguishes from sibling webhook tools by specifying 'account opening' context, though it doesn't explicitly contrast with other detail webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the use case: to confirm URL and creation date without modification. This guides the agent to use it for read-only verification. However, it does not explicitly list when to avoid this tool or suggest alternatives, such as using list or config webhook tools when a different operation is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=false. The description's 'Cria' confirms creation but adds no additional behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence states action, second gives usage condition. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage and output schema, the description lacks explanation of the 'id' parameter and differentiation from other one-step tools like create_one_step_charge. Minimal context for a complex tool with many 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 description coverage is 100%, so the description does not need to add parameter details. The description provides no extra meaning beyond the schema, meeting baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a subscription and sets payment method in one operation, with specific verb 'Cria a assinatura e define sua forma de pagamento'. This distinguishes it from siblings like create_subscription (no payment) and define_subscription_pay_method (separate step).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use quando plano, assinante e dados de pagamento já estiverem disponíveis para iniciar a recorrência', giving clear context for when to use. It does not explicitly list alternatives or when not to use, missing a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, but the description does not add any behavioral context beyond purpose. It does not disclose side effects, permission requirements, or what happens if a plan with the same name exists. This lack of transparency could lead to unexpected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly front-loaded with the purpose and usage guidance. No redundant words. It efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested input schema (body with required name and interval), an output schema, and good annotations, the description is adequate for an agent to understand when and why to use it. However, it could mention that the plan includes name, interval, and optional repeats to 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 coverage is 100%, so baseline is 3. The description mentions 'periodicidade' and 'quantidade de cobranças recorrentes' which loosely map to interval and repeats, but does not explain them in detail. It adds minimal value beyond the schema, so score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cria' (creates), the resource 'plano' (plan), and defines what it does: sets the periodicity and number of recurring charges. It also distinguishes from siblings by noting it is used before linking clients to subscriptions that follow the same schedule, differentiating it from tools like create_subscription or list_plans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'Use antes de vincular clientes a assinaturas que deverão seguir a mesma programação.' It provides clear context but does not mention when not to use or name specific alternative tools, though the sibling list includes related plan 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?
Annotation already indicates destructiveHint=true, and description confirms revocation. Adds context about biometric payment journey but no additional behavioral details like idempotency or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines action, second gives usage scenario. No unnecessary words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose and usage. Does not mention that an enrollment identifier is required (though schema captures it) or outcome details, but output schema exists. Minor 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 covers 100% of parameters with descriptions. The tool description adds no extra parameter semantics, so 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 tool revokes a biometric enrollment link, with a specific verb and resource. It distinguishes from sibling tools like create or list, but does not 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage scenario (when the device or authorization should no longer allow payments without redirection), but does not mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds that it doesn't modify delivery, aligning with annotations. However, it does not disclose additional behavioral traits (e.g., pagination, error handling). With annotations covering safety, the bar is lower, so 3 is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, followed by usage guidance. No unnecessary words. Every sentence earns its place. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown but flagged as present), so return values are covered elsewhere. Annotations provide behavioral hints. The description gives a clear purpose and usage guideline, and parameters are in schema. It is complete enough for an agent to use, though it doesn't mention any prerequisites or limitations. Thus 4.
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%, and the schema already describes the two parameters (dataInicio, dataFim) with dates. The tool description does not add any extra meaning about parameters, so the baseline score of 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 it is for consulting the webhook configuration used in payment notifications. The verb 'Consulta' and resource 'configuração de webhook' are specific. While it doesn't explicitly distinguish from siblings like 'account_list_webhook', the focus on payments is clear. A 5 would require explicit differentiation, but 4 is appropriate.
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 says 'Use para confirmar o destino dos callbacks sem modificar sua entrega,' providing guidance on when to use (to confirm) and implying it's read-only. It doesn't explicitly state when not to use, but the context of siblings (config, delete webhooks) makes it clear. A 5 would require explicit alternatives, but 4 is fair.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that the tool does not alter contents ('sem alterar seus conteúdos'), which aligns with readOnlyHint. It does not provide additional behavioral details such as authorization requirements, rate limits, or error conditions. Since annotations carry the burden, the description adds minimal extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences with 21 words. It front-loads the core functionality and usage intent, with no redundant or unnecessary text. Every sentence 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?
Given the simple nature of a list tool, full schema coverage, and presence of annotations and output schema, the description is adequate. It does not explain return values (handled by output schema) or pagination details (covered in params). The only minor gap is not explicitly stating the batch-listing scope, but it is clear from context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented with field-level descriptions. The description only generically mentions 'período e filtros aceitos' without adding semantic context or usage examples for the parameters. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists due charge batches ('Lista lotes de cobranças Pix com vencimento') with period and filters. It distinguishes from sibling mutation tools by emphasizing read-only monitoring ('acompanhar sua criação sem alterar seus conteúdos'), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context ('Use para localizar lotes e acompanhar sua criação') but does not explicitly state when not to use it or suggest alternatives like pix_create_due_charge_batch or pix_update_due_charge_batch. The annotation readOnlyHint reinforces the non-destructive nature, but the description lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the tool's write nature is known. The description adds the context that adjustments are allowed only while the state permits, but does not elaborate on potential side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two succinct sentences with no wasted words. It front-loads the purpose and immediately provides usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool modifying a single field, the description covers the essential context (purpose, timing). However, it could explicitly state that only status can be set to 'CANCELADA' to avoid ambiguity. Output schema exists, so return values don't need explanation.
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% with both params described. The description does not add additional meaning beyond the schema, e.g., it does not mention that status can only be 'CANCELADA'. Baseline score of 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 tool 'reviews allowed fields' and 'adjusts the request', indicating an update operation. It distinguishes from sibling tools like pix_detail_request_recurrence_automatic by focusing on modification, but does not explicitly list which fields are modifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage condition: 'while the state allows, before final authorization'. It lacks explicit alternatives or when-not-to-use, but in context of siblings, it is positioned as the update tool for this specific resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds that it resends an email (a mutation) and does not issue a new charge, which aligns with the annotations but does not provide additional behavioral traits beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence front-loads the core purpose, and every word adds value. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, annotations, and output schema presence, the description is fairly complete. It explains the purpose and usage scenario, though it could mention prerequisites (e.g., charge must have a billet generated) or response expectations, but these are not critical.
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%, with each parameter having a description. The tool description does not add any extra meaning or context to the parameters (email and id) beyond what the schema already provides, so 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 action (resend by email) and the resource (already generated billet for a charge). It distinguishes from other send-email tools by specifying 'boleto já gerado' and 'cobrança,' but does not explicitly contrast with alternatives like send_link_email or send_carnet_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage scenario: 'Use quando o pagador precisar receber novamente o documento' and notes what the operation does not do ('não emite uma cobrança diferente'). However, it lacks explicit guidance on when not to use the tool or mention of 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, establishing that the tool modifies data. The description adds context that changes affect future transactions, which is useful but does not disclose additional behavioral traits like permissions or side effects. The description is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and relatively concise. It front-loads the purpose and includes key information. However, it could be slightly more structured (e.g., bullet points) and the title is in Portuguese while the tool name is in English, but that is not a major detriment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested schema and presence of an output schema, the description is somewhat minimal. It states the general effect ('afeta transações futuras') but does not explain the output or provide examples. For a tool with this complexity, more detail 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 the schema alone documents all parameters. However, many schema descriptions are tautological, repeating the field name. The tool description does not add any meaning beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('cria ou modifica') and the resource ('regras de recebimento e notificação Pix da conta ou de chaves específicas'). It distinguishes from siblings by specifying account-level Pix config update, which is distinct from other config tools like pix_config_webhook or of_config_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use para controlar formas aceitas de recebimento' providing clear context. However, it does not explicitly exclude alternative tools or state when not to use it. Among many sibling config tools, some guidance on when to choose this over others would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description states the tool does not recreate or charge, implying safety. This contradiction undermines transparency. The description does not disclose potential side effects like overwriting all metadata or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no extraneous information. It is front-loaded with the primary action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata update tool, the description covers the purpose and usage context well. However, the contradiction with destructiveHint and lack of detail on idempotency or error cases slightly reduce 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 coverage is 100% with descriptions for all parameters. The description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates integration metadata of a subscription, specifically references used by the calling system. It distinguishes from siblings like update_subscription by focusing on metadata and external links, and explicitly mentions it does not recreate or charge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool to correct external links without recreating or charging, providing clear context for when to use it. It lacks explicit alternatives or when-not-to-use scenarios, but the context is sufficient for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the destructive nature (pode efetivar a cobrança), which aligns with the destructiveHint annotation. However, it adds little beyond the annotation—no details on side effects, authentication needs, or what happens to the charge state. The description is minimal.
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 one sentence with two clear clauses, no redundancy, and no unnecessary details. It is front-loaded with the action and condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic scenario but does not explain what constitutes a 'compatible charge', the expected output, or error conditions. Given the complexity of nested parameters and the presence of an output schema, the description is adequate but incomplete.
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 the schema already documents all parameters. The description does not add any additional parameter information, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retry a card payment for a compatible charge after an unauthorized attempt. The verb 'tentar novamente' and the context of 'pagamento por cartão' make the action unambiguous. It distinguishes itself from sibling tools by specifying the retry scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use após uma tentativa não autorizada e com dados válidos'. It does not explicitly exclude other scenarios or mention alternative tools, but the condition is clear and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds context about the hosted checkout but does not disclose side effects (e.g., whether a webhook notification is sent), authentication requirements, or rate limits. With annotations covering basic behavioral traits, the description provides adequate but minimal enrichment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and perfectly front-loaded. The first sentence states what the tool does, and the second sentence gives the primary use case. Every word serves a purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, nested objects, output schema exists) and the array of sibling tools, the description adequately conveys its purpose but lacks details about prerequisites (e.g., need for a pre-existing plan), expected output behavior (though output schema exists), or constraints (e.g., rate limits). It is sufficient for a basic understanding but not fully comprehensive for an agent to select it confidently without deeper schema analysis.
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 the baseline is 3. The tool description does not add any additional meaning beyond the schema's property descriptions (e.g., 'items', 'settings'). Many schema descriptions are auto-generated and repetitive, but the description itself does not compensate by explaining parameter purpose or constraints. It remiss inherent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates a subscription and its payment link in one step, clearly differentiating it from siblings like create_one_step_charge (which creates a charge) and create_subscription (which likely creates a subscription without a link). The verb 'Cria' (creates) and resource 'assinatura' and 'link de pagamento' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: to allow the subscriber to complete the contract in Efí's hosted checkout. It implies when to use this tool (when a hosted checkout link is needed) but does not explicitly mention when not to use it or list alternatives. The guidance is clear but could be more comprehensive by excluding scenarios where other tools are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, so the safety profile is covered. Description adds that it consults parameters and status, but does not disclose any new behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. First sentence states the action, second sentence provides use case. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While purpose and use case are clear, the tool has a complex input schema with multiple query modes and an output schema exists. The description does not elaborate on these aspects, leaving some gaps for an agent to correctly interpret usage patterns.
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 the schema documents all parameters thoroughly. Description does not add any additional meaning or guidance on the complex anyOf alternatives, thus adding no value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it consults parameters and status of Open Finance automatic payment enrollments, with a specific verb 'Consultar' and resource 'adesões de pagamento automático'. It also distinguishes from siblings like of_list_automatic_pix_payment by focusing on enrollment check for authorization before charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use para verificar a autorização disponível antes de iniciar uma cobrança automática', providing clear context and a specific use case. However, it does not mention when not to use or compare with other list tools like of_list_automatic_pix_payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent hints. The description adds that it does not alter payments, which aligns with annotations. No additional behavior beyond annotations is disclosed, but no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. The core action and purpose are front-loaded, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema with two alternatives and many optional fields, the description lacks details on listing modes, pagination, and output. It is adequate but not thorough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description mentions 'período e filtros' which hints at the date range and optional filters, but does not explain the two alternative required parameter groups (by identifier vs. by date range). Value added is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists scheduled Pix payments via Open Finance, specifying the resource and scope. The verb 'Lista' matches the tool name, and it distinguishes from siblings like 'of_list_automatic_pix_payment' by focusing on scheduled payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool to track authorization, scheduling, and execution without modification, providing clear context. However, it does not explicitly mention when to avoid this tool or suggest alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and side effects. The description adds that the tool checks the association, providing moderate added context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no superfluous words. It front-loads the action and purpose, earning every sentence's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (one parameter, output schema exists), the description fully covers what the tool does, when to use it, and the safety profile via annotations. It is complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning to the 'id' parameter beyond the schema's generic 'Identificador do recurso.' It implicitly ties to the location recurrence via the tool name, but explicit elaboration is absent.
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 consults a location of automatic Pix recurrence and its current association. It provides a specific verb ('Consulta') and resource, distinguishing it from siblings like pix_detail_location (without recurrence) and pix_detail_recurrence_automatic (without location).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises use to confirm the link before displaying or reusing the payload, giving clear guidance on when to invoke the tool. It does not name exclusions or alternatives but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, so the description's mention of moving balance adds modest context. The constraint of same ownership is more of a purpose/guideline than a behavioral trait. No contradictions exist, but the description adds limited behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earned its place: the first defines the tool's purpose, the second provides usage guidance. It is front-loaded and contains no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists (though not provided), which reduces the burden for describing return values. The description covers the core constraint and usage reminder, but it lacks differentiation from the similar sibling 'pix_send', which could lead to confusion. Adequate but not comprehensive.
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 the baseline is 3. The description does not elaborate on parameter usage beyond general advice to verify origin, destination, and value, which maps to high-level concepts but does not add meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests a Pix transfer exclusively for accounts of the same ownership. The verb 'solicita' and resource 'transferência Pix para mesma titularidade' are specific, and it distinguishes itself from the broader 'pix_send' sibling tool by adding the constraint of same ownership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use after verifying origin, destination, and value, and notes that it moves balance. This provides clear context for when to invoke the tool. However, it does not explicitly mention when not to use it or name alternatives like 'pix_send' for different ownership scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds that the operation modifies the split link and advises to verify charge state, but does not elaborate on what exactly changes or any side effects. It is adequate but not rich beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no unnecessary words. It efficiently conveys the purpose and usage guidance. Could potentially combine the caution into the first sentence, but it's very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter structure, the presence of an output schema, and annotations covering idempotency and destructiveness, the description is sufficiently complete. It clarifies the scope (immediate charge) and provides a usage note. No 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?
The input schema covers the single parameter txid with a description ('Identificador da cobrança Pix'). The tool description adds no extra parameter semantics. With 100% schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: remove the split link from an immediate Pix charge. It uses a specific verb-reource pair and distinguishes from siblings like pix_split_unlink_due_charge (due charge) and pix_split_link_charge (link operation). The title also reinforces the 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 advises when to use ('when the receipt should no longer follow that distribution') and includes a caution to check the charge state before changing. It does not explicitly name alternatives, but the context of split operations implies the opposite (linking). Good practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that the operation is non-destructive to untouched items ('preservando as demais cobranças'), providing useful context. However, it does not disclose potential side effects, authorization requirements, or error conditions, which would raise the score further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with a rich schema and output schema. It covers the main purpose and usage pattern but omits details like batch existence prerequisites or error handling. Given the complexity of nested objects, a bit more context 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 coverage is 100%, with each parameter well-described in the schema. The description adds no additional parameter-level information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Revisa cobranças específicas dentro de um lote Pix com vencimento' (review/update specific charges in a Pix batch). It distinguishes from sibling tools like pix_create_due_charge_batch (create batch) and pix_update_due_charge (update single charge) by focusing on partial updates within a batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use para alterar somente os itens informados, preservando as demais cobranças do lote' (use to change only specified items, preserving others). It implies the tool is for partial updates but does not explicitly mention alternatives or when not to use it, hence not 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?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=true. The description 'updates allowed data' aligns but does not add context beyond annotations. It does not explain side effects, auth needs, or rate limits. With annotations present, the bar is lower, and the description meets minimal expectations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and action. No extraneous information. Every sentence contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, output schema, many siblings), the description is adequate but not comprehensive. It lacks details on partial updates, field behavior, or return value. However, the presence of an output schema reduces the burden. The description is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema documents all parameters. The description does not add any parameter-level meaning beyond what the schema provides. Baseline of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'updates' and resource 'subscription'. It distinguishes from creating a new subscription by explicitly mentioning 'without creating a new subscription'. This differentiates it from sibling tools like create_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool: 'to review individual configuration... without creating a new subscription'. This implies modification of an existing subscription. However, it does not explicitly state alternatives or when not to use, such as when to use update_metadata or cancel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior; description adds that callbacks are interrupted, but little else beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no unnecessary text.
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?
Adequate for a simple tool with one parameter and a known output schema; covers purpose and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, and description does not add new parameter details beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cancels an account opening webhook configuration by identifier, distinguishing it from other webhook tools like pix_delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains to use when the destination should no longer receive events, but does not explicitly mention alternative tools or 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?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds that it is a listing operation without alteration, matching the annotations. It does not disclose additional behaviors like pagination or rate limits, but the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the main action. Every phrase is meaningful with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has output schema and annotations covering safety. The description covers purpose and usage adequately. It could mention pagination behavior given the pagination parameters, but the schema already documents those. Overall, it is sufficiently complete for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for each parameter, though the descriptions are minimal (mostly repeating the field name). The tool description mentions 'according to accepted filters', which adds a bit of semantic context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists account opening webhook configurations, and names the specific domain (account opening) and action (list). It distinguishes from sibling tools by focusing on onboarding destinations and reading without altering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: to inventory onboarding destinations and locate a configuration without altering it. It does not explicitly list alternatives or when-not-to-use, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructive and idempotent. The description adds context: it cancels charges and depends on the state accepted by Efí, providing behavioral nuance. However, it lacks details on error conditions, reversibility, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences, no wasted words. First sentence states the action, second gives usage context. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and annotations covering safety, the description provides core purpose, usage context, and state dependency. The output schema likely covers return values, so completeness is adequate.
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% (id parameter described as 'Identificador do recurso'). The description adds no further parameter semantics, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels an existing carnê and its charges, using a specific verb and resource. It distinguishes from siblings like 'cancel_carnet_parcel' by specifying the scope (entire carnê vs. parcel).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear usage guideline: 'Use quando o conjunto de parcelas não deve mais ser cobrado' (use when the set of installments should no longer be charged). It does not explicitly mention when not to use or list alternatives, but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds that it stops future billing and only applies to active subscriptions, but doesn't detail side effects like refunds, pending charges, or irreversibility. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly states purpose and usage context, and contains no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, output schema, and simple parameter set, the description covers the essential aspects: what it does and when to use it. It could mention that the subscription must be active and the result is idempotent, but these are implied or covered by annotations.
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%, with the parameter 'id' already described. The tool description adds no additional information about parameters, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (cancela) and resource (assinatura ativa) and the specific effect (interrompe cobranças futuras). It distinguishes itself from sibling cancellation tools like cancel_charge and cancel_carnet by targeting subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use quando o cliente não deve mais permanecer vinculado à recorrência do plano.' It does not explicitly state when not to use it or mention alternatives, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is not read-only, not destructive, and not idempotent. The description adds that it is a one-step operation creating a link to a hosted checkout, which is useful but does not go beyond what annotations imply. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested parameters and an existing output schema, the description provides sufficient context for the core use case. Does not detail return values, but output schema is present so not required.
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 the description does not add additional meaning beyond what is in the parameter descriptions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a charge and payment link in a single step ('Cria, em uma única etapa, a cobrança e o link'), and specifies the hosted checkout context. It distinguishes from siblings like 'create_charge' (which likely only creates a charge) and 'create_one_step_subscription'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Quando a aplicação quiser oferecer pagamento sem implementar um checkout próprio.' It provides clear context but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true and idempotentHint=false. The description adds a security warning about the sensitive key in the response, but does not disclose what happens if called multiple times (e.g., key regeneration) or any other behavioral details beyond what annotations imply.
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: first states purpose, second gives usage guidance and warning. Extremely concise with no wasted words, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema exists, the description covers the essential purpose, usage context, and security. However, for a destructive, non-idempotent tool, more detail on the consequences of repeated calls would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so description does not need to clarify parameters. Baseline score of 4 applies. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a private key for SFTP statement integration. The verb 'gera' (generates) and the resource 'chave privada' are specific. It is distinct from all sibling tools, none of which involve key generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context ('Use ao configurar essa forma de entrega') and a security warning, but does not specify when to avoid using the tool (e.g., if a key already exists), or clarify idempotency or overwrite behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present (readOnlyHint=false etc.), and the description adds minimal behavioral insight beyond stating it creates a recurring schedule and makes statements available. No contradictions, but little extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no superfluous words. It efficiently conveys the purpose and usage suggestion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested object, output schema), the description covers the main purpose and context. It could mention return values or prerequisites, but it is sufficiently complete for an agent to understand the tool's role.
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% with descriptions for all parameters. The description does not add meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cria' and the resource 'agendamento recorrente para gerar extratos CNAB 240', making the tool's purpose unambiguous. It distinguishes from siblings like list_statement_recurrences and update_statement_recurrency by specifying creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case ('Use para automatizar a conciliação periódica') which guides when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative siblings, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the agent knows it modifies state. The description adds that it enables recurring charges, which is useful context beyond annotations, but does not detail permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences in Portuguese. Every word serves a purpose: action, resource, purpose, and outcome. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's role in a multi-step subscription flow. Given the complex schema and presence of an output schema, it provides adequate context. Could mention prerequisites like a valid subscription ID, but the required param 'id' covers that.
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% with detailed descriptions for each field, so the description's mention of 'forma de pagamento e os dados do cliente' adds minimal extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('associa') and resource ('assinatura previamente criada'), clearly distinguishing it from sibling tools like 'define_pay_method' which is for one-time charges. It states the outcome: enable recurring charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to complete the second step after creating a subscription. It implies context but does not explicitly exclude alternatives or state prerequisites, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds that it lists only open infractions ('abertas'), which is useful context beyond annotations. However, no additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with the main action and followed by usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, and scope (open infractions, authenticated account). With an output schema present, return values are not needed. However, pagination parameters are not mentioned, which could affect 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 coverage is 100% (all parameters described), but descriptions are tautological. The tool description adds no parameter meaning. Per guidelines, with high schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists open MED infractions associated with the authenticated account. It also specifies use cases: to monitor contests and identify cases needing defense. The name and title align well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use para acompanhar contestações e identificar casos que exigem defesa ou tratativa adicional.' This gives clear guidance on when to use. It implies that med_defense is for actual defense, but does not explicitly state alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive, non-read-only, idempotent operation with open-world effects. The description adds context (timing relative to payments) but does not elaborate on specific behavioral traits beyond what the annotations imply. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the purpose, the second provides usage guidance. No unnecessary words or repetition. Every sentence 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?
Given the complexity (nested parameters, multiple annotations, output schema exists), the description is adequate. It covers the primary purpose and usage timing. The schema and annotations handle the rest. However, it could optionally mention the other parameters or potential side effects more explicitly.
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%, but the schema descriptions are somewhat repetitive and generic. The tool description adds value by explaining that redirectURL and webhookURL are for redirects and callbacks, but it does not explain other parameters like processPayment or webhookSecurity. Baseline is 3 due to high coverage, and the description adds modest meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Configura as URLs') and the resource ('redirecionamentos e callbacks das jornadas Open Finance'). This distinguishes it from sibling tools like 'of_config_detail' which retrieves config, and other payment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use antes de iniciar pagamentos e somente com destinos preparados para receber o fluxo.' This tells the agent when and under what conditions to use the tool, though it does not explicitly list when not to use it or 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?
Annotations already indicate it's a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds context but does not disclose side effects or external calls implied by openWorldHint=true. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown), the description does not need to explain return values. The tool's role in the biometric payment journey is clearly stated, leaving no major 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 the input schema already documents all parameters and their constraints. The description does not add additional meaning beyond stating the tool's general purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'cria o vínculo' and specifies the resource: biometric enrollment for payment journey. It distinguishes from siblings like of_list_biometric_enrollment (list) and of_revoke_biometric_enrollment (revoke).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use during user enrollment, before starting payments without redirection', providing clear context. It could be improved by mentioning when not to use (e.g., if enrollment already exists), but the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true; the description adds that it uses biometrics without redirect and requires a bond. However, it does not clarify idempotency or error behaviors beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first describes the action, the second provides critical usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description is adequate for its complexity. It covers purpose, usage condition, and destructive nature, but could mention response format or error cases.
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 the description's role is limited. It does add context that the vínculo must be pre-existing, which relates to the required parameter, but no further parameter details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests a Pix payment via biometric journey without redirect, distinguishing it from other payment tools like pix_send or pix_create_charge. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states usage conditions: only with a previously created bond and after confirming recipient and amount. It warns that it can move funds, but does not mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false. Description adds 'movimenta valores' confirming the write operation. No additional behavioral context is provided beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage guideline. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations, output schema, and full schema coverage, the description provides a complete picture for the agent. The precondition and warning are sufficient, though additional details on idempotency or error handling could improve it.
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 description need not add param details. No extra semantic meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool solicits a devolution of an immediate Pix payment initiated via Open Finance, with specific verb and resource. It distinguishes from siblings by specifying 'Open Finance' and 'imediato'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use after locating and confirming the completed payment, and warns that it moves values. However, it does not explicitly compare to sibling devolution tools like of_devolution_schedule_pix or of_devolution_recurrency_pix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the caution about moving resources and checking before use, which gives extra context about the operation's impact. It does not disclose potential side effects beyond what annotations already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The purpose is stated first, followed by usage guidance. No unnecessary words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and the relatively straightforward operation (executing a refund for an executed scheduled payment), the description provides sufficient context. It covers the action and preconditions, though it could briefly mention what the response contains.
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?
Parameter schema coverage is 100% with descriptions in the schema. The tool description does not add additional meaning or context for the parameters beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Solicita a devolução'), the specific resource ('pagamento Pix agendado que já foi executado'), and the context (use after checking). It distinguishes this tool from other pix devolution or cancellation tools by specifying the scheduled and executed nature of the payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use: after verifying the payment and the refunded amount. It also warns about moving funds. However, it does not explicitly mention when not to use or suggest alternative tools for non-executed payments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety profile is known. Description adds filtering behavior and use-case context but no additional behavioral traits like pagination or authentication needs.
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-sentence description: first sentence states purpose, second gives use case. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a list tool with rich annotations and schema coverage. Output schema exists but is not shown; description could mention return structure but not necessary given other fields.
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% with both parameters (cpf, cnpj) fully described. Description adds no extra meaning beyond schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists biometric links with filters and specifies a concrete use case (confirm eligible link before payment). Distinguishes from sibling tools like of_list_biometric_pix_payment which lists payments, not enrollments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before initiating a payment without redirection. Does not mention alternatives or when not to use, but 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds minimal behavioral context (it is a read operation). It does not contradict annotations, but also does not elaborate further.
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, each serving a distinct purpose: statement of functionality and usage guidance. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers purpose and usage. It could mention that parameters are optional or filtering behavior, but this is not critical for a simple read 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?
All parameters have descriptions in the input schema (100% coverage), so the tool description does not need to add more. It does not explain parameter semantics beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists institutions available for Open Finance payment initiation journeys, with a specific verb and resource. It distinguishes from siblings that deal with Pix charges, payments, etc., by focusing on listing participating institutions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool ('for the payer to choose where to authorize the operation before starting a Pix'), but does not mention exclusions or alternatives. Given the narrow domain, it is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description reinforces read-only behavior ('sem modificar a programação') but adds no new behavioral details beyond annotations. It does not mention auth, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences. The first sentence states the action and scope, the second clarifies intent. No wasted words. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested params, output schema exists), the description is adequate. It covers the purpose and safe usage. Output schema is present, so return values need not be detailed. Pagination details are in the schema. Could be slightly richer on operational context, but overall complete for the task.
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 baseline is 3. The schema provides detailed but repetitive descriptions for each parameter (e.g., 'Valor do campo ... usado na entrada da operação'). The tool description does not add further parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (lista), resource (recorrências e pagamentos Pix), and scope (via Open Finance, conforme os filtros). It distinguishes from sibling tools by emphasizing the read-only monitoring purpose ('sem modificar a programação'). The title and description align.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states the intended use case: 'Use para acompanhar a série e suas parcelas sem modificar a programação.' This implies a monitoring role, distinguishing it from modification tools. No explicit alternatives are given, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true; description confirms altering a future financial execution. However, it does not detail what exactly changes beyond the schema, and idempotency is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no fluff. Efficiently conveys the essential purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers the tool's purpose and usage. Lacks examples or edge cases, but is sufficient for the 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%, and the description adds minimal additional meaning (e.g., 'parcela identificada'). The schema already documents parameters well; the description does not significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces an identified installment within an Open Finance Pix recurrence, using the verb 'Substitui' and specific resource. It distinguishes from siblings like cancel or devolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when the schedule of that installment needs revision, providing clear context. Lacks explicit exclusions or alternative tool mentions, but the condition is well-stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it 'produz sua jornada de autorização' (produces authorization journey) and 'movimentará valores' (moves money), confirming destructive nature. No contradiction, but does not detail authorization flow or side effects beyond movement of values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage. No wasted words. Efficient and easy to parse.
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 mutation tool with an output schema, the description covers purpose and usage. It mentions the authorization journey, which is important context. Minor gap: no mention of prerequisites like Open Finance consent or idempotency handling, but those are partially covered by schema and annotations.
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 the schema already documents all parameters. The description does not add parameter-specific details beyond the schema; it only states the tool's purpose. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it initiates a scheduled Pix payment via Open Finance and produces an authorization journey. The verb 'Solicita a iniciação' and the resource 'Pix para data futura' are specific. It distinguishes from immediate Pix payments by mentioning 'data futura' and from other scheduling/cancel operations via sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use quando o pagamento deve ocorrer posteriormente' (use when payment must occur later), providing clear context for when to use. It does not state when not to use, but the sibling 'of_start_pix_payment' implies alternative for immediate payments, so guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint, readOnlyHint, and idempotentHint. The description adds the behavioral consequence that the application will stop receiving callbacks, which goes beyond the annotations but is not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one stating the purpose and one stating when to use. It is concise, front-loaded, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and good annotations, the description provides enough context. It covers the purpose and usage scenario. It could mention idempotency or comparison with siblings, but is still adequate.
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% with descriptions for 'body' and 'url' parameters. The tool description does not add further parameter semantics, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Remover webhook de pagamentos de contas' and description 'Remove a configuração de webhook de pagamentos de contas' clearly state the verb and resource. The description also adds context about when to use, distinguishing it from sibling tools like pay_config_webhook or pay_list_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use quando o destino não deve mais receber atualizações', providing a clear condition for usage. While it doesn't mention alternatives, the context of siblings implies it is for deletion, not configuration or listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's addition that it is for monitoring without initiating payments adds limited incremental value. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word adds value. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (1 parameter object with 2 required fields) and the presence of an output schema, the description adequately explains the tool's purpose and constraints. It could mention expected output structure but is otherwise complete.
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% with both parameters already described in the schema. The description does not add any additional meaning or usage details for the parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists a summary of payment requests based on accepted filters. It explicitly notes it is for monitoring and reconciliation without initiating new payments, distinguishing it from payment creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description 'Use para acompanhamento e conciliação das saídas sem iniciar novos pagamentos' provides clear context for when to use the tool (monitoring and reconciliation) and what not to do (initiate payments), but does not name specific 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?
Annotations already declare destructiveHint=true, so the description doesn't need to restate that it modifies state. The description adds minimal behavioral context beyond the fact that it configures a webhook. It could mention overwriting behavior or authentication requirements, but given annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the purpose and include a usage hint. Every word is essential, no fluff. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one parameter) and existence of an output schema (not shown), the description is fairly complete. It could explain what happens if the webhook URL already exists or how to manage multiple endpoints, but for this tool it is adequate. Context signals show it's among many siblings, so clarity is important.
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% with one parameter (webhookUrl) having a clear description. The tool description repeats that the URL receives events, adding no new meaning beyond the schema. Baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (configures), the resource (webhook URL for Pix Automático charges), and additional context. It specifies the exact purpose and differentiates from sibling tools like pix_config_webhook by targeting Pix Automático specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use depois de preparar o callback seguro para acompanhar tentativas e pagamentos recorrentes.' It tells the user when to use it (after preparing a secure callback), but does not explicitly state when not to use it or mention alternatives. Still, it offers good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by indicating that a secure callback must be prepared first and that the operation sets the notification destination. While annotations show destructiveHint: true, the description doesn't elaborate on consequences like overwriting existing webhook or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise, front-loaded sentences. The first states the primary purpose, and the second adds a prerequisite and confirms the action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description adequately covers purpose and prerequisite. It could be improved by mentioning whether existing webhook configurations are replaced or what happens on failure, but the specificity of the resource type suffices.
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% with clear descriptions for 'webhookUrl' (URI format). The description adds minimal extra meaning ('destino das notificações') but largely echoes the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: configuring the URL for Pix automatic recurrence webhook events. The verb 'Configura' and the specific resource 'webhook de recorrências Pix Automático' distinguish it from generic webhook tools like pix_config_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Use depois de preparar o callback seguro') but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. Usage context is implied by specifying the recurrence webhook type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context that the tool is for automatic charges and the system assigns txid, but no further behavioral details beyond what annotations provide. Annotations already indicate it's a write operation (readOnlyHint=false), and the description aligns. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and purpose, with no wasted words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (nested objects) and the existence of an output schema, the description is succinct but covers the essential scenario. It completes the picture for an agent to understand when to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any meaning about parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a PIX Automatic charge and lets Efí assign the txid, distinguishing it from the sibling tool pix_create_automatic_charge_txid that requires specifying the txid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it: for established recurrences when the application doesn't need to choose the identifier. It implies when not to use (when txid is needed) but doesn't name the alternative explicitly. Clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds that this creates a charge, consistent with annotations, but does not provide additional behavioral details beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the action. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, output schema exists), the description provides essential purpose and usage context. It doesn't explain return values, but output schema covers that. Slightly incomplete for absolute beginners but adequate.
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 the input schema fully describes all parameters. The description does not add extra meaning or usage details for the parameters beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an immediate Pix charge with a txid defined by the receiver, using specific verbs and resource naming. It distinguishes from siblings like pix_create_due_charge which create due charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: when the application needs to control the identifier and generate a traceable Pix payment. It does not explicitly mention when not to use or list alternatives, but the context of siblings and the phrase 'txid definido pelo recebedor' implies differences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only basic hints (non-readOnly, non-destructive, non-idempotent, openWorld). Description adds that the location is 'reutilizável' (reusable), which is a behavioral trait. However, it does not discuss side effects, permissions, or behavior on multiple calls. Given limited annotations, description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema (hinted), the description covers main purpose and usage guidance. It could mention that the output includes a location ID, but this is likely in the output schema. Minor gap: no mention of prerequisites or idempotency, but overall complete.
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% for the single parameter (body with tipoCob). The tool description does not add any additional meaning about the parameter beyond what the schema provides. Baseline of 3 is appropriate since schema covers parameters, though schema descriptions are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a reusable location for associating a charge with a dynamic payload, and distinguishes itself by noting it should be used before generating QR code when separate management is needed. This verb+resource combination differentiates from siblings like pix_generate_qr_code or pix_create_charge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit context: use before generating QR code when you need to manage the association separately. It does not explicitly state when not to use or name alternatives, but the guidance is clear enough for an AI agent to decide when to invoke this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's not read-only and not destructive. The description adds that the recurrence must be authorized by the payer ('deverá ser autorizada pelo pagador'), which is important behavioral context beyond the annotations. However, it doesn't detail the post-creation flow or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the action and resource, and immediately follows with usage guidance. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, many parameters) and the presence of an output schema, the description is minimal. It hints at the authorization requirement but doesn't explain the overall process or expected outcomes, leaving gaps for a multi-step flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, most descriptions are tautological (e.g., 'Valor do campo “valor Rec” usado na entrada da operação'), adding little meaning beyond field names. Only a few descriptions (e.g., 'calendario' as 'Regras de calendário e vencimento') provide actual semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cria' (creates) and the resource 'recorrência' for Pix Automático, specifying it requires payer authorization. It distinguishes from siblings like update or detail by noting it's used at the start of the recurring agreement journey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use no início da jornada de contratação do acordo recorrente' (use at the beginning of the hiring journey), providing clear context. It does not explicitly mention when not to use or alternatives, but given sibling tools like pix_update_recurrence_automatic, the use case is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it creates a 'request for confirmation', implying a specific behavioral step in the recurrence journey, but does not detail side effects, triggers, or error cases. This adds some value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that immediately convey the action and context. There is no fluff, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and usage context adequately. Since an output schema exists, return values are documented elsewhere. However, it could be improved by mentioning prerequisites or the typical workflow, but overall it provides sufficient context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with detailed descriptions for each field. The tool description adds no additional semantic information about parameters beyond what the schema provides. Therefore, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cria uma solicitação de confirmação de recorrência de Pix Automático') and provides context that distinguishes it from siblings, such as the need for payer authorization before recurring charges. This differentiates it from other recurrence-related tools like pix_create_recurrence_automatic.
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 specifies when to use this tool: 'na jornada em que a autorização do pagador depende dessa solicitação antes das cobranças recorrentes'. It does not explicitly list when not to use it or provide alternative tools, but the context is clear enough for an agent to understand the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds that the webhook is removed and notifications stop, which is consistent but does not provide additional behavioral insights beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Information is front-loaded: purpose first, usage second. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is nearly complete. It covers purpose, usage, and effect. The presence of an output schema reduces the need to explain returns. Could marginally mention prerequisites (e.g., webhook must exist), but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions. The tool description does not add further meaning to the 'chave' parameter beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (removing webhook configuration) and the associated resource (chave Pix). It distinguishes from siblings like pix_config_webhook or pix_list_webhook by focusing on deletion. The effect (cessation of event delivery) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: when a destination should no longer receive events. It implicitly advises against using when events are still desired. While it lacks explicit mention of alternatives, the context is sufficient for an agent to decide when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, openWorld, and idempotent. The description adds minor behavioral detail (generates both text and image, prerequisite step), but it does not provide significant new behavioral traits beyond what annotations cover. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, with every word earning its place. No unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description adequately covers the main purpose, usage timing, and outputs. It could mention prerequisites like the location being active, but it is sufficient for an agent to select and invoke 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% with the parameter 'id' described as 'Identificador do recurso.' The description adds no extra meaning or usage guidance for the parameter, so it meets the baseline expectation but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gera' and identifies the exact resources: 'Pix Copia e Cola e a imagem do QR Code'. It specifies the context 'para uma location existente', which implicitly distinguishes it from static QR generation tools like pix_generate_static_qr_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use depois de associar a location à cobrança que o pagador deverá acessar.' This tells the agent when to use the tool, but it does not mention when not to use it or name alternative tools for different scenarios, such as pix_generate_static_qr_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds valuable context: the operation is performed locally (no network request) and does not create charges or financial transactions. This goes beyond annotations and clarifies side effects well.
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 with no wasted words. The first sentence states the core action, and the second explains when to use it. Ideal front-loading and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, schema, and output schema existence, the description is sufficient. It explains the local nature and financial safety, and the output is implied to be a QR code image. No major 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 the description does not need to elaborate on parameters. The description mentions 'dados do recebedor' generically, but does not add 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 clearly identifies the tool as generating a static Pix payload and its image locally, and it states that it does not create a charge or make a financial request. However, it does not explicitly distinguish itself from similar sibling tools like pix_generate_qr_code, which may also generate QR codes, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for presenting a QR code without creating a charge or making a financial request. It implies when not to use it, but does not name alternative tools for dynamic charges. This is clear but lacks differentiation from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description reinforces read-only behavior but adds no further behavioral context beyond that. Given the annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states what the tool does, the second recommends when to use it. Every word is meaningful, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with a full input schema and output schema, the description covers the essential purpose and usage. It could mention pagination or output format, but the schema and annotations suffice.
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 each parameter is already described in the input schema. The description adds high-level context about filters and period but no extra detail beyond the schema, making the contribution marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: list immediate Pix charges with period and filters. The title 'Listar cobranças Pix imediatas' matches the name and clearly distinguishes it from sibling tools like pix_list_due_charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends use in monitoring and reconciliation routines and emphasizes that records are not altered, providing clear context. While it doesn't list alternatives, the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the read-only nature already declared by annotations (readOnlyHint=true), stating 'sem alterar seus estados.' It adds minimal additional behavioral insight beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the action and context, second gives usage guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many optional filters, nested pagination) and the presence of an output schema, the description covers the core purpose and usage. It could have briefly mentioned pagination or filter categories, but remains adequate.
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 the schema already documents all parameters. The description mentions 'período e filtros informados' but does not add specific meaning beyond the schema. This meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists automatic Pix recurrences based on period and filters, and its use case is to monitor authorizations and locate agreements without altering states. This distinguishes it from many related Pix tools (e.g., pix_list_charges, pix_detail_automatic_charge).
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 says 'Use para acompanhar autorizações e localizar acordos sem alterar seus estados,' providing clear context for when to use (monitoring/reading) and implying not to use for state changes. However, it does not explicitly name alternative tools among the many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description reinforces the read-only nature ('sem modificá-los') and adds context about inventory and verification, but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the core function, second explains use. It is front-loaded, concise, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with a simple parameter object and output schema, the description covers purpose and use case adequately. It could be slightly more specific about the filters (inicio/fim being date range), but the schema provides that detail.
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?
Parameter descriptions are fully covered by the input schema (100% coverage). The description does not provide any additional meaning or examples for the 'inicio' and 'fim' parameters, so it meets the baseline but does not add extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Pix webhook configurations according to available filters. It explicitly distinguishes its read-only listing use case from sibling tools like config, detail, delete, and resend by noting it verifies links without modifying them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance: use this tool to inventory notification destinations and verify links without modification. It implies not to use for configuration, deletion, or other operations, but does not explicitly name alternative tools for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that it does not modify links, aligning with annotations. No additional behavioral details (e.g., pagination behavior) are provided, so the description adds limited value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action and purpose. Every word adds value, and it is efficient without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameters, pagination) and the presence of an output schema, the description is adequate. It covers the core purpose and read-only nature. It could mention pagination explicitly, but the schema and sibling tools provide context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the schema already documents each parameter's meaning. The description does not provide any additional semantic information beyond what is in the schema, fulfilling the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Pix payload locations using filters, and specifies it is for locating charge/QR associations without modification. This distinguishes it from sibling tools like pix_create_location, pix_detail_location, and pix_generate_qr_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool to locate associations without modifying links, which provides clear context. Although it does not explicitly state when not to use it or name alternatives, the read-only intent is well communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate read-only and idempotent behavior. The description adds 'sem movimentar valores', reinforcing the read-only nature. However, it does not disclose pagination details or other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that directly convey the tool's purpose and usage. Every word adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple parameters, nested pagination) and the presence of an output schema, the description adequately covers the tool's function. It mentions period and filters, though it does not detail output format or pagination. The missing details are compensated by the schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description adds little beyond 'filtros aceitos'. The individual parameters are well-documented in the schema, so the description does not need to elaborate further. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lista recebimentos Pix' (lists Pix receipts) and specifies the action with 'conforme período e filtros aceitos'. It also provides a distinct use case: 'Use para conciliar entradas na conta e acompanhar devoluções sem movimentar valores', which differentiates it from siblings like pix_send_list or pix_list_charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use: 'para conciliar entradas na conta e acompanhar devoluções'. It implies this tool is for listing received Pix, but does not explicitly mention when not to use or name alternative tools like pix_detail_received for single receipts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so behavior is a write operation. Description adds the condition but does not detail side effects, authorization needs, or what 'retentar' entails beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are concise and front-loaded: first sentence states the action, second gives usage condition. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and when to use, and with output schema available, return values are handled. It lacks details on prerequisites or exactly what the retry modifies, but overall is sufficient given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions already define 'txid' and 'data'. The tool description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Solicitar retentativa' and the resource 'cobrança de Pix Automático' with a specific date, distinguishing it from creating or updating charges. The title reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when previous charge was not completed and recurrence conditions allow retry. Does not mention when not to use or alternatives, but the condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description confirms the mutation ('cria ou substitui') and adds context about future links. However, it does not elaborate on the effect of replacement (e.g., overwriting existing config) beyond the word 'substitui'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and annotations, the description sufficiently captures the tool's purpose and usage context. It explains the key differentiator (custom identifier) and notes future links. Minor omission: no explicit mention of idempotent or destructive behavior beyond 'substitui', but annotations cover that.
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%, with descriptions for all parameters. The description does not add extra meaning beyond the schema; it only references the identifier in the context of the tool's purpose. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or replaces a split configuration with a chosen identifier. It specifies the action ('cria ou substitui') and the resource ('configuração de split'), distinguishing it from sibling tools that operate on charges or list configs.
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 tells when to use the tool: when the application needs to control the identifier. It also notes that future links will use the resulting definition. However, it does not explicitly state when not to use it or mention alternatives like pix_split_config (which may create without a specific id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that it does not alter repasses, but does not disclose other behaviors like error handling 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a usage note, no unnecessary words, and front-loads the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, readonly), and presence of an output schema, the description is complete enough. It covers the purpose and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the single parameter (txid) as 'Identificador da cobrança Pix.' The description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the split configuration for a Pix due charge, using the verb 'Consultar' and specifying the resource. It distinguishes from siblings that link/unlink splits by mentioning it's for verification only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says to use for checking distribution without altering repasses, which implies a read-only query. However, it does not explicitly exclude other scenarios or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true) already convey mutability, destructiveness, and idempotency. Description adds timing context but no new behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the action, second provides usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the core purpose and usage timing. Lacks detail on error scenarios (e.g., nonexistent split config), but given the presence of an output schema, it is largely sufficient.
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% with clear parameter descriptions. Description adds no additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: linking an existing split configuration to an immediate Pix charge. It distinguishes from siblings like pix_split_unlink_charge (unlink) and pix_split_link_due_charge (link to due charge), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use before payment to define value distribution. Does not list when not to use or alternatives, but the context is clear among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows it mutates. The description adds the context of removing a link but does not detail side effects or prerequisites beyond checking state. Still, it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, directly to the point. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and a single required parameter, the description is largely sufficient. It includes an important precaution about checking the charge state. However, it could be slightly more explicit about what the removal entails.
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?
Input schema provides 100% coverage with a description for 'txid'. The tool description does not add additional meaning beyond what the schema already states, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Remove o vínculo de split') and resource ('cobrança Pix com vencimento'), distinguishing it from sibling split tools like pix_split_link_due_charge and pix_split_unlink_charge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear when-to-use ('Use quando o recebimento não deve mais seguir aquela distribuição') and a precaution to check the charge state. Does not explicitly name alternatives, but the context given is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true; description adds context about payload purpose but no additional behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and usage adequately for a simple unlink operation with output schema available. Could mention prerequisites but not essential.
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 100% with only one param (id). Description provides no extra meaning beyond schema's 'Identificador do recurso', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'Remove' and resource 'vínculo entre location e recorrência de Pix Automático', clearly distinguishing from other unlink tools like pix_unlink_txid_location.
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?
Explicit when-to-use: 'Use quando o payload não deve mais representar aquele acordo recorrente.' No exclusions or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description reinforces that the operation moves resources. No contradiction, but the description adds minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states function, second provides usage guidance. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers purpose and usage context. Given the presence of annotations and output schema, it is reasonably complete for a refund tool, though it could mention idempotency behavior (already in annotations).
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?
Input schema has 100% coverage with descriptions for all parameters. The description does not add further parameter-specific meaning; thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it requests full or partial refund of a card payment, using specific verb and resource, distinguishing it from sibling tools like cancel_charge or settle_charge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool to refund values from an already paid charge, providing clear context. However, it does not mention when not to use it (e.g., for unpaid charges) or name alternatives like cancel_charge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly and destructive behavior. The description adds that it alters the financial state, but lacks details on side effects, reversibility, or other consequences. This is sufficient but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and usage condition. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the presence of an output schema (not shown but noted), the description adequately covers purpose, usage context, and behavioral impact. It could mention prerequisites or side effects but remains sufficiently complete for a manual settle action.
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% with clear parameter descriptions. The tool description does not add additional meaning to the parameters beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('marca manualmente como paga'), resource ('uma parcela específica de carnê'), and distinguishes from siblings like 'settle_carnet' (entire carnet) and 'cancel_carnet_parcel' (cancellation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('quando o recebimento externo precisar ser registrado'), providing clear context. It does not explicitly mention when not to use or list alternative tools, but the condition is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, covering the core behavioral traits. The description adds that 'as cobranças das parcelas informadas serão modificadas', but this is already implied by the update verb. No extra insight on scope or reversibility beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words. Front-loaded with purpose and usage. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a batch update tool with high schema coverage and annotations. However, it lacks guidance on limits (e.g., max parcels), prerequisites (carnet must exist), and expected output/errors. The presence of an output schema partially compensates, but more context on coordination behavior would be beneficial.
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 the schema already documents all parameters (parcels array with parcel integer and expire_at string). The description does not add meaning beyond 'dados permitidos' and does not explain constraints or format of the fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates multiple parcels of a carnet in a coordinated manner, using the verb 'Atualiza' and specifying the resource 'parcelas de um carnê'. It distinguishes from sibling tools like 'update_carnet_parcel' (singular) by highlighting the batch operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('aplicar revisões coordenadas a vários vencimentos') but does not explicitly state when not to use it or mention alternatives like update_carnet_parcel for single parcels. The sibling list implies the distinction, but direct exclusion is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's clarification that it adds a description without destructive effects is consistent but not substantial beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences that front-load the action and constraints without any fluff. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, schema coverage, and existing output schema, the description fully covers the necessary context for correct invocation.
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% with parameter descriptions already clear (id as identifier, description as text). The tool description does not add new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Acrescenta' and the resource 'histórico de um carnê existente', specifying it adds a description without modifying installments. This distinguishes it from sibling tools that update or cancel carnets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it for registering an operational occurrence without modifying other fields. It implies when not to use (if needing to modify charges or payments), but could explicitly mention alternatives like update_carnet_parcel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that it does not complete payment method selection, which is useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences, front-loaded with action. Efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested objects, the description is minimal but sufficient. With 100% schema coverage and an output schema, it covers the essential usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to explain parameters. It adds no additional meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates the initial transaction without finalizing payment method, and distinguishes from one-step charges like create_one_step_charge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use in a two-step flow before associating boleto, cartão, or link. Provides clear context, but does not explicitly exclude alternative uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description does not contradict these and adds the context that this tool should be used before other actions. However, it does not provide additional behavioral details beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first defines the tool's function, second advises when to use it. No unnecessary words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive annotations, the description is sufficient. It covers the purpose and usage timing without missing critical information.
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%: both 'brand' and 'total' are described in the schema. The description does not add extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: consulting installment options and values for a specific card brand. The verb 'consulta' and resource 'opções de parcelamento' are specific. Among many sibling tools, this is the only one dedicated to installment options, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to use it before presenting installments to the customer or before creating a charge by card, providing clear context. It does not explicitly state when not to use it or list alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds context about the callback trigger and transaction state confirmation but does not reveal additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no wasted words, and immediately communicates the tool's purpose and usage context. It is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations (readOnly, idempotent), simple schema (one required param), and existence of an output schema, the description provides all necessary context: what it does, when to use it, and why. No 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?
The schema has 100% coverage, and the description does not add any extra meaning to the 'token' parameter beyond its schema definition. The tool description focuses on overall purpose rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Recupera' (retrieves), the resource 'notificação', and specifies the usage context (after receiving a callback token). This distinguishes it from sibling tools which deal with charges, subscriptions, and other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises use after a callback notification to confirm transaction state. While it doesn't list alternatives or when not to use, the context is clear and sufficient for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description confirms it lists payments and does not create them, adding that it is for reconciliation. However, it does not disclose detailed behavioral aspects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with purpose, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. Annotations provide safety and idempotence. The description explains the use case clearly. With only one required parameter, the definition is complete.
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% with both parameters having descriptions. The tool description does not add additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state it lists automatic Pix payments from Open Finance. The description specifies it lists payments made by automatic enrollments according to filters, distinguishing it from other payment-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it for tracking and reconciliation without creating payments, which implies a read-only monitoring use case. It does not explicitly compare to siblings but given the context, the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it does not move balance, which aligns with the annotations, and specifies what data is presented. However, it does not add significant behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded, with no unnecessary information. Every sentence contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple read-only tool with one parameter. Annotations and output schema exist, and the context of not moving balance is clearly stated. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter codBarras is fully described in the schema (100% coverage) with pattern and description. The tool description does not add any additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: consult and validate barcode data before payment, showing beneficiary, due date, and amount without moving balance. It distinguishes from payment execution tools by explicitly stating it does not move balance.
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 specifies when to use the tool: 'Use para apresentar beneficiário, vencimento e valor ao usuário sem movimentar saldo.' It implies not to use when payment is intended, but does not explicitly name alternative tools. Given sibling list context, the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds that the tool creates a charge linked to an existing recurrence, which aligns with annotations. No contradictions, but it could mention prerequisites like the recurrence must exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and target. It is concise and efficient, though it could include a brief note on prerequisites without adding noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, 100% schema coverage, output schema exists), the description is mostly complete. It explains the purpose and usage context, but could explicitly state that an existing recurrence is required (implied by 'já estabelecido').
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%, with each parameter and subfield having a description. The tool description adds no additional meaning beyond the schema, which already adequately documents all parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool creates a charge linked to a recurring Pix Automatic using a receiver-defined txid. It distinguishes from siblings like pix_create_automatic_charge (which likely does not use a txid) by highlighting the txid involvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool to schedule a charge for an already established recurring agreement, providing clear context. However, it does not explicitly mention when not to use it or alternatives (e.g., pix_create_automatic_charge without txid).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world. The description adds that it queries a specific entity ('solicitação de confirmação de recorrência') and returns its response and status, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief, front-loaded sentences with no extraneous information. Every word serves a purpose: action verb, resource, usage intent, and safety note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter and presence of an output schema, the description adequately covers what the tool does and returns. Provides sufficient context for a read-only query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a single parameter 'idSolicRec' fully described. The description does not add further parameter details, meeting the baseline for high 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 clearly states the tool queries a recurrence confirmation request by identifier. It distinguishes from sibling update tools by emphasizing 'without modifying the associated recurrence.' However, it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use it: to track response and status. It also clarifies that it does not modify the recurrence, implying not for updates. No explicit when-not or alternatives, but sufficiently clear for a read-only query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that it does not alter delivery, reinforcing the read-only behavior. This is consistent with annotations and provides a slight behavioral nuance beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no wasted words. Every sentence adds value: the first defines the action, the second specifies the use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the purpose and use case. With an output schema available, the return structure is documented. It could clarify whether the tool returns a single configuration or a list (given the name 'list'), but overall it is sufficiently complete for this read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, with 100% schema description coverage. The description does not need to add parameter details. A baseline of 4 is appropriate for zero-parameter tools.
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 queries the current webhook configuration for automatic Pix recurrences, using the verb 'consulta' and specifying the resource. It adds that it does not alter delivery, distinguishing it from mutation tools. However, it does not explicitly differentiate from siblings like pix_list_webhook or pix_detail_webhook_recurrence_automatic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it to confirm the destination of events without altering notification delivery, providing clear context for a read-only check. It does not mention when to use alternatives or exclude cases, but the guidance is sufficient for the tool's read-only nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and openWorldHint=true, which convey safety and idempotence. Description adds that the tool does not alter the charge, reinforcing the read-only behavior but not adding substantial new information beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and to the point, with no redundant or extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema and the annotations fully cover behavioral aspects (readOnly, idempotent, openWorld), the description is complete. It clearly explains the tool's purpose and that it is a read operation, which is sufficient for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already describes the only parameter (txid) as 'Identificador da cobrança Pix.' The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries split configuration for an immediate Pix charge, using verbs 'Consulta' and 'verificar' to indicate read-only inspection. It distinguishes from sibling tools like pix_split_link_charge by focusing on inspection without modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use para verificar' which implies appropriate usage context. It does not list alternatives or exclusions, but the read-only nature is clear, and sibling tool names (e.g., pix_split_link_charge) indirectly provide contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, readOnlyHint=false. The description adds behavioral context: updates are contingent on the charge state allowing changes, which is useful beyond annotations. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence states action and identifier, second sentence specifies usage condition. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many nested parameters, extensive siblings), the description is minimal. It does not explain allowed fields, partial updates, or error conditions. Output schema exists but does not compensate for missing context on usage scope.
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 the baseline is 3. The description does not add additional meaning beyond what the schema provides (e.g., 'campos permitidos' is vague; the schema details all fields).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing due Pix charge identified by txid, using the verb 'Revisa' (reviews/updates) and specifying 'campos permitidos' (allowed fields). It distinguishes itself from siblings like pix_create_due_charge (create) and pix_detail_due_charge (read) by focusing on modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage condition: 'enquanto seu estado admitir mudanças' (while its state allows changes). However, it does not explicitly list when not to use it or mention alternatives like pix_update_charge or pix_update_due_charge_batch, which are present among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds no extra behavioral details beyond stating it updates attributes. Adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences in Portuguese, front-loaded with verb and resource, no unnecessary words. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and annotations, the description sufficiently covers the main purpose and usage context. It is complete for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. Description does not add additional meaning beyond what the schema provides. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it updates attributes of an existing payment link. It distinguishes from sibling tools like create_charge by specifying 'without creating another charge', and from update_charge_metadata by focusing on checkout experience options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use when the checkout experience or options need to be revised without creating another charge', providing clear context for use. It does not list alternatives but the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context: 'a mudança de estado impede que o fluxo de pagamento prossiga normalmente' (the state change prevents the payment flow from proceeding normally). This goes beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences that pack clear purpose and usage context. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that annotations and output schema exist, the description provides sufficient context: purpose, when to use, and behavioral effect. It does not mention prerequisites or error states, but the tool is simple with one parameter, so completeness is adequate.
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 the schema already documents the single required parameter 'id' with a basic description. The tool description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels an existing charge that can still be canceled, with a specific verb and resource. It distinguishes from sibling tools by noting the condition 'que ainda possa ser cancelada' (which can still be canceled), separating it from other charge operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use quando o débito não deve mais ser cobrado' (use when the debit should no longer be charged). It provides a clear context but does not mention when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool initiates a process requiring customer authorization via message, aligning with openWorldHint=true. It does not contradict annotations (readOnlyHint=false, destructiveHint=false). Could be more explicit about the state after initiation, but provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Front-loaded with purpose, then usage guidance. Every word 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?
Given the complex nested schema (covered by schema) and presence of output schema, the description provides sufficient context for onboarding. It notes the customer authorization step, which is key. Could mention async nature, but not critical.
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 parameters are well-documented. The description adds only a vague reference ('com os dados e acessos informados'), not enhancing parameter meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it initiates account opening for an Efí client with provided data and accesses. It specifies the verb 'inicia', resource 'conta Efí', and context 'onboarding'. It is distinct from siblings like 'create_account_certificate', which deals with certificates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises use during onboarding and notes that the customer must authorize integration via message. While alternatives are not mentioned, no other account creation tool exists among siblings, so context is clear. Lacks explicit when-not-to-use but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive (destructiveHint=false). The description adds that it does not change value, due date, or payment status, which aligns with annotations. No contradiction; it provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The purpose is front-loaded, and every sentence adds value. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and an output schema (not shown), the description adequately covers purpose, usage, and behavioral constraints. No major gaps given the low complexity.
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% with minimal but existent descriptions for each parameter. The tool description does not add new information about parameters beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Acrescenta uma descrição ao histórico') and the resource ('cobrança existente'). It distinguishes from sibling tools like 'create_carnet_history' by specifying 'charge history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use para registrar uma ocorrência operacional ou observação' and states what it does not alter ('sem alterar valor, vencimento ou estado de pagamento'). It does not name specific alternatives but gives clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a destructive, non-read-only operation. The description adds that it combines transaction and payment but does not elaborate on error behavior, rate limits, or authorization. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. First sentence states purpose, second provides usage guidance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested schema, multiple payment types) and presence of output schema, the description is adequate but minimal. It could briefly mention the two payment options (boleto vs. credit card) for completeness, but it sufficiently covers purpose and use case.
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 all parameters are described. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a transaction and payment method in a single operation (verb+resource+scope). It distinguishes from siblings like 'create_charge' by emphasizing 'em uma única operação' (single operation) and provides a condition for use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use: when all commercial and payer data are available to issue the charge immediately. It implies not to use when data is missing, guiding agents away from multi-step alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clarifies the non-destructive nature by stating it does not alter plan, payment method, or status, complementing the annotations (destructiveHint: false). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, usage, and behavior adequately. Output schema handles return values, so no missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and adequately describes parameters; description adds minimal additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'acrescenta' (adds) and the resource 'histórico de uma assinatura' (subscription history), clearly distinguishing it from sibling tools like create_charge_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs using this tool to record operational occurrences without modifying plan, payment method, or status, providing clear context for when to use it, though it does not mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-readonly behavior. Description adds that it operates on a pre-existing charge and 'only organizes the provided data', clarifying it does not compute or validate beyond organization. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives usage context. No redundant words, well front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema (not shown), so return values need no explanation. Description covers the action, precondition (charge exists), and result (produces billet with tabular content). Adequate for the complexity, but could mention that it modifies the existing charge.
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 baseline is 3. Description does not explain individual parameters beyond implying the body contains tabular content. No additional semantics beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool defines a previously created charge to produce a balance sheet billet and informs its tabular content. The verb 'define' and resource 'cobrança' are specific, and it distinguishes from sibling tools like 'define_pay_method' by specifying the 'balancete' layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use when the document needs this layout' and notes that Efí only organizes provided data. However, lacks explicit guidance on when not to use or alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'cria e associa', which aligns with the destructiveHint=true annotation. It adds context about forwarding the payer to checkout, enhancing the understanding of the tool's behavior beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and context. Every sentence adds value with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the prerequisite ('transação previamente criada') and the two-step flow. With output schema present and complete parameter docs, the description adequately covers the tool's role, though it could briefly note that the 'id' parameter refers to the existing transaction.
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 the schema already documents parameter details. The description does not add any additional meaning or context for the parameters beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('cria e associa um link de pagamento') and the context ('a uma transação previamente criada'). It also distinguishes from siblings by mentioning 'fluxo em duas etapas', which sets it apart from one-step tools like 'create_one_step_link'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use para concluir o fluxo em duas etapas', indicating when to use this tool. It implies that it is the second step after charge creation. However, it does not state when not to use or mention alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds value by specifying the tool returns installment status and confirms no alterations are made, reinforcing safe read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in Portuguese: first explains the action, second provides usage guidance. No redundant words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (stated but not shown), the description covers purpose, usage, and read-only nature sufficiently. It lacks mention of prerequisites (e.g., valid carnet ID), but that is implied for detail tools.
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% with a single parameter 'id' described as 'resource identifier'. The description does not add new parameter details beyond that; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries an existing installment plan and its installment status, explicitly distinguishing from mutation siblings by noting 'no changes are made'. The verb 'consultar' (query) aligns with read-only intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises use for tracking due dates, payments, write-offs, and cancellations, providing clear context. It implicitly excludes modification tools, though an explicit contrast with sibling mutation tools would strengthen it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds context about asynchronous processing ('verificar se o processamento terminou') which is beyond annotations, but does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key action and resource, and every sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the simple parameter, the description is largely complete. It covers the purpose and usage hint. However, it could explicitly mention that the 'id' is the report ID from create_report, but the sibling tool provides enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the 'id' parameter as 'Identificador do recurso.' The description does not add any extra meaning about the parameter beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for querying the status and data of a previously requested reconciliation report, using specific verbs ('consulta', 'verificar') and resource ('relatório de conciliação'). It distinguishes from siblings like create_report by specifying 'solicitado anteriormente'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs the agent to use this tool to check if processing has finished and to obtain data ('Use para verificar se o processamento terminou e obter as informações'). It implies the report must have been requested earlier, but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description reinforces that it does not alter the subscription and adds context about what data can be tracked (charges, payment, cancellation). No contradictions. It does not disclose further behavioral traits like rate limits or auth, but annotations cover the main safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage guidance. Every sentence adds value, with no extraneous information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query tool with an existing output schema, the description covers the purpose and usage context adequately. It could mention the output format but the schema handles that. The sibling differentiation is implicit. Nearly complete.
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% with the single 'id' parameter described as 'Identificador do recurso.' The description does not add any additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries subscription data linked to a plan, using the verb 'Consulta' and specifying the resource. It explicitly says 'without modifying the subscription,' which distinguishes it from mutation siblings like update_subscription and cancel_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: tracking recurring charges, payments, or cancellation. It implies not to use for modifications, but does not name alternative tools directly. Given the large sibling list, this guidance is helpful but could be more specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds important behavioral context: it retrieves sensitive credentials and warns to protect the response. This adds value beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and usage guidance. No wasted words. Every sentence 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?
Given the presence of an output schema and annotations, the description covers the essential information: what it retrieves (Client ID, Client Secret, integration data), when to use, and a security warning. It could mention error conditions but is sufficiently complete for a straightforward read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (idContaSimplificada) with 100% schema description coverage. The description does not add additional semantics beyond the schema's own description. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Recupera Client ID, Client Secret e dados de integração de uma conta simplificada', clearly specifying the verb (Recupera), resource (credenciais de conta simplificada), and scope. It is distinct from sibling tools which mostly deal with charges, payments, or configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description advises 'Use após a aprovação da conta e proteja a resposta', providing explicit context on when to use (after account approval) and a security warning. While it does not explicitly list alternatives or when not to use, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, aligning with the description's implication of a state-modifying action. The description adds context that the submission is 'complementar' and does not substitute ticket follow-up, which goes beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and includes essential usage guidance without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete given the tool's complexity, good schema, and annotations. It explains the tool's role and limitations. It could explicitly mention the relationship to 'med_list' or prerequisites like needing a ticket, but overall it is adequate.
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% with descriptions for all parameters. The description does not add parameter-specific details beyond what is already in the schema, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Envia uma defesa para uma infração específica do Mecanismo Especial de Devolução.' It specifies the resource (infração MED) and the action (defense submission). Among siblings like 'med_list', this tool is distinct for submitting defenses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance: 'Use para complementar a análise; o envio não substitui o acompanhamento e documentos solicitados por ticket.' This tells when to use it (as a complement) and what it does not replace (ticket processes). It does not name alternative tools but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds the important condition 'quando seu estado permitir'. No contradictions. However, lacks details on success/failure responses or side effects beyond the state condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous words. Front-loaded purpose and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description adequately explains input and state condition. Minor gap: no mention of idempotency key behavior, but it's optional and schema covers it.
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 covers 100% of parameters with descriptions. The tool description does not add further meaning to the parameters, but baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose as canceling an automatic Pix payment when state permits, using specific verbs like 'cancelar' and 'impedir execução pendente'. It distinguishes from enrollment changes, avoiding confusion with 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('impedir uma execução pendente') and when not to ('adesão deve ser tratada separadamente'). Provides clear user guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description confirms cancellation of recurrences. It adds that the operation depends on the state and that executed payments are not undone, providing useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second explains usage scope. No redundancy, front-loaded with key information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, the description need not detail return values. It covers the operation's scope well. With moderate complexity and good annotations, it is sufficiently complete.
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 the baseline is 3. The description does not add meaning beyond the schema; parameters are not elaborated upon. Adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'cancela uma recorrência Pix' and specifies the resource (Open Finance recurrence) and condition (when state permits). It distinguishes from sibling tools like 'pix_create_recurrence_automatic' by focusing on cancellation.
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?
Describes when to use: to prevent future executions of the series, and clarifies that completed payments are not affected. While it doesn't explicitly state when not to use, the context is clear enough among many similar cancellation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true already indicates mutation, but the description adds important context: cancellation depends on the payment state ('quando seu estado permitir') and should be done before execution. This goes beyond the annotation's binary flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, directly stating the action and usage guidance. No extraneous words. Front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full schema coverage, the description is largely sufficient. It covers purpose and usage timing. It could be more explicit about prerequisites or error scenarios, but for a cancel operation, it is adequately complete.
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 the baseline is 3. The tool description does not add any extra meaning beyond what the schema already provides for the two parameters. No additional parameter guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cancela' and the resource 'pagamento Pix agendado iniciado via Open Finance', identifying the specific transaction type. It distinguishes from similar siblings like of_cancel_recurrency_pix by specifying 'agendado' (scheduled).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use antes da execução para impedir a movimentação prevista' (use before execution to prevent the planned movement), providing clear timing context. However, it does not explicitly mention alternatives or when not to use this tool, though the condition 'quando seu estado permitir' implies state-dependent applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by warning 'pois há movimentação de recursos', which aligns with the destructiveHint: true annotation. No contradictions, but could disclose more about reversibility or auth needs.
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: first states purpose, second gives usage guidance. No extraneous words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is part of a complex recurrency system, the description is adequate but could include more detail on prerequisites or effects. Nevertheless, it is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description does not add additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Solicita a devolução' and the resource 'pagamento executado dentro de uma recorrência Open Finance'. It distinguishes from siblings like 'of_devolution_pix' by specifying it's for a recurrency payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use: 'após identificar a parcela e conferir o valor' and warns about fund movement. It provides clear context but does not explicitly mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description's 'lista' (lists) is consistent but adds no new behavioral context beyond the annotations. The description does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many sibling tools) and presence of output schema and nested objects, the description sufficiently covers purpose and usage. It does not detail return structure, but the output schema handles that. Minor gap: could mention that it lists only completed/biometric payments, but overall complete.
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% (all 4 parameters have descriptions). The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Pix payments made via biometric journey without redirection. It uses specific verb 'Lista' and resource 'pagamentos Pix por biometria', distinguishing it from sibling tools like of_start_pix_payment and of_list_pix_payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool for monitoring and conciliation ('Use para acompanhar processamento e conciliar operações') and warns against initiating another payment ('sem iniciar outro pagamento'), providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior; the description adds that changes may affect future payments, which is valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information; the purpose is front-loaded and every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's function and effect, and the output schema is assumed to handle return values. It could mention that an existing enrollment must exist, but the required identifier parameter implies this.
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 baseline is 3. The description does not add additional meaning to parameters beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Edita' (edits) and resource 'adesão de pagamento automático Open Finance', distinguishing it from sibling tools like of_create_automatic_enrollment or of_list_automatic_enrollment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context 'Use para revisar a autorização existente' indicating it's for updating existing authorizations, but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds value by stating that the operation can move balance ('pode movimentar saldo') and implies the need for prior verification. No contradictions with annotations. Could mention more about failure modes or idempotency, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: first states purpose, second provides crucial usage warning. No unnecessary words, front-loaded. Efficiently communicates essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema and detailed annotations, the description covers key behavioral aspects (destructive, needs verification). It lacks explicit mention of idempotency or return structure, but overall adequate for a payment tool. Slight ambiguity in 'solicita pagamento' is clarified by balance warning.
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%, with all parameters adequately described in the input schema (e.g., 'codBarras', 'valor'). The tool description does not add additional parameter context beyond the schema. Baseline of 3 is appropriate per scoring guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Solicita o pagamento de uma conta identificada por código de barras', specifying the verb (solicitar pagamento) and resource (conta com código de barras). It distinguishes from sibling tools like 'pay_detail_bar_code' which only details, and the warning adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage guidance: 'Use somente depois de consultar e conferir os dados do título, pois a operação pode movimentar saldo.' This tells when to use (after consulting bill data) and warns about side effects. However, it does not mention alternatives or when not to use, so not 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?
Annotations already indicate destructive and idempotent behaviors. The description adds context about prerequisites (endpoint preparation) and the replacement effect, but does not detail response or error conditions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. The description is front-loaded with the core action and efficiently includes usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the comprehensive annotations and the presence of an output schema, the description adequately covers prerequisites and the replacement behavior. It could mention idempotency or that a successful response confirms the webhook is set, but it remains fairly complete.
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% with clear parameter descriptions. The description does not add additional meaning beyond what the schema already provides for 'webhookUrl' and 'chave'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a webhook URL for Pix events associated with a key, using specific verbs and resources. It distinguishes itself from sibling tools like pix_list_webhook or pix_delete_webhook by focusing on configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises use after preparing the callback endpoint with security requirements and notes that it replaces the applicable destination. However, it does not explicitly contrast with alternative tools or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this tool is not read-only (readOnlyHint=false), is state-changing (openWorldHint=true), idempotent (idempotentHint=true), and not destructive (destructiveHint=false). The description adds that the txid is defined by the receiver, which is a useful behavioral detail beyond annotations. However, it does not disclose other side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no redundant words. It front-loads the primary action and then provides a clear usage condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input (nested objects) and the presence of an output schema, the description provides sufficient high-level context for selecting the tool. It could benefit from summarizing the required nested structures, but the schema already details those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that the txid is defined by the receiver and that the tool involves 'data de vencimento e das regras financeiras,' which maps to calendario and valor fields, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cria' (creates), the resource 'cobrança Pix com vencimento' (Pix charge with due date), and specifies the use of a txid defined by the receiver. This distinguishes it from sibling tools like pix_create_immediate_charge, which lack due date constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use quando a cobrança precisar de data de vencimento e das regras financeiras admitidas para cobranças desse tipo.' It does not explicitly mention alternatives or when not to use, but the context of sibling tools implies them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint (false), destructiveHint (false), and idempotentHint (true). The description adds that the operation 'altera o conteúdo integral do lote' (changes the entire content of the batch), providing context about full replacement. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, each providing essential information. It is front-loaded with the verb and resource, and there is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It covers the purpose, usage, and behavioral trait of full batch replacement. Could mention authentication requirements, but that is typical and not mandatory.
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% with detailed descriptions for all parameters. The description adds a high-level summary ('várias cobranças coordenadas') but does not provide additional semantic value beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or replaces a batch of due Pix charges under an identifier. It specifies the verb (cria ou substitui), resource (lote de cobranças Pix com vencimento), and distinguishes from single-charge tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use para registrar várias cobranças coordenadas' (use to register multiple coordinated charges), indicating when to use it. However, it does not explicitly mention alternatives like pix_create_due_charge for single charges or pix_update_due_charge_batch for partial updates, which are siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not idempotent, and has open world effects. The description adds that the txid is auto-assigned by Efí, which provides useful behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, succinct and front-loaded. The first sentence states the action, the second provides usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested input schema and presence of an output schema, the description focuses on the key differentiator (auto-assigned txid) and use case. It is slightly brief but sufficient for tool selection, as the schema handles parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description provides no additional information about parameters beyond what the schema already includes, so it does not enhance understanding of the input fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an immediate Pix charge and lets the system assign the txid. It also distinguishes from siblings by specifying 'without txid' in the title and describing the use case for when the application doesn't need to pre-select the identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the application does not need to previously choose the charge identifier,' providing clear context for when to use this tool. It implies alternatives for when a specific txid is needed but does not name them explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds that the tool creates a location for a Pix recurrence payload, which is useful but does not disclose any additional behavioral traits beyond the creation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and usage context without any fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema (not shown), the description adequately covers the creation purpose and proper usage timing. Could be more detailed about return value, but output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema_description_coverage is 100%. No parameter information is needed, and the description does not repeat what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cria uma location destinada ao payload de uma recorrência de Pix Automático' which specifies the action (cria), resource (location), and context (recurrence), distinguishing it from sibling tools like pix_create_location.
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 instruction 'Use antes de associar a recorrência e apresentar seu QR Code ao pagador' provides clear when-to-use guidance. It lacks explicit when-not-to-use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and idempotentHint=true. The description adds that the same EVP cannot be recreated and linked charges may stop working, which provides additional behavioral transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It is front-loaded with the core purpose and includes essential warnings efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the simple single-parameter input, the description adequately covers the irreversible nature and potential side effects. It is complete for a delete 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?
The input schema has 100% coverage and describes the 'chave' parameter as 'Chave Pix associada à operação.' The description does not add new information about the parameter, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a random Pix key (EV) and specifies the consequence: it cannot be recreated. This distinguishes it from sibling tools like pix_create_evp and pix_list_evp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: use only when the key should no longer receive payments. While it does not list alternatives, it provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the tool is for accompaniment without modification, complementing the readOnlyHint annotation. No contradictions; behavioral traits are transparent and consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no redundancy. Every word adds value; it is concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the readOnlyHint and presence of an output schema, the description covers the essential use case. It specifies the charge type (imediata) which is important among many Pix charge siblings. Could mention prerequisites (e.g., charge must exist) but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already explains txid and revisao. The description adds that it retrieves data, revision, and state, which adds marginal value but does not go beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults by txid the data, revision, and state of an immediate Pix charge. It distinguishes from siblings by specifying 'imediata' and emphasizing no modification, which aligns with readOnlyHint.
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 says to use it to monitor payment or removal without modifying, providing clear context. It does not explicitly name alternative tools, but the sibling list offers many creation/update tools that would be used instead for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds value by explaining the result (associação atual) and the context (verify vinculação with a charge). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action verb 'Consulta', and no unnecessary words. Each sentence 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?
Given the output schema exists, the description is adequate. It explains the purpose and usage context. It could potentially elaborate on what 'associação' means, but it is complete enough for a detail tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'id' described as 'Identificador do recurso.' The description does not add extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it consults a Pix location by identifier and reports its current association, with a specific use case: verifying vinculação before generating or reusing QR Code. This distinguishes it from sibling tools like pix_create_location or pix_location_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for...' providing clear context on when to use (before generating/reusing QR Code). It doesn't mention when not to use or compare to alternatives, but the guidance is sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open world. The description adds the behavioral context of confirming the binding without alteration, which is valuable beyond the annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first sentence states purpose, second gives usage guidance. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations and an output schema, the description covers purpose, usage, and behavioral traits sufficiently. It does not detail return values, but the output schema likely handles that. Complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'chave' parameter with 100% coverage. The description does not add additional meaning or context for the parameter beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it consults the webhook configuration for a Pix key. It distinguishes from siblings by focusing on querying and confirming the URL and binding without altering the configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: to confirm URL and creation of the binding before depending on notifications. It implies it's a safe, read-only operation. While it doesn't name alternative tools, the sibling names like pix_config_webhook and pix_list_webhook make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description carries a lower burden. It adds that the tool retrieves a PDF, which is consistent with read-only behavior. No contradictory information is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and has no redundant or superfluous information. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (though content unknown) and comprehensive annotations, the description is adequate. It explains the tool's core function and intended use, though it omits details like supported identifiers (handled by schema) and output format (partially mentioned as PDF).
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 the description mentions 'usando um de seus identificadores aceitos,' but this adds little beyond what the schema already provides through the anyOf structure and per-field descriptions. The description does not deepen parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool obtains a PDF receipt of a Pix transaction using accepted identifiers. It distinguishes itself from sibling tools (e.g., pix_detail_charge, pix_send_detail) by focusing on receipt delivery/archival, which is a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use para entregar ou arquivar a evidência de uma operação já realizada,' providing clear context for when to use the tool. While it does not explicitly exclude alternatives, it implies the need for an identifier and the purpose of evidence delivery, which is sufficient 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?
Annotations already declare readOnlyHint=true, so the description's explicit statement 'sem modificar as cobranças encontradas' reinforces safety. No contradictions. Could add more about idempotency or side effects, but annotations cover key traits.
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: first defines purpose, second adds usage guidance. No redundant words. Every sentence serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are robust, the description covers purpose and safe usage. It could mention pagination or differentiate from similar list tools, but it already specifies 'with due date,' which is sufficient for basic 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 the schema already documents each parameter. The description adds no parameter-level detail beyond 'com os filtros informados.' Baseline 3 is appropriate; it does not detract but adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Lista cobranças Pix com vencimento no período e com os filtros informados.' It specifies the verb (list), resource (Pix charges with due dates), and scope (period and filters). Distinguishes from siblings like pix_list_charges by focusing on due charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description says 'Use em rotinas de acompanhamento e conciliação sem modificar as cobranças encontradas.' It provides context (monitoring/reconciliation) and explicitly states it does not modify charges. However, it does not compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, and idempotent behavior. The description adds that it decodes, retrieves, and verifies (including 'when available'), and explicitly warns that the result does not authorize payment, providing valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a usage sentence, both front-loaded with critical information. Every word is meaningful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality (decoding, retrieval, verification) and includes an important caveat. An output schema exists, so return values are documented elsewhere. The tool is moderately complex, and the description provides adequate 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% and the schema already describes the parameter 'pixCopiaECola' in detail. The description repeats 'Pix Copia e Cola' but adds no new semantic meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool decodes a Pix Copia e Cola, retrieves the dynamic charge, and verifies the JWS signature. It clearly identifies the specific resource and action, distinguishing it from other pix tools like pix_qr_code_pay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool for inspection and states that an invalid or unavailable result does not authorize payment, providing clear context for when to use it. It does not explicitly list when not to use it, but the guideline is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the configured endpoint may receive already emitted events again, which adds behavioral context beyond annotations. Annotations indicate non-idempotent and non-destructive, which aligns with this replay behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, clear schema, output schema exists), the description covers purpose and use case adequately. It could mention prerequisites (e.g., configured webhook), but it is largely complete.
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%, but schema descriptions are generic (e.g., 'Tipo do recurso ou da operação'). The tool description does not add additional parameter meaning, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resends Pix webhook notifications within a specified cut, distinguishing it from sibling webhook tools by specifying the use case of recovering unprocessed callbacks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use to recover unprocessed callbacks,' providing a clear condition for use. However, it does not clarify when not to use or compare to similar webhook tools like pix_detail_webhook or pix_delete_webhook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description reinforces that the tool does not move values, which adds behavioral context beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states what the tool does, second states its use case. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and clear annotations. The description covers purpose and usage adequately. It does not mention pagination details, but those are in the schema.
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% with descriptions for each parameter. The description summarizes filtering by period and filters but adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists sent Pix transfers with period and filters. It distinguishes from siblings like 'pix_received_list' and 'pix_send' by specifying 'enviadas' (sent) and 'sem movimentar valores' (without moving values).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use para acompanhamento e conciliação de saídas sem movimentar valores', providing clear context for when to use it (monitoring and reconciliation) and implying it should not be used for executing transfers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description does not need to repeat those. The description adds useful behavioral context: it defines participants and distribution criteria, and should be used before linking. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences in Portuguese, effectively communicating the purpose and usage without any redundant information. It is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's purpose and when to use it. Although it does not describe return values, an output schema exists to cover that. Given the tool's complexity (nested objects), the description is complete enough for an agent to understand its role and prerequisites.
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 the baseline is 3. The description adds general context ('define participantes e critérios de distribuição') but does not provide additional meaning beyond what is already detailed in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cria' (creates), the resource 'configuração de split' (split configuration), and the context of use before linking to Pix charges. It distinguishes from sibling tools like pix_split_link_charge by specifying that this tool is for creation only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: 'Use antes de vinculá-la a cobranças Pix que devam repartir valores recebidos.' This implies that the tool should be used before linking to charges that need splitting. While it doesn't explicitly state when not to use it, the context is clear from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that the operation moves funds and adjusts related transfers ('movimenta recursos e ajusta os repasses relacionados'), which aligns with annotations (destructiveHint=true). It adds context beyond annotations by specifying the effect on split distributions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by usage guidance. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description adequately covers the tool's purpose and behavioral impact. It misses potential prerequisites like configuration, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all parameters, so the description adds no additional 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Solicita a devolução de um Pix recebido que teve distribuição por split'), specifying a distinct verb and resource. It differentiates from sibling 'pix_devolution' which handles non-split Pix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using after verifying the transaction and value ('Use após conferir a transação e o valor'), providing context for safe usage. It implicitly excludes non-split refunds (handled by sibling) but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and idempotent behavior. Description adds timing context (use before payment) and that it links an existing configuration, extending beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 30 words, no fluff. Action and guidance front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, output schema exists), description covers purpose and usage timing. Minor missing details like error cases but overall sufficient.
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% with descriptions for both parameters. Tool description does not add further parameter detail; baseline of 3 is appropriate as schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it links an existing split configuration to a Pix charge with due date, using specific verb and resource. It distinguishes from siblings like pix_split_link_charge by specifying 'due charge' (vencimento).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use before payment to distribute received amount. No explicit alternatives or when-not-to-use, but context with siblings implies distinction for due vs. immediate charges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it states that the QR Code stops representing that link. Annotations include destructiveHint=true and idempotentHint=true, which are consistent. The description clarifies the behavioral impact on the QR Code.
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 that are front-loaded and contain no extraneous information. Every sentence serves a purpose: first defines the action, second provides usage guidance in a concise manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema (not shown but exists), the description adequately covers the purpose and usage. It could mention the return value or side effects, but it is complete enough for the 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?
The input schema has 100% coverage, so the baseline is 3. The description does not add meaning to the 'id' parameter beyond the schema's generic 'Identificador do recurso'. It implies the id is the location identifier but does not explicitly state that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'vínculo entre uma location e o txid de sua cobrança Pix'. It specifically identifies the action and the entities involved, distinguishing it from siblings like 'pix_unlink_location_recurrence_automatic' which deals with recurrence locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'antes de reutilizar a location ou encerrar a associação'. This tells the agent the context for invocation. However, it does not mention when not to use it or alternatives, but the given context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, which is consistent with the update behavior. The description adds value by noting the state-dependent constraint, but does not elaborate on side effects or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and usage condition. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers the tool's role. It could elaborate on which fields are 'allowed' for update, but the overall information suffices for the tool's complexity.
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 the schema already details parameters. The description adds marginal value by hinting at 'allowed fields', but does not specify which fields are mutable or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an immediate Pix charge identified by txid, specifying it modifies allowed fields while state permits. The term 'imediata' distinguishes it from due charge tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool when the charge state allows changes, providing clear context. However, it does not exclude scenarios or mention alternatives, which is acceptable given the specific naming.
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?
Adds value beyond annotations by confirming no new creation occurs (non-destructive). Annotations already indicate non-destructive, but description reinforces the resend-only behavior, enhancing understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existence of an output schema, the description covers purpose, usage scenario, and limitations adequately. Could be more detailed about side effects, but sufficient.
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% for both parameters, so baseline is 3. Description does not add additional meaning beyond the schema's basic descriptions for 'email' and 'id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resends an existing payment link email for a charge, using specific verbs and resource. It distinguishes from siblings like 'send_subscription_link_email' by specifying 'already created for a charge'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when the payer did not receive or lost the original message. Also clarifies that no new link or charge is created, helping avoid misuse. Doesn't explicitly mention alternatives but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the write nature and financial impact ('efeito financeiro'), which aligns with annotations (destructiveHint: true, readOnlyHint: false). It adds context beyond annotations by explaining the condition for use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first defines the action, the second provides usage guidance. No redundant information; front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter) and presence of output schema, the description covers essential context. It mentions financial effects but could elaborate on reversibility or return values for full 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 coverage is 100% with descriptions in the input schema, so baseline is 3. The tool description does not add any meaning beyond the schema's parameter descriptions, e.g., not specifying that 'id' refers to the charge ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool marks a charge as paid manually, specifying the verb and resource. It distinguishes from siblings like cancel_charge by emphasizing it's for external payments. The title 'Dar baixa manual em uma cobrança' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: only when payment was received by another means and the status needs to be reflected in Efí. This provides clear context, though it doesn't mention alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true (modifies data) and idempotentHint=true. The description adds context that it does not create a new carnet or alter installment payments, which clarifies the scope of modification. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences: the first states the action, the second provides use case context. It is front-loaded and efficient, though could be slightly more concise. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (update metadata with two parameters) and the presence of an output schema, the description covers the essential purpose, scope, and what actions are not taken. No gaps remain for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters (id, custom_id, notification_url). The description does not add additional meaning beyond what is in the schema. Baseline score of 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates integration metadata of an existing carnet (payment plan). It specifies the use case: correcting references or notification information without recreating the carnet or altering installment payments. This distinguishes it from sibling tools like create_carnet, update_carnet_parcel, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use this to fix integration metadata without recreating the carnet or affecting installments. It implies when to use but does not explicitly state when not to use or provide alternative tools. However, the positive context is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds value by explaining that the change affects the charge presented for that installment, providing behavioral context beyond what annotations offer. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no wasted words. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, output schema, and simple parameters, the description is complete enough. It covers purpose, usage guidance, and effect. Could mention what 'allowed data' entails, but schema covers it.
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 the description does not need to elaborate on parameters. It adds no extra meaning beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates allowed data of a specific carnê installment. It specifies it's for a single due date needing revision, which distinguishes it from siblings like update_carnet_parcels (plural).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool when only one due date needs revision, implying it is not for multiple. It provides clear context but does not explicitly name alternative tools, though the sibling list includes alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by stating changes affect future generations. Annotations already indicate destructiveHint: true and readOnlyHint: false, but the description clarifies the scope of the mutation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose. Every sentence adds value without redundancy. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the schema and output schema (present), adequately covers the tool's purpose and effects. It could include more detail on prerequisites or constraints, but it is sufficient for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds little semantic value beyond the schema, only hinting at which parameters relate to frequency or delivery. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('atualiza' - updates) and the resource ('recorrência de extrato CNAB 240'). It explicitly mentions adjusting frequency or delivery, distinguishing it from sibling tools like create_statement_recurrency and list_statement_recurrences.
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 states to use it for adjusting frequency or delivery and notes that changes affect future generations. It implies it is for existing recurrences but does not explicitly state when not to use it or mention alternatives. The context is clear enough given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it only cancels that specific parcel, not the whole carnê. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states action, second provides usage context. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and output schema available, the description covers what the tool does and when to use it. Additional details about return values are not needed due to output schema.
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% with clear parameter descriptions. The tool description does not add additional semantics beyond what the schema provides, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it cancels a specific parcel of a carnê without canceling others, using the verb 'Cancela' and resource 'parcela específica de um carnê'. It distinguishes from siblings like cancel_carnet (whole carnê) and cancel_charge (generic charge).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'Use quando somente aquele vencimento não deve mais ser cobrado do pagador.' It doesn't mention when not to use or list alternatives, 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?
Annotations already indicate non-readonly and non-destructive. The description adds valuable context: the output is a secret (P12 base64) and must be treated as such, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the purpose, followed by usage guidance and security note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, existing output schema, and annotations, the description covers the essential purpose, precondition, output format, and security handling. No gaps identified.
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 the parameter description in the schema is adequate. The tool description does not add additional meaning to the parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a certificate for a simplified account, specifies the precondition (account already created and ready), and distinguishes from siblings like create_account by dealing with certificates. The verb 'gera' and resource 'certificado' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use após a conta estar apta' (use after account is ready), providing clear usage context. However, it does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description reinforces read-only behavior and adds context about included data (payment method, status). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose and usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-ID lookup tool with an output schema, the description covers the needed context: what data is returned and that it is read-only. No 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%; the only parameter 'id' is described as 'Identificador do recurso.' Description does not add further semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries current data of a charge including payment method and status. The verb 'consultar' (query) and resource 'cobrança' are specific, and the read-only nature distinguishes it from mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for monitoring processing/payment/cancellation without modification. However, it does not explicitly exclude alternatives among the many sibling tools (e.g., pix_detail_charge).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint; description adds context about what it returns (Pix rules, keys) and purpose (check receipt/notification behavior). No contradictions, but adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first describes action, second gives usage guidance. No wasted words, front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, complete annotations, and presence of output schema, the description is sufficient. It covers purpose and when to use, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; description doesn't need to add anything. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns Pix rules for the account and keys, with a specific verb 'retorna' and resource. It distinguishes itself from the sibling 'update_account_config' by implying it's the read-only counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it before altering settings ('antes de alterá-lo'), providing clear context. Does not explicitly mention when not to use, but the sibling tool name implies the alternative for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and side-effect-free behavior. The description adds that the tool returns recurrence data and current configuration, enriching the behavioral model. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences in Portuguese, front-loaded with the core action and resource. Every sentence adds value: the first states what it does, the second specifies when to use it. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema (with nested objects) and annotations covering idempotency and safety, the description effectively provides the remaining context: recurrence data and usage scenarios. It is complete for a list/query tool of this complexity.
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?
Input schema coverage is 100% with descriptions for all parameters (name, limit, offset). The description does not add significant detail beyond the schema, but it hints at using the name parameter to find the appropriate plan, which provides minor additional context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists registered subscription plans and their recurrence data, using the verb 'Lista' and resource 'planos de assinatura'. It differentiates from sibling tools like create_plan, delete_plan, and create_subscription by specifying its role in finding the appropriate plan before creation or querying current configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to locate the right plan before creating a subscription or to consult current settings, providing clear context. It does not explicitly state when not to use it, but the guidance is specific and covers primary use cases, so it meets a high standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, covering safety. The description adds that files are 'já gerados' (already generated) and lists them for the account, but does not disclose additional behavioral traits beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words. Front-loaded with the action and followed by usage guidance. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an existing output schema, and annotations covering safety, the description fully explains the tool's purpose and when to use it. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description does not need to add parameter details; its lack of parameter explanation is acceptable. Baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists generated CNAB 240 statement files for the account, which is a specific verb-resource combination. It distinguishes from sibling tools like get_statement_file by mentioning it is used before downloading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use the tool: 'Use para localizar períodos disponíveis para conciliação antes de solicitar o download de um arquivo.' This provides clear context, though it does not list explicit when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds context about verifying frequency and delivery but does not disclose additional behavioral traits such as pagination or result limits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence states the tool's primary function, and the second provides guidance on when to use it. There is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is complete. It covers the tool's purpose and usage context without requiring additional detail about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has no properties. The description does not need to explain parameters since none exist. Schema description coverage is 100%, so the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists recurring CNAB 240 statement generation schedules ('agendamentos recorrentes de geração de extrato CNAB 240'), which directly names the resource and action. It also distinguishes from sibling tools like create_statement_recurrency and update_statement_recurrency by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use para verificar frequência e entrega antes de criar ou revisar uma recorrência,' providing a specific use case. It gives clear context for when to use the tool (before creating or revising a recurrence), but does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds that it fetches URLs for redirects and callbacks, providing some behavioral context but not deeply detailing side effects or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then adding a usage note. Every word is necessary; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema is present, the description sufficiently explains what the tool does (returns redirect/callback URLs) and when to use it (pre-payment validation). No further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (0 params, 100% schema coverage). With no parameters to describe, a baseline score of 4 is appropriate. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Consulta') and resource ('URLs configuradas para redirecionamentos e callbacks Open Finance'), clearly stating what the tool does. It also distinguishes itself from sibling tools like 'of_config_update' by focusing on reading configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use para validar a integração antes de iniciar uma jornada de pagamento.' This gives clear context on when to use the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's statement 'sem alterar a cobrança' aligns and adds context about output (agenda, tentativas, estado). This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and resource, no unnecessary words. Perfect structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema, the description is complete: it explains the purpose, usage, and non-destructive behavior. No missing critical information.
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%, with one parameter 'txid' described as 'Identificador da cobrança Pix.' The description mentions 'txid' but adds no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries a charge by txid associated with a Pix Automático recurrence, specifying the resource (charge with recurrence) and action (consultar). It distinguishes from siblings by targeting automatic recurrence charges, unlike generic pix_detail_charge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: monitoring schedule, attempts, status without altering. It implies read-only use, but does not explicitly contrast with sibling tools like pix_detail_charge or pix_update_automatic_charge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint. Description adds that the tool is for 'Pix recebido' (received Pix) and that it does not create or move values. This complements the annotations with domain-specific context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first sentence states purpose, second gives usage and behavioral guidance. Front-loaded, no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage scope (received Pix, existing devolution), and safety (read-only, no creation). Output schema exists but is not needed for the description to be complete. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with descriptions for e2eId and id. The tool description does not add further semantic value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Consulta o estado e os dados de uma devolução já solicitada para um Pix recebido', with specific verb 'consulta' and resource 'devolução já solicitada'. It distinguishes from sibling tools like pix_devolution by specifying it queries an existing return rather than creating one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use para acompanhar seu processamento sem criar outra devolução ou movimentar valores', providing clear context for when to use (monitoring) and when not to (creating). Does not name alternatives directly, but the sibling pix_devolution is implied from the contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As anotações já declaram readOnlyHint=true e idempotentHint=true. A descrição adiciona contexto útil: 'sem modificar o lote' e menciona 'processamento e revisões', reforçando o comportamento read-only. Não há contradição com as anotações, e a descrição agrega valor semântico além do que as anotações fornecem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A descrição é curta (duas frases, 23 palavras em português), vai direto ao ponto da consulta, sem verbosidade ou repetições. A informação essencial está na primeira frase, e a segunda complementa o contexto de uso. Nenhum desperdício.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considerando que existe um esquema de saída (que explica os valores retornados) e anotações ricas (readOnly, idempotent), a descrição fornece o contexto necessário para um agente entender o que a ferramenta faz e quando usá-la, sem lacunas significativas. A menção a 'processamento e revisões' é relevante para o domínio.
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?
O esquema de entrada tem cobertura de 100% (o parâmetro 'id' possui descrição 'Identificador do recurso.'), então a linha de base é 3. A descrição não adiciona informações adicionais sobre o parâmetro além do que já está no esquema, mantendo a nota padrão.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição afirma claramente que a ferramenta 'consulta pelo identificador um lote de cobranças Pix com vencimento e seus itens', especificando verbo (consulta) e recurso (lote de cobranças). Isso a distingue de ferramentas irmãs como pix_create_due_charge_batch e pix_update_due_charge_batch, que são de criação e atualização.
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?
A descrição orienta: 'Use para acompanhar o processamento e as revisões sem modificar o lote', deixando claro o contexto de uso (acompanhamento apenas leitura) e implicitamente quando não usar (se precisar modificar). Embora não mencione alternativas específicas entre os irmãos, a orientação é clara o suficiente para um agente.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) already establish safety and idempotence. The description adds concrete details about confirmable fields (value, time, payer, returns), enriching the behavioral expectations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the action and key identifier, second provides usage guidance. No unnecessary words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations (read-only, idempotent, open world), schema (100% parameter coverage), and existence of an output schema, the description is complete. It clearly explains what the tool does and what information it provides, leaving no 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 descriptions cover both parameters (e2eId and exibirCodigoBanco) at 100% coverage. The description adds no parameter-specific meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries a specific Pix receipt by end-to-end identifier. It specifies the action ('consulta'), the resource ('recebimento Pix'), and what details it confirms (value, time, payer, returns), distinguishing it from listing or sending tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use para confirmar...' indicating when to use it. While it doesn't list alternatives like pix_received_list or pix_send_detail, the context from siblings and the phrase 'de uma transação já recebida' clarifies the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description reinforces that the tool does not modify the recurring agreement, which aligns with readOnlyHint. It adds value by specifying the aspects consulted (authorization, state, parameters). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no filler. The first sentence states the core purpose, the second provides usage guidance. Every word is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and an output schema (indicated), the description covers the essential aspects: purpose, when to use, and behavioral note (no modification). It is complete and sufficient for an agent to select and invoke the tool 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?
Only one parameter (idRec) with a schema description that explains it is the identifier. The tool description itself does not elaborate further, but schema coverage is 100%, so the baseline is appropriate. The description does not add additional semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: consulting a recurring automatic Pix payment by its identifier. It specifies the action (consultar) and the resource (recorrência de Pix Automático). The phrase 'Use para acompanhar autorização, estado e parâmetros vigentes sem modificar o acordo recorrente' further clarifies its read-only monitoring role, distinguishing it from modification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: monitoring authorization, status, and current parameters without modification. This implies when to use it (for read-only checks) but does not explicitly name alternatives or state when not to use it. Given the large sibling list, explicit differentiation would be beneficial, but the guidance is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds that it lists only random type keys on the authenticated account, which is useful but not extensive.
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 efficient sentences, no waste, front-loaded with purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations covering safety, the description is complete for a simple list tool, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description correctly adds no additional param info. Baseline score of 4 for 0 parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' and the resource 'chaves Pix do tipo aleatória', distinguishing it from other Pix key tools like create or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool to inventory available EVPs before configuring charges or webhooks, providing clear context without explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it states that the operation 'movimenta saldo da conta' (moves account balance), aligning with destructiveHint=true and readOnlyHint=false. It also implies a prerequisite of validation, which annotations do not cover. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the core action and required inputs. Every sentence adds essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter documentation, the description covers the essential context: what the tool does, when to use it (after validation), and its effect (balance movement). No critical 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 the schema fully documents each parameter. The description mentions 'Pix Copia e Cola' and 'identificador de envio', corresponding to pixCopiaECola and idEnvio, but does not provide additional detail beyond the schema. This adds marginal value, warranting a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to request payment of a QR code via its Pix Copy and Paste code and a sending identifier. It specifies the verb 'Solicita o pagamento' and the resource 'QR Code', distinguishing it from sibling tools like pix_send or pix_create_charge which handle other payment initiation methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage instruction: 'Use após validar os dados do recebedor e o valor' (Use after validating the receiver's data and the amount). This tells the agent when to invoke the tool, though it does not explicitly mention when not to use or suggest alternatives among the many pix sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral context by stating it is for confirmation without initiating a new transfer, and lists specific data points (processing, recipient, value, returns). This provides value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every sentence adds value. No redundant or verbose language. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers purpose, usage context, and behavioral notes. It is fully sufficient for an agent to select and invoke the tool 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 description coverage is 100% for the single required parameter (e2eId). The description does not add new semantic details about the parameter's format or source, so it meets the baseline expectation without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it consults a sent Pix using its end-to-end ID, with a specific verb and resource. It distinguishes from siblings like pix_send and pix_send_list by focusing on detail retrieval. The additional purpose of confirming processing, recipient, value, and returns without initiating another transfer further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool to confirm details without starting a new transfer, providing clear context. However, it does not explicitly exclude or compare with similar tools like pix_detail_charge, which slightly limits guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so behavior is well-defined. Description adds that it monitors processing, but does not contradict annotations. Adds minor context beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose is front-loaded, and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with an output schema, the description covers purpose, usage, and parameter context completely. No missing information.
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%, so parameters are fully documented in schema. Description adds meaning by explaining the identifier is 'atribuído pela aplicação no envio', clarifying its origin, which goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries a Pix transfer by the application-assigned identifier, distinguishing it from sibling tools like pix_send_detail that may use a different identifier. It specifies the resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (to monitor processing, beneficiary, amount without initiating a new transfer). Context is clear, but no explicit when-not-to-use or alternatives beyond implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only, non-destructive, non-idempotent. The description adds behavioral nuance: the created subscription is in an incomplete state (without payment method), which is beyond basic mutation flags. No side effects or error conditions disclosed, but annotations suffice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences that convey the core purpose and usage context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (confirmed) and annotations, the description sufficiently explains the tool's role in the two-step flow and required state. It could mention prerequisites like an existing plan, but that is implied. Overall adequate for agent decision-making.
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% with descriptions for all parameters. The description hints at the plan id and incomplete payment state but does not add syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a subscription linked to an existing plan without completing payment method, using a specific verb and resource. It distinguishes from siblings like create_one_step_subscription by positioning itself in a two-step flow before payment data association.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use no fluxo em duas etapas antes de associar os dados de cobrança do assinante' maps the tool to a specific sequence and alternative (create_one_step_subscription). Contextually clear when to use vs siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds behavioral context: it lists payments without creating new ones, and tracks statuses. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, directly conveys purpose and usage. Efficiently written.
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?
Description is adequate for a list operation with good annotations and output schema present. Could mention pagination or status enumeration but not essential.
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 parameters are fully documented in schema. Description adds minimal extra meaning beyond 'período e filtros'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists immediate Pix payments initiated via Open Finance with period and filters. It distinguishes from siblings by specifying 'imediato' and 'Open Finance', and mentions monitoring use cases.
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 says to use for tracking authorization, completion, or failure without creating new payments. This provides clear context but does not explicitly name alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds context that it is non-destructive ('sem repetir a ordem de pagamento') and used for monitoring. No contradictions, and it reinforces the safe read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: first states the purpose, second provides usage guidance. Every word is necessary, no fluff, and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown but indicated), the description does not need to detail return values. It covers purpose, usage, and identifier. It lacks error conditions or prerequisites, but for a simple read-only query tool, it is largely complete.
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 baseline is 3. The description does not add additional parameter meaning beyond the schema; the parameter description in schema is already clear but somewhat circular. No extra semantic value from the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Consulta uma solicitação de pagamento de conta pelo identificador,' specifying the verb (consultar) and resource (payment request). It also distinguishes from related tools by noting it is for tracking without reissuing the payment order, differentiating it from creation or mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides usage: 'Use para acompanhar processamento, confirmação ou falha sem repetir a ordem de pagamento.' This tells the agent exactly when to use this tool (to check status) and when not to (avoid resending the payment).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context: 'move balance' (consistent with destructiveHint) and 'identifies the devolution within the transaction', informing the agent about the return value and side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. Every sentence provides essential information: the action and a usage caution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description is sufficiently complete. It covers the tool's purpose, side effects, and post-conditions. Could add more detail about when not to use it or prerequisites like authentication, but overall adequate.
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 the schema already documents all three parameters (e2eId, id, valor). The description does not add further meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests a refund linked to a received Pix and identifies it within the transaction. The verb 'Solicitar' and resource 'devolução vinculada a um Pix recebido' are specific, and it distinguishes from siblings like pix_send or pix_detail_devolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage condition: 'Use após conferir o recebimento e o valor, pois a operação movimenta saldo.' It warns about balance movement, but does not explicitly exclude alternative scenarios like querying existing devolutions (pix_detail_devolution) or sending a new Pix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide some hints (readOnlyHint=false, destructiveHint=false), but the description adds context: the operation resends an existing carnet without creating new ones. It does not disclose rate limits or authentication requirements, but given the simple nature of the tool and existing annotations, the description adds reasonable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no fluff. The first sentence states the action, the second provides usage guidance. Every sentence 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?
Given the presence of an output schema, the description does not need to explain return values. It adequately covers purpose and usage. It could mention that the carnet must exist, but the schema's required parameter 'id' implies that. For a simple resend tool, it is sufficiently complete.
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 the baseline is 3. The description does not add additional meaning beyond what the schema already provides for the 'id' and 'email' parameters. It implicitly references them but lacks extra details like format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Reenvia por e-mail um carnê já criado com suas parcelas.' It specifies the resource (carnê already created) and the operation (resend by email). It also distinguishes from generating new carnês or charges, which differentiates it from sibling tools like 'create_carnet' or 'send_billet_email'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'Use quando o pagador precisar receber novamente os documentos.' It also clarifies what not to do: 'sem gerar outro carnê ou novas cobranças.' This provides clear context and alternatives, making it easy for the agent to decide when to invoke this tool.
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?
Description aligns with annotations (readOnlyHint, idempotentHint) by stating 'Recupera' and 'sem alterar a conta ou o agendamento', adding behavioral context beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states action, second gives use case. No redundant information, front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description is complete. It explains the purpose, use context, and output expectation (retrieving a file). Siblings like list_statement_files are not mentioned but the tool is self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter nome_arquivo is documented in schema with a clear description. The tool description further clarifies it retrieves by name. Since schema coverage is 100%, baseline 3 is appropriate; description adds minimal additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (recupera) and resource (arquivo de extrato CNAB 240). It distinguishes from sibling list_statement_files by indicating file retrieval by name and provides a specific use case (importar movimentos em conciliação).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the intended use case (importar movimentos em conciliação) and clarifies it does not alter account or schedule. However, it does not mention when not to use or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately describes creation behavior and output, consistent with annotations (non-read-only, non-destructive). No contradiction. It adds context that the response contains the created key, which is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, clear annotations, and presence of output schema, the description fully covers purpose, usage, and output. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (vacuously). The description explains what the tool does beyond the schema (purpose and output). Baseline of 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it registers a new random Pix key, which is distinct from siblings like pix_list_evp (list) and pix_delete_evp (delete). The verb 'registra' and resource 'chave Pix aleatória' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'when the account needs an EVP to receive payments.' It does not mention alternatives or when not to use, 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?
The description indicates a destructive action ('Remove'), which aligns with the destructiveHint annotation. No additional behavioral details are provided, but annotations already convey the safety profile, and the description is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the action, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and a simple destructive purpose, the description is complete. It does not need to explain return values due to the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters (0 params, 100% schema coverage). The description does not need to add parameter meaning, and baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: remove a webhook configuration for automatic Pix charges. It specifies the resource (automatic charge webhook) and distinguishes it from siblings like pix_delete_webhook and pix_delete_webhook_recurrence_automatic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: when the destination should no longer receive charge events and recurring attempts. It does not provide explicit alternatives or when-not-to-use scenarios, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by stating that notifications will be interrupted, which aligns with the destructiveHint and idempotentHint annotations. It does not contradict any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and purpose, then providing usage context. There is no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, destructiveHint and idempotentHint annotations, and an output schema, the description covers what, when, and the consequence completely. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline score is 4. The description does not need to elaborate on parameter semantics, and it remains clear and sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (remove) and the specific resource (webhook configuration for automatic Pix recurrences), effectively distinguishing it from sibling tools like pix_delete_webhook and pix_config_webhook_recurrence_automatic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on when to use the tool ('when the destination should no longer receive these events') and mentions the consequence (notifications stop). It does not explicitly list alternatives, but the context implies deletion is the only removal option for this specific resource.
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?
Describes the operation as read-only ('consulta', 'sem alterá-la'), aligning with annotations (readOnlyHint, idempotentHint, openWorldHint). Adds context about retrieving revision and status, reinforcing safe behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no redundancy. Front-loaded with purpose, every word serves a function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description sufficiently covers purpose and usage for a read-only query tool. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes parameters thoroughly. The description adds no extra semantics beyond the schema, just mentions 'by txid', meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries data, revision, and status of a Pix due charge by txid. It specifies the exact resource and action, distinguishing it from sibling tools that create, update, or list charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for monitoring or display without altering, implying not for modification. Provides clear context but does not mention specific alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and open-world behavior. Description adds value by specifying the exact data queried (capacity, tokens, replenishment), which aids understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences concisely convey purpose and usage. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description fully covers what it does, why to use it, and what it returns. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Description adds no parameter information, but none is needed. Baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries capacity, available tokens, and replenishment of buckets used in Pix key management. The verb 'consulta' and resource 'baldes de fichas' are specific. It distinguishes from sibling tools focused on other Pix operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use for deciding when to register keys without consuming a token. While it doesn't list alternatives or when not to use, the use case is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description reinforces that it is a query operation ('Consulta') and adds context about its purpose, which is consistent and adds value without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the main purpose, and contains no unnecessary words. Every part is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and the description covers the essential usage (querying participants and criteria for validation), it is complete for its purpose. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, but they are minimal. The tool description adds meaning by explaining that the parameters are used to query split configuration details for validation, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries participants and criteria of a split Pix configuration, using specific verbs and resources. It distinguishes itself from sibling tools by mentioning validation before linking or reviewing an existing link, which is unique among split-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: validate distribution before linking to a charge, or review an existing link. It does not explicitly mention when not to use, but the context is clear and sets expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive mutation. The description adds valuable context that only the specified parcel is resent, not the entire carnet. While it does not discuss authentication or rate limits, the combination is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundancy, and front-loaded with the core action followed by usage guidance. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the description's clarity on purpose and scope, the description is complete. It covers the essential behavioral and usage aspects without missing critical information.
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% with clear parameter descriptions. The description does not add meaning beyond what the schema provides; it merely reiterates the action. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resend by email a specific installment) and the resource (carnet parcel). It differentiates from siblings like 'send_carnet_email' by specifying that only one parcel is affected, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: 'Use when only that document needs to be delivered again; the other installments remain unchanged.' This implies when not to use it (e.g., for full carnet resend) and suggests alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent, non-destructive mutation. Description adds context: resends existing link, does not create subscription, aligning with annotations and clarifying no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key action and resource. No redundant information; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters, clear purpose, and existence of output schema, description fully informs the agent when and how to use the tool. No gaps remain.
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% with clear parameter descriptions (email and id). Description does not add extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resends the payment link for a subscription via email. Verb 'reenvia' and resource 'link de pagamento da assinatura' are specific. Distinguishes from generic send_link_email by specifying subscription context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use when customer needs to receive checkout access again and notes the operation does not create a new subscription. Provides a clear use case but lacks explicit when-not or comparison to alternatives like send_link_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent; description adds context that it alters financial state, complementing the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, no redundant text, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with output schema and clear usage context; no gaps given the complexity.
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 baseline is 3. Description does not add extra meaning to the 'id' parameter beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manually marks a carnet as paid, uses specific verb-resource pair, and distinguishes from siblings like settle_carnet_parcel and cancel_carnet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: only when payment occurred through another means and needs to be reflected in Efí, and warns of state change.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint true; description adds that blocked values are shown when requested and confirms no balance movement, aligning perfectly and adding value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences conveying all essential information without waste, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given read-only nature, one optional param, and existence of output schema, the description covers purpose, usage, and safety completely.
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% with one parameter. Description's 'quando solicitado' hints that 'bloqueios' triggers blocked value retrieval, adding meaning beyond schema's vague description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'consulta' and resource 'saldo da conta Efí', with optional blocked values, clearly distinguishing it as a balance query tool among many Pix siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use 'antes de operações de saída ou em conciliações' and confirms 'nenhum saldo é movimentado', providing clear context. No explicit exclusion of alternatives but sufficient given tool type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that it only consults and does not alter delivery, reinforcing the read-only nature. It doesn't contradict annotations and provides operational context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action. No wasted words; each sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, annotations cover safety, and an output schema exists, the description is complete. It tells the agent what the tool does, when to use it, and its non-destructive nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. Description doesn't need to explain parameters. Baseline for 0 params is 4, and the description is clear about the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults the current configuration of the automatic Pix charges webhook. It uses specific verb 'Consulta' and resource 'configuração vigente do webhook de cobranças Pix Automático', distinguishing it from sibling tools like pix_config_webhook_automatic_charge (which alters) and general webhook query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use para confirmar o destino dos eventos sem alterar a entrega das notificações.' This tells the agent when to use the tool (to confirm destination) and implies when not to (when wanting to change configuration, use the sibling config tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mcp-server-efi MCP server](https://glama.ai/mcp/servers/JoaoLucasAl/mcp-server-efi/badges/card.svg)](https://glama.ai/mcp/servers/JoaoLucasAl/mcp-server-efi)

Score Badge

Copy to your README.md:

[![mcp-server-efi MCP server](https://glama.ai/mcp/servers/JoaoLucasAl/mcp-server-efi/badges/score.svg)](https://glama.ai/mcp/servers/JoaoLucasAl/mcp-server-efi)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JoaoLucasAl/mcp-server-efi'

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