Despezzas MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a distinct name and description, covering different resources (accounts, profiles, credit cards, transactions) and actions (list, create, update, delete, search, etc.) with no overlap.
Naming Consistency5/5
All tools follow a consistent 'despezzas_verb_noun' pattern in snake_case, making the intended action and resource clear. Even nuanced operations like 'prepare_create_transaction' adhere to this convention.
Tool Count3/5
With 35 tools, the set is on the higher side but still reasonable for a comprehensive personal finance API that includes profiles, accounts, credit cards, transactions, and advanced operations like batch updates and exports.
Completeness4/5
The tool set covers full CRUD for accounts, credit cards, and transactions, plus search, finance summaries, transfers, exports, and duplicate/toggle operations. The presence of a 'raw_api' tool suggests possible edge cases not covered, but the main surface is thorough.
Average 3.3/5 across 35 of 35 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds default date/account context beyond annotations. However, it lacks detail on pagination, rate limits, or other behaviors relevant for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but overly minimal for a tool with 15 parameters. It lacks structure, front-loading only a default behavior hint. The brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite rich annotations and an output schema, the description omits critical context: how to use filters, what the output contains, or how results are ordered/paginated. It fails to compensate for the complex schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description provides no parameter explanations. None of the 15 parameters (e.g., limit, order, search, is_paid) are described. The description does not add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists filtered transactions and notes default behavior (current month, bank accounts). It distinguishes from siblings by being the primary search tool, though not explicitly contrasting with other transaction tools like overview or summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., despezzas_transaction_overview, despezzas_finance_summary). The description only notes default filtering, not usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations by revealing two modes (count/inspect vs export). However, it does not elaborate on side effects, rate limits, or detailed behavior. Annotations already indicate read-only and idempotent, so 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence) but achieves some effect. However, it lacks structure and forces the agent to infer too much. Could be expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no schema descriptions, and a output schema present (not described), the description is severely incomplete. The agent cannot understand the tool's full functionality or parameter roles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions coverage is 0%, so the description must explain parameters. It only mentions count_only, ignoring date_start, date_end, account_ids, credit_card_ids, sample_limit, and include_field_summary. Inadequate for 7 parameters.
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 'Conta e inspeciona campos' hints at counting and inspecting, and the title 'Exportar Transações' clarifies export. It implies two modes via count_only. Distinguishes from sibling transaction tools (e.g., search, update) but could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like search_transactions or transaction_overview. Does not specify conditions for using count_only=true vs false.
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 adds one behavioral detail: that confirm must be true for creation to proceed. However, annotations are all false and provide no safety profile; the description does not disclose other behaviors like error handling, idempotency, or what happens if confirm is false. The description carries the full burden but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no filler, and front-loads the purpose and key requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters and no schema descriptions, the description provides minimal context. It does not explain what an 'account' resource is, the role of logo/name, or what the output schema contains. The tool is incomplete for an AI agent to use correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only explains the confirm parameter (requires true). Other parameters (name, logo, include_total_balance, initial_balance_cents) have no meaning added beyond their names and types. The description partially compensates for one parameter but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'cria conta manual' (creates manual account), specifying the verb and resource. The title also supports this. It distinguishes from sibling tools like despezzas_update_account or despezzas_list_accounts, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'Exige confirm=true' (requires confirm=true), which indicates a precondition but no context on when to use this tool versus alternatives (e.g., update or delete account). No prerequisites or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=true. The description adds the requirement for confirm parameter and denotes "manual" edit, but does not explain behavior like partial updates or side effects. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two short sentences) and front-loads the action. However, given the complexity of 10 parameters, it is under-specified. The structure is clear but brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 10 parameters, zero schema descriptions, and annotations present, the description provides minimal context. It fails to explain when to use this tool, what the "manual" edit entails, or how to handle the many optional fields. The existence of an output schema reduces the need for return value explanation, but overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only adds meaning for the `confirm` parameter (requires true). It does not explain any other parameters (id, logo, name, etc.), leaving the agent with no guidance beyond the schema's type definitions.
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 title and description clearly state the tool edits a credit card. The verb "Edita" (edits) and resource "cartão" (card) are specific. However, it does not explicitly differentiate from sibling tools like create or delete, but the name itself is self-explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions a requirement for the `confirm` parameter to be true, but provides no guidance on when to use this tool versus alternatives (e.g., when to update vs. delete or create). No context on prerequisites or conditions.
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 the confirm parameter requirement, which is useful. However, it omits other behavioral traits like whether updates are partial or full, or what happens if confirm is false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (2 sentences) with no wasted words, but it lacks front-loading of critical information beyond the verb. Concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, a destructive operation, and an output schema, the description is severely incomplete. It fails to explain update behavior (partial vs full), return values, or prerequisites, relying too much on the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameter meanings, but it only mentions the confirm flag. No details on id, date, kind, scope, etc., leaving the agent to infer from names and types alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edita transação' (Edits transaction), specifying the verb and resource. It distinguishes from sibling tools like batch_update or toggle_paid, but lacks detail on the scope of edit (e.g., partial update vs full replacement).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Exige confirm=true' as a requirement but provides no guidance on when to use this tool versus alternatives like prepare_update_transaction or batch_update_transactions. It fails to mention prerequisites or exclusion 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=true, destructiveHint=false, and idempotentHint=true, so the description's statement 'sem excluir' aligns without adding significant new behavioral context. It confirms safety but offers minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it is too terse; it could add substance without losing brevity. It meets the minimum but does not earn its place fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools and a output schema (not shown), the description should hint at what the tool returns or how it differs from other prepare tools. It lacks completeness for a preview operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters (id and scope with its enum values). The meaning of scope options (THIS, THIS_AND_NEXT, ALL) is left undefined, which is a gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mostra alvo e escopo sem excluir' clearly indicates the tool displays a target and scope without deleting, distinguishing it from the actual delete tool. The name 'prepare_delete_transaction' reinforces this, making purpose clear 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like despezzas_delete_transaction. The description does not advise users to preview before deleting, leaving it implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds no further behavioral context, such as what exactly is toggled or if the date parameter affects which occurrence is toggled.
Agents need to know what a tool does to the world before 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, containing only two short sentences with no redundant information. It efficiently conveys the core action and a key requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with three parameters, the description is insufficient. It fails to explain the toggle mechanism, the role of the date parameter, or the overall impact on the transaction, leaving the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially explains the 'confirm' parameter (require true) but omits any description for 'id' and 'date', leaving their meaning and usage unclear.
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 'Toggle payment on date' clearly states the action (toggle) and the resource (payment/transaction), distinguishing it from general update tools. However, it does not explicitly differentiate from sibling tools like update_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions 'Requires confirm=true' but provides no guidance on when to use this tool versus alternatives, such as when toggling vs. setting paid status 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 already indicate destructive and idempotent behavior. Description adds the crucial requirement that confirm must be true, but lacks details on permanence, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, two short sentences. No wasted words, but could benefit from more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 2 parameters and no schema descriptions, the description is insufficient. It omits important context like irreversibility, required ownership, or impact on related entities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameters. It only hints at confirm must be true, but does not describe the id parameter or any other semantics 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?
Description clearly states it deletes an account, using a verb+resource structure. It does not explicitly distinguish from sibling delete tools like delete_profile, but the resource type is distinct from others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Only mentions the requirement for confirm=true, but no context on prerequisites or 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, destructiveHint=false. The description confirms no API call and validation role, adding marginal value. No contradictions, but little extra behavior disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified given the tool's complexity (15 parameters). It omits critical usage details, making it insufficient for effective tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and complex input, the description is minimal. It fails to describe return values, validation behavior, or relationships to other tools. The agent lacks context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with 15 parameters and many enums. The description provides zero information about any parameter, leaving the agent to infer meaning only from names and types. This severely hinders correct parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Monta e valida uma transação sem chamar a API' clearly states the tool assembles and validates a transaction without API calls. The verb 'prepara' (prepare) and the distinction from 'create_transaction' is clear, especially given the sibling tool 'despezzas_create_transaction' exists for actual creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a safe validation step before actual creation, but does not explicitly state when to use or not use, nor provide alternatives. The sibling tool names suggest it, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal value by stating it returns totals/balances, but does not elaborate on response structure, caching, or authentication requirements. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short phrase). It is front-loaded with the core action, but lacks structure such as separate sections for usage or examples. Brevity is appreciated, but not at the cost of 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 presence of an output schema (not shown in input) and annotations covering safety, the description is minimally adequate for a simple read operation. However, it fails to explain that the date must match a specific pattern or note the unusual default value of 2026-07-29, which could confuse agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description does not describe the parameter at all. While the description mentions 'para uma data' (for a date), it does not specify the parameter name, format (YYYY-MM-DD), optionality, or default value. With only one parameter, more detail would be expected.
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 retrieves totals and balances for a specific date. 'Obtém totais e saldos para uma data' translates to 'Gets totals and balances for a date,' which is a specific verb+resource combination. Among siblings, it is distinct from search_transactions or finance_summary, though the differentiation is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as 'finance_summary' or 'search_transactions'. The description only states it works for a date, but does not explain prerequisites, limitations, or provide examples of appropriate 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 that the tool requires confirm=true to execute, adding behavioral context beyond annotations. Annotations already indicate destructiveHint=true and idempotentHint=true, and the description aligns with these, confirming it is a mutation that must be explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, but it lacks structure and depth. It front-loads the confirm requirement, but it does not organize information or earn its place beyond stating a single constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no schema coverage, and is destructive with idempotency, the description should provide more context about side effects, return values (though output schema exists), and parameter roles. The description is too minimal for adequate use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions the confirm parameter. The other 5 parameters (id, logo, name, balance_cents, include_total_balance) are completely undiscussed, leaving the agent without semantic guidance.
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 explicitly states the tool edits a manual account, which is a specific verb-resource combination. It distinguishes from sibling tools like despezzas_create_account and despezzas_delete_account, though it could be more explicit about what types of accounts are editable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only provides a requirement for the confirm parameter but offers no guidance on when to use this tool versus alternatives. There is no comparison to siblings like despezzas_list_accounts or despezzas_create_account.
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 destructive and idempotent. The description adds that invites replace the current list and requires confirm=true. This goes beyond annotations but does not cover all behavioral traits (e.g., confirmation effect, side effects on other fields).
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, no fluff, key points about behavior and requirement. However, could be more concise if additional details were added without bloating.
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 5 parameters with no schema descriptions, the description is insufficient. It omits explanations for id, name, type, and does not mention output or conditions. Required confirm=true is stated but not elaborated. Agent would need to infer or rely on other sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It explains 'invites' (replaces list) and 'confirm' (must be true), but leaves id, name, and type unexplained. Only two of five parameters are addressed.
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 edits a shared profile (verb+resource). It distinguishes from sibling update tools by specifying 'perfil compartilhado' and mentions that invites replace the current list. However, it could be more explicit about the access aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus alternatives. The only usage direction is 'Exige confirm=true', which is a requirement, but no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that the operation is 'manual' and requires 'confirm=true', which is beyond the annotations. Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description does not disclose other behavioral traits like response details or side effects, but the added requirement is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short phrases. It front-loads the action and key requirement. Every word earns its place, with no filler.
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 9 parameters, 1 required, and the existence of an output schema (which reduces need to explain returns), the description is still far from complete. It lacks context on what 'manual' means, prerequisites, default behaviors, and how parameters interact. The output schema may help, but the description itself is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only clarifies the 'confirm' parameter (requires true) but offers no additional meaning for the other 8 parameters (e.g., name, logo, account_id). This is insufficient for a complex creation tool.
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 a credit card ('Cria cartão manual'). The verb 'Cria' and resource 'cartão' correctly identify the action and object. However, it lacks explicit differentiation from sibling tools like update or delete, though the context of 'create' is clear among credit card tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only one usage requirement ('Exige confirm=true') but no guidance on when to use this tool versus alternatives (e.g., list, update, delete). It doesn't mention prerequisites or context for manual creation vs. automatic processes.
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 read-only, idempotent, and not destructive. The description adds minimal context about listing both default and user categories. It does not contradict annotations, but it also does not elaborate on behavioral traits like pagination, filtering, or error states, which would add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the core purpose. While it could include more detail, it does not contain fluff and is efficient for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema exists), the description is minimally adequate. However, it lacks context about what happens when 'include_user' is false, or how the output is structured. Sibling tools like list_subcategories suggest a hierarchy that is not mentioned. The description is complete enough for basic use but leaves room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the 'include_user' parameter. The description only says 'lists default and user categories,' implying the parameter controls inclusion of user categories, but this is ambiguous and not explicit. The parameter's effect when false or true is not clarified, so the description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists default and user categories. The verb 'list' and resource 'categories' are specific, and the mention of 'padrão e do usuário' distinguishes it from potential siblings like list_subcategories. However, it could be more explicit about the differentiation from list_accounts or other 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_subcategories or search_transactions. There is no mention of prerequisites, exclusions, or typical use cases, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the need for the confirm parameter, which adds behavioral context beyond annotations. It aligns with readOnlyHint=false, indicating a write operation. No contradictions, but other behavioral traits (e.g., side effects, errors) are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, no wasted words. However, it could be slightly longer to include essential parameter details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain the overall behavior, return value, or error conditions. With 8 parameters and a complex transfer operation, the minimal description is insufficient for an agent to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining key parameters. It only mentions 'confirm', leaving 7 other parameters (including critical ones like amount_cents, sent_account_id) undescribed. Agent would lack information to use the tool correctly.
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 a transfer between accounts, which is specific and actionable. However, it does not differentiate from sibling tool 'despezzas_create_transaction', leaving ambiguity about when to use each.
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 critical usage requirement ('Exige confirm=true'), which is helpful. However, it lacks guidance on when to use this tool vs alternatives (e.g., create_transaction) and does not mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the burden. It adds the requirement that confirm=true, but does not clarify whether the operation is destructive, idempotent, or what side effects occur (e.g., creating a new transaction record).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences. It is front-loaded with the core action, but might be too sparse to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema and two parameters, the description lacks details on what 'duplicate' entails (e.g., does it copy all fields? Does it create a new transaction?) and does not explain the return value or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It only addresses the 'confirm' parameter by stating it must be true. The 'id' parameter is left unexplained.
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 'duplicate' and the resource 'transaction'. However, it does not differentiate from sibling tools like create_transaction or prepare_create_transaction, which could also be used to create copies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The only usage hint is that 'confirm' must be true, but no context for when duplication is 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 indicate destructiveHint=true. The description adds that GET is safe without extra flags, while other methods require explicit confirmation. This adds some context but does not detail error behavior, side effects, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively communicates the core purpose and key condition. It is appropriately front-loaded and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical context such as base URL, authentication, valid endpoints beyond the path pattern, and error handling. For a generic raw API tool, this is insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no details about parameter semantics. It only mentions method flags 'allow_destructive' and 'confirm' implicitly; parameters like 'path', 'query', and 'body' are left unexplained.
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 'Executa GET bruto' indicating a raw GET request, and notes that other methods require special flags. It clearly identifies the tool's primary verb and resource, distinguishing it from sibling tools that target specific endpoints.
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 specifies when to use GET versus other methods by requiring 'allow_destructive=true' and 'confirm=true' for non-GET operations. However, it does not explicitly contrast this tool with sibling tools or provide guidance on when to use the raw API over dedicated 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?
The description adds the confirm requirement beyond annotations (destructiveHint=true, idempotentHint=true). However, it does not disclose side effects like irreversibility, impact on other members, or required permissions, which would be valuable for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and followed by a crucial requirement. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description lacks detail on return values, prerequisites, or side effects for a destructive tool. The minimal information may confuse the agent about when and how to safely invoke 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 0%, so description must compensate. It clarifies that confirm must be true for the action to proceed, but provides no semantics for profile_id (only that it is required). This partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'leave' and resource 'profile', indicating it removes the account from a shared profile. It distinguishes from siblings like delete_profile (which deletes the profile) and switch_profile (which changes active profile), but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only states the action and requirement for confirm=true, leaving the agent to infer usage context from the name and 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, idempotentHint=true, destructiveHint=false, indicating a safe, non-destructive operation. The description adds that it does not call the API, which is consistent but does not provide additional 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the core purpose. It is front-loaded and contains no unnecessary words. However, the lack of parameter guidance slightly reduces usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters and an output schema, the description fails to mention what the tool returns (e.g., validation errors, prepared transaction object). The output schema exists but is not described, leaving the agent unaware of the return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 13 parameters (e.g., id, date, kind, etc.). The agent must infer meaning solely from parameter names and types, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name 'despezzas_prepare_update_transaction' and description 'Monta e valida uma edição sem chamar a API' clearly indicate it prepares and validates a transaction edit without executing the update. This distinguishes it from sibling tools like 'despezzas_update_transaction' which actually calls the API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that it assembles and validates without calling the API, implying it should be used before an actual update. However, it does not explicitly state when to use it over alternatives (e.g., update_transaction or prepare_create_transaction), nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that it lists standard and user subcategories, but does not disclose any further behavioral details (e.g., ordering, filtering, or pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It efficiently communicates the core purpose. However, it could be slightly expanded to include parameter clarification without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation and presence of an output schema, the description is adequate but not complete. It fails to explain the parameter and does not provide context when to use this tool over siblings. More detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'include_user' with 0% description coverage. The description does not explain this parameter, leaving its purpose unclear. The parameter name is somewhat informative, but the description should clarify its effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 subcategories (both standard and user), which distinguishes it from sibling tool 'list_categories' that likely lists parent categories. The verb 'list' and resource 'subcategories' 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_categories' or other sibling tools. The description only states what it does, not the context or conditions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description simply says 'searches', which is consistent but adds no additional behavioral context such as what the response contains or any side effects. Given strong annotations, the description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose. It is appropriately sized for a simple retrieval tool with no parameters. However, it could be slightly more informative without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, strong annotations, and an output schema (though not detailed here), the description provides a basic understanding. It lacks detail about the output structure or typical values, which might be necessary for correct usage. The use of Portuguese may also reduce clarity for multilingual agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100%. The description does not need to provide parameter details. The baseline for zero parameters is 4, and the description meets this without adding unnecessary information.
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 retrieves financial visibility preferences, which matches the title 'Get Personal Configuration'. It is distinct from sibling tools that deal with accounts, transactions, or profiles. However, it could be more explicit about what specific preferences are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'despezzas_profile' or 'despezzas_finance_summary'. No context on prerequisites or typical use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only (readOnlyHint=false) and not idempotent. The description adds the requirement for 'confirm=true', which is useful but does not disclose other behaviors like error handling or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose and a key requirement. It is front-loaded but could include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, including optional nested invites) and the existence of an output schema, the description covers only the bare minimum. It lacks explanation of the return value, the invites parameter, and the effect of 'confirm'. The description is incomplete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter description coverage is 0%, so the description must add meaning. It mentions the 'type' enum values (PJ, família, investimentos) and the 'confirm' requirement, but does not explain 'name', 'invites', or the meaning of 'confirm' itself. This is insufficient for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an extra profile (PJ, family, investments). It distinguishes from sibling tools like 'despezzas_list_profiles' and 'despezzas_create_account' by specifying the resource (profile) and subtypes.
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 notes that 'confirm=true' is required, giving a usage constraint. However, it does not provide guidance on when to use this tool versus alternatives (e.g., 'despezzas_create_account'), nor does it mention prerequisites 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?
Description adds the confirm requirement beyond annotations. Annotations already indicate destructiveHint=true and idempotentHint=true, which are consistent. No additional behavioral details like error cases or irreversible 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 with no redundant information. Every word is essential for the purpose and requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations provide destructive/idempotent hints, the description is passable but minimal. It lacks information about prerequisites (e.g., ownership is implied but not explicit in text) and potential side effects on associated data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should compensate. It explains the confirm parameter (must be true), adding value beyond the default=false in schema. However, the required 'id' parameter is not described at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 action (Exclui = delete) and resource (perfil compartilhado próprio = own shared profile). Differentiates from siblings like despezzas_leave_profile (leave vs delete) and despezzas_create_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions the requirement confirm=true, but provides no guidance on when to use this tool versus alternatives (e.g., despezzas_leave_profile for shared profiles not owned). No 'when not to use' or context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true. The description adds context: it can preview (no confirm) or edit (with confirm), and limits to 50 items. It does not fully detail modification behavior (e.g., which fields are overwritten), but it adds meaningful behavioral info beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence) and front-loaded, but it omits essential details. It earns its place but could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (batch update with many fields, preview/write behavior, output schema), the description is incomplete. It does not explain the updates structure, stop_on_error parameter, or what the tool returns. While output schema exists, the description should still provide context for using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only mentions the 'confirm' parameter, ignoring the complex 'updates' array (with 13 sub-fields) and 'stop_on_error'. This leaves the agent with no guidance on how to structure updates or handle errors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: 'Pré-visualiza ou edita até 50 transações' (preview or edit up to 50 transactions). It uses a specific verb (preview/edit) and resource (transactions), and distinguishes itself from sibling tools like 'despezzas_update_transaction' (single edit) by specifying the batch nature.
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 hints at usage by noting that 'confirm=true' is required to write, implying preview without confirm. However, it does not explicitly state when to use batch vs single update tools, nor provide exclusions 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 are all false (no readOnly, no idempotent, etc.), so the description carries full burden. It adds behavioral context by noting the confirm flag requirement and the prepare recommendation, but does not disclose side effects, error conditions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no fluff. The main action and crucial usage notes are front-loaded. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too sparse for a 16-parameter mutation tool. It omits details on required fields (title, amount_cents, date), optional fields, and parameter interplay. The prepare-first recommendation is helpful but insufficient for confident agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema). The tool description does not explain any of the 16 parameters, such as title, amount_cents, kind, etc. It only mentions confirm and prepare, which are not parameter-specific explanations. Considerable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cria transação' (Creates transaction), a specific verb+resource combination. The mention of required confirm and recommended prepare distinguishes it from sibling tools like update or delete transactions.
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 the requirement to set confirm=true and recommends running the prepare step first (via sibling despezzas_prepare_create_transaction). Provides clear context for correct invocation, though does not explicitly list 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 indicate idempotentHint=true and non-readOnly. The description adds the 'confirm=true' requirement but does not disclose other behavioral traits such as side effects, failure modes, or permissions. With annotations covering some aspects, the description offers 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 short (two sentences) and front-loads the core action. Every word is meaningful 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 low complexity (2 params, no nested objects) and existing annotations, the description is adequate. However, it lacks context on error handling, confirmation semantics, and how switching affects other operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions the confirm parameter requirement but does not explain the profile_id parameter or the meaning of confirm. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Troca o perfil ativo' - switches the active profile) and adds a specific requirement ('Exige confirm=true'). This distinguishes it from siblings like create_profile or delete_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the 'confirm=true' requirement but does not provide explicit guidance on when to use this tool versus alternatives (e.g., despezzas_profile). No exclusion criteria or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that confirm=true is required, which is a behavioral constraint not in annotations. But it does not elaborate on scope behavior 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 minimal (two sentences) and front-loaded, containing no unnecessary words. It efficiently conveys the core purpose and a critical usage constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description lacks explanation of the scope parameter and what happens when confirm is false. For a delete tool with multiple behavior modes, this is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions (0% coverage). The description only clarifies the confirm parameter (must be true), but ignores id (required) and scope (enum). This leaves the agent with incomplete understanding of all 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 'Exclui transação' clearly states the action (delete) and resource (transaction), distinguishing it from sibling tools like create, update, search, 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 explicitly requires confirm=true, guiding the agent to set this parameter. However, it does not provide context on when to use this tool versus alternatives like batch_update_transactions or toggle_transaction_paid.
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 destructiveHint, covering safety. The description adds the scope of the summary (revenues, expenses, payments, categories) and default period, which is useful 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, concise sentence front-loading the core action and default behavior. No unnecessary words.
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 5 parameters with 0% schema coverage, the description is insufficient to guide proper invocation. The existence of an output schema mitigates return-value ambiguity, but parameter usage remains unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only mentions default current month related to date range, but provides no details on limit, account_type, include_transactions, or the null/pattern 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 tool summarizes revenues, expenses, payments, and categories, distinguishing it from sibling tools like search_transactions or list_accounts. The default current month is specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for financial summaries, with a default current month, but does not explicitly state when to use versus alternatives. However, context and sibling tool names provide adequate differentiation.
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 readOnlyHint=false. Description adds that confirm must be true for execution, which is beyond annotation data and clarifies a critical behavioral guard.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences with no filler. Information is front-loaded and to the point.
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 annotations and output schema exist, the description lacks details about side effects, error conditions, or confirmation semantics beyond the confirm flag. For a destructive tool, more context 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 coverage is 0%, so description must compensate. It explains the confirm parameter's purpose (must be true) but does not elaborate on the id parameter. This provides some added value but is insufficient for full parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Exclui cartão' (deletes card) and specifies the required confirm flag. This distinguishes it from sibling tools like list, create, update credit cards.
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 'Exige confirm=true', which is a usage requirement, but does not provide when to use this tool vs alternatives (e.g., update instead of delete) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds that it checks credentials/token, which is useful context but does not reveal additional behavioral traits such as response format or potential error states. It 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 a single, concise sentence that directly states the tool's functionality. 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.
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 (zero parameters, output schema present), the description is complete. It clearly explains what the tool does without needing more detail. The output schema presumably defines the response structure.
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 no parameters, and schema coverage is 100%. The description does not need to explain parameters, so it is adequate. A higher score would require additional context about what is checked, but no parameters exist to merit 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 tool's purpose: to verify if the server has credentials or token for Despezzas. It uses a specific verb ('Verifica') and resource ('credenciais ou token'), and it distinguishes itself from sibling tools like 'despezzas_list_accounts' or 'despezzas_profile' which are not health checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical usage scenarios, or when not to use it. For a health check tool, it would be helpful to suggest calling it before other operations, but this is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and non-destructive. The description adds the behavioral detail that it returns 'context of the active profile', which is not in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets to the point. However, it is in Portuguese, which may reduce clarity for agents expecting English descriptions for an English-named tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, output schema exists, annotations cover safety), the description sufficiently covers the main function. Could mention if it returns all accounts or filtered, but output schema likely fills 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, so baseline is 4 as per guidelines. The description does not add parameter info because none exist, which 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 accounts and includes the context of the active profile. The verb 'list' and resource 'accounts' are explicit, and it distinguishes from create, update, and delete 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like list_banks or other list tools. The purpose is clear but there is no advice on context or exclusion criteria.
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, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds that the tool returns 'contexto do perfil ativo', which provides additional 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 a single, concise sentence with no redundant words. It is front-loaded and immediately conveys the tool's 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 that the tool has no parameters and an output schema exists, the description is complete. It explains what the tool returns (credit cards and active profile context), which is sufficient for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to explain parameters. 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.
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 'cartões de crédito', and adds that it also returns 'o contexto do perfil ativo', which differentiates it from other list tools like despezzas_list_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. There is no mention of prerequisites, conditions, or exclusions. The context of 'profile ativo' is implied but not explicitly stated as a requirement.
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 and idempotent hints; the description adds context by specifying the source ('used in manual accounts'), providing 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?
Single sentence with no extraneous words, efficiently conveying the tool's 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 presence of an output schema and no parameters, the description adequately conveys the tool's purpose and context, though it could hint at expected return format.
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, so the description need not add parameter details. 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 the tool lists bank options and logos used in manual accounts, distinguishing it from siblings like despezzas_list_accounts which list different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for manual accounts but does not explicitly state when to use this tool versus alternatives like despezzas_list_accounts.
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 destructiveHint=false. The description adds that sensitive fields are masked, which is valuable 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 a single, focused sentence with no wasted words. It efficiently conveys the core purpose and a key behavioral trait.
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 simplicity (no parameters, output schema exists) and strong annotations, the description is mostly complete. It could mention that the output contains profile data, but the title and masking detail suffice for this straightforward 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?
No parameters are defined in the input schema (coverage 100%), so the description does not need to add parameter semantics. Per guidelines, 0 parameters yields a baseline score of 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 title and description clearly state it fetches the authenticated profile. The verb 'Busca' and resource 'perfil autenticado' are specific. It is distinct from sibling tools like despezzas_list_profiles (which likely lists multiple profiles) and other CRUD 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 implies use for retrieving the current user's profile, but does not explicitly state when to use versus alternatives or provide exclusions. It is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating safe, repeatable reading. The description adds context by specifying it 'informa o perfil ativo' (reports the active profile), which goes beyond the annotations and improves understanding of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys all necessary information without any redundant or unnecessary words. Every phrase 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 the tool has no parameters, an output schema exists to document return values, and annotations fully cover safety behavior, the description is complete enough. It informs the agent of the exact purpose (list profiles with active info) and no further context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% by default. The description adds no parameter-specific information, which is acceptable since none exist. Baseline score of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists profiles (owner and member) and identifies the active profile. It uses a specific verb ('Lista') and resource ('perfis'), and the mention of 'informa o perfil ativo' adds distinct value. Among siblings, this tool is distinct as a list operation versus singular retrieval (despezzas_profile) or mutations (create/delete/switch).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, its purpose is straightforward (listing profiles) and sibling names like 'despezzas_profile' (singular) and 'despezzas_switch_profile' imply different use cases. The description does not provide explicit exclusions or scenarios.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/guipmilek/despezzas-mcp'

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