Cuéntica MCP

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct entity or action (e.g., customers, invoices, expenses, transfers). Despite the large number, the purpose of each tool is clearly defined and separate, minimizing confusion for an agent.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern (e.g., create_customer, list_customers). The only minor inconsistency is singular vs. plural nouns (get_customer vs. list_customers), but overall the naming is predictable and systematic.
Tool Count2/5
59 tools is excessive for typical MCP server scope. While the domain (accounting) requires many operations, this number likely overwhelms agent decision-making. The tool set could be consolidated or split into multiple servers.
Completeness4/5
The server covers full CRUD for major entities (customers, providers, invoices, expenses, income) plus advanced operations (VAT summaries, pending collections, email sending, voiding). Minor gaps exist (e.g., no delete_tag or create_account), but the surface is largely complete for accounting workflows.
Average 3.5/5 across 59 of 59 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds no additional behavioral context. It does not disclose what data is returned or any constraints 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words) but lacks necessary detail. It is under-specified rather than concisely informative.
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 many sibling get tools and no explanation of what a 'document' is, the description is incomplete. The presence of an output schema does not compensate for the lack of context in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the document_id parameter or its meaning. The agent has only the type and requirement from the schema, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Detalle de un documento' indicates it retrieves document details, but it is vague and does not specify what constitutes a 'document' or differentiate from other get tools like get_invoice or get_expense.
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_documents or other get tools. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint: true. The description adds a confirmation prompt and a warning icon, which reinforce the destructive nature but do not explain what is destroyed or any side effects (e.g., irreversible changes, authorization requirements). Behavioral context remains minimal.
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, which makes it concise, but the structure is flat and overloaded: a single line of warning followed by dense field listings. It could be more efficient by using bullet points or separating concerns, but it does not waste 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 8 parameters, 3 required, and no schema descriptions, the description is severely incomplete. It fails to explain required parameters (e.g., customer), optional parameters (e.g., date), or how to structure the array parameters. An output schema exists, but this does not excuse the lack of input guidance.
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 lists field names for income_lines, charges, and document_type, but provides no semantic meaning (e.g., what 'concept', 'imputation', or 'destination_account' are). Many top-level parameters (customer, date, document_number, annotations, tags) are not mentioned at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Crea un ingreso' which clearly indicates the tool creates an income record, but it does not differentiate from siblings like create_invoice or create_expense. The purpose is minimally clear but lacks specificity to avoid confusion with similar creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The only usage hint is 'Confirmar con usuario', which is a safety instruction, not a usage condition. No exclusions or context for appropriate use 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?
The annotations already declare readOnlyHint and idempotentHint, so the agent knows it's a safe read operation. The description adds that the output is Base64 content, which is useful. However, it omits potential size limits or response structure, relying on the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It is concise but could be more structured with separate sentences for functionality and usage. The brevity is appropriate, but it lacks 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?
While the presence of an output schema reduces the need to explain return values, the description does not provide essential usage context such as parameter requirements. For a simple tool with one parameter, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one parameter (document_id), the description does not explain the parameter at all. It fails to mention that a document_id is required or how to obtain it, making it difficult for an agent to use 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 the tool returns the content of a document attachment in Base64 format. The verb 'get' and resource 'document attachment' are specific, and the format mention distinguishes it from siblings like get_expense_attachment. However, it could be more explicit about what exactly is returned (the file data).
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 get_document or other attachment getters. The description lacks context on prerequisites or scenarios, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so behavioral traits are covered. The description adds no additional behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise but misses the opportunity to add value. It is not verbose, but it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the output schema existing and annotations covering idempotency, the description does not address the single required parameter or provide enough context for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the provider_id parameter or its meaning, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Detalle de un proveedor' clearly indicates the tool returns details of a provider. It uses a specific verb-resource combination and is distinct from sibling tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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, nor any context about prerequisites or typical use 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 indicate destructiveHint=true. The description adds a warning emoji and instruction to confirm with the user, which aligns with the destructive nature. However, it does not disclose other behaviors like partial update, idempotency, or effects on related entities.
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 three elements: a warning, the action, and a reference. It is front-loaded with the warning. While short, it wastes no words, but could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (22 parameters, destructive hint, and many sibling tools), the description is incomplete. It lacks parameter descriptions, update semantics explanation, and details about the output schema, relying on an external reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no information about what each of the 22 parameters means or their constraints. The only reference is to 'Ver create_provider para valores válidos', which is insufficient for understanding the semantics of each field.
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 'Actualiza un proveedor' (updates a provider), providing a specific verb and resource. However, it does not distinguish this tool from sibling tools like create_provider or delete_provider, which are similar but different actions.
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 update_customer. The only usage notes are to confirm with the user and refer to create_provider for valid values, which is minimal and does not help with tool selection.
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 readOnlyHint and idempotentHint, so the safety profile is clear. However, the description adds no extra behavioral details, such as behavior when the invoice_id does not exist, authorization requirements, or data freshness guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the purpose. It could be structured with bullet points for clarity but is acceptably concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema exists, the description does not need to explain return values. However, it lacks contextual completeness by not mentioning any rate limits, dependencies, or typical use cases. It is minimally adequate.
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% (the parameter 'invoice_id' has no description in the schema). The description only says 'by its internal ID', which provides minimal context about the parameter's meaning. It does not specify the format, range, or source of the ID.
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 indicates the tool retrieves complete invoice details by internal ID ('Detalle completo de una factura por su ID interno'). This distinguishes it from sibling tools like 'get_invoice_pdf' or 'get_invoice_public_link' which serve different purposes. However, it could be more specific about what 'complete detail' entails.
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. For instance, it doesn't clarify when to use 'get_invoice' versus 'list_invoices' or 'get_invoice_pdf'. The description lacks any context about prerequisites or exclusion criteria.
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 no behavioral information beyond what the readOnlyHint annotation already provides. There is no mention of side effects, permissions, or data scope, so the agent gains no additional insight into tool behavior.
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), but it lacks a verb and feels underspecified. While brevity is generally good, the minimal text barely meets the bar for clarity, resulting in a borderline score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return values, but it does not provide any context about what 'invoice series' are, how they are configured, or how the output is structured. More context would help the agent understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema description coverage is 100%. With no parameters to document, the description does not need to add parameter semantics. The baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Series de facturación configuradas' provides a general idea of the resource but lacks a verb (e.g., 'gets' or 'lists'), making it vague. It repeats the resource from the name without clarifying whether it retrieves a single series or a list, and does not distinguish it from sibling tools like 'get_invoice' or 'list_invoices'.
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. With many sibling tools for reading and writing, the description offers no context or constraints, leaving the agent to infer usage from the 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?
Annotations indicate readOnlyHint and idempotentHint are true, so the description does not need to restate these. The description adds no further behavioral context (e.g., no mention of side effects, auth, or rate limits), but it doesn't contradict annotations. A score of 3 is appropriate as the description is neutral and adequate.
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. It is front-loaded and directly states the tool's purpose. However, given the lack of parameter guidance, it could be slightly more structured, but overall it is appropriately brief for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple tool (one parameter, output schema present), the description is minimally complete. It states the purpose but does not explain that it retrieves a single customer by ID or describe the output. The presence of an output schema partially compensates, but the description could be more helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (customer_id) with no description. The tool description does not mention or explain this parameter, leaving the AI agent without semantic meaning. With schema coverage at 0%, the description provides no value beyond the schema itself.
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 'Detalle de un cliente' clearly indicates the tool retrieves details of a customer. The verb 'get' in the name aligns with the purpose. While it doesn't explicitly differentiate from sibling tools like list_customers, the singular nature and the specific noun 'customer' make the purpose evident.
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. For example, there is no mention of when to use 'get_customer' over 'list_customers' based on needing a single record versus multiple. The description lacks context for appropriate usage.
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 and idempotentHint=true, informing the agent this is a safe, idempotent read. The description adds that it returns 'full detail,' which is slightly more specific but still minimal. It does not describe any behavioral traits like potential errors or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is concise and front-loaded with the key action. It earns its place by being to the point, though it could be slightly more informative 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?
For a simple retrieval tool with one required parameter and an output schema, the description is minimally adequate. It states the tool returns full details, but does not elaborate on the output schema content or any edge cases. Given the output schema exists, the description does not need to detail return values, but it could still provide better context on what 'full detail' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fails to explain the single required parameter 'expense_id'. With 0% schema description coverage, the description should compensate by at least stating that the expense_id identifies which expense to retrieve. It does not, leaving the parameter's role ambiguous.
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 'Full detail of an expense' clearly indicates a retrieval operation on a single expense resource. It implies a get-by-ID action, distinguishing it from listing or mutation tools, but does not explicitly state the use case or differentiate from siblings like list_expenses or update_expense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_expenses for a list or get_expense_attachment for attachments. There is no mention of prerequisites, context, 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that it returns 'complete detail', implying a full record rather than a summary. This adds some context beyond annotations, but does not disclose other behavior like response format or access control.
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 quickly conveys the tool's purpose. It is front-loaded and efficient, with no unnecessary words. However, it could marginally improve by including the parameter context.
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 low complexity (single parameter, output schema exists), the description is adequate but minimal. It states the purpose but omits details like how to identify the income (via income_id) or what 'complete detail' entails. With an output schema present, the return values are covered, but the description could still be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning the parameter income_id has no description in the schema. The tool description does not compensate; it does not mention the parameter at all. The agent receives no additional meaning about the parameter beyond it being an integer and required.
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 'Complete detail of an income' clearly indicates a retrieval operation for a single income record. It distinguishes from sibling tools like list_income (listing) and delete_income (deletion) through the verb 'get' and the resource 'income'. However, it does not explicitly say 'get' or 'retrieve', but it is implied.
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 given on when to use this tool versus alternatives like list_income or get_income_attachment. There is no mention of when it is appropriate (e.g., to fetch a single record by ID) or when not to use it. The agent is left to infer from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description only needs to add context beyond that. It mentions the source 'buzón' and gives a specific filter example, but does not describe pagination, sorting, or response format. The additional context is useful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loads the core functionality. There is no wasted text, though the Spanish language might be a minor barrier for non-Spanish agents. Still, it is appropriately sized.
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 9 optional parameters and an output schema, the description is insufficient. It omits details on date filtering, keyword search, hashing, sorting, pagination, and return values. The output schema exists but is not referenced, leaving agents to infer behavior.
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 explains 'assigned' (boolean filter) and 'extension' (with format example), but 7 of 9 parameters (initial_date, end_date, keyword, hash, sort, page, page_size) are left unexplained. The description covers only about 22% of 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 states 'Lista documentos del buzón' (lists documents from the mailbox), clearly indicating a listing action on a specific resource. While it does not explicitly differentiate from sibling list tools like list_accounts, the resource is distinct enough.
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 hints at filtering use cases (assigned=False for pending expenses, extension example) but provides no guidance on when to use this tool versus alternatives like get_document for a single document or other list tools. No exclusions or prerequisites are mentioned.
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 and idempotentHint=true, indicating a safe read operation. The description does not add behavioral details beyond that, but it also does not contradict the annotations. It provides minimal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, efficient and front-loaded. However, it could be slightly more informative without sacrificing 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 existence of an output schema (not shown), the description does not need to explain return values. However, it lacks context on error handling, expected behavior for missing accounts, or relationships to sibling tools. The description is minimally complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'account_id' parameter beyond what the schema provides (integer, required). The parameter is self-explanatory given the tool name, but the description adds no semantic value for format or source.
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 'Detalle de una cuenta bancaria' clearly indicates the resource (bank account) but uses a noun phrase instead of a verb like 'get' or 'retrieve'. It distinguishes the tool as returning account details, though it does not explicitly state the action. The purpose is clear enough for a simple retrieval tool.
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 its siblings (e.g., get_customer, list_accounts). There is no mention of prerequisites, context, or alternatives. The description lacks any usage instructions.
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 and idempotentHint=true, covering safety and idempotency. The description adds return format context (Base64 with filename, data, mimetype) but no additional behavioral traits. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with key information front-loaded. However, it omits parameter details, which slightly reduces effectiveness.
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 low complexity and presence of an output schema, the description covers the basic purpose and return format. But it lacks parameter explanation, leaving a gap in 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?
Schema description coverage is 0%, yet the description does not explain the expense_id parameter. It only describes the output, failing to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the attachment of an expense in Base64 format with specific fields. It differentiates from siblings like get_document_attachment by specifying 'expense', but does not explicitly contrast with similar 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 on when to use this tool vs alternatives (e.g., get_expense, delete_expense_attachment). The description only states what it does, not when it 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 declare readOnlyHint and idempotentHint, indicating safe, read-only behavior. The description adds that the result is Base64, which is a behavioral trait, but lacks details on error handling (e.g., missing attachment) or return format structure.
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, using only a few words. It is front-loaded with the key information (attachment in Base64). However, it could be slightly more structured 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?
The description is minimal and covers the basic purpose, but with an output schema present, more details about return values are not strictly necessary. However, given the simplicity of the tool, it is adequate but not complete (e.g., no mention of behavior when income_id does not exist).
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 (income_id) with no description (0% coverage). The tool description does not mention income_id or its purpose, so it adds no value beyond the schema. Given low coverage, the description should compensate but fails to do so.
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 retrieves an attachment of an income in Base64 format, specifying the verb (get) and resource (attachment). It distinguishes from sibling tools like delete_income_attachment and get_expense_attachment, though it could be more explicit about the operation being a retrieval.
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 (e.g., get_income, delete_income_attachment). The description does not specify prerequisites or contexts where this tool is preferred.
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 include destructiveHint: true. The description adds context with a warning emoji and 'Confirmar con usuario', indicating user confirmation needed. No contradictions, but behavioral disclosures beyond the annotation are minimal.
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 short (three sentences) and front-loaded with the purpose. It uses a warning emoji and references, but the structure is slightly fragmented. Still, it is concise with minimal waste.
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 (21 parameters, 0% coverage) and the presence of an output schema, the description is incomplete. It lacks details on prerequisites, error handling, and most parameter semantics, leaving the agent under-informed.
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. It only explains 'default_expense_type' with examples and references create_customer for others. This leaves 20 undocumented parameters without any 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 clearly states 'Crea un proveedor' (creates a provider), specifying the action and resource. It distinguishes from sibling tools like create_customer by referencing it for value validation, but does not explicitly differentiate from other create 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 advises user confirmation ('Confirmar con usuario') and directs to create_customer for valid values of certain parameters. However, it does not state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, the description explains the behavior of draft, sort, and summary parameters (e.g., draft=True for drafts, sort example 'date:desc', summary returns limited fields). This adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loads the action. While efficient, it omits necessary details for some parameters, which might reduce clarity for complex filters.
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 13 parameters and a complex filter schema, the description is incomplete. It does not explain date filtering, provider, expense_type, tags, totals, or pagination, leaving significant gaps for an agent to use 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?
With 0% schema description coverage, the description compensates partially by explaining draft, sort, and summary. However, 10 out of 13 parameters (date range, provider, expense_type, investment_type, tags, min/max_total_limit, page, page_size) 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 clearly states 'List expenses' as the main purpose, specifying the resource. It distinguishes from sibling list tools by resource type, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like get_expense or other list tools. No exclusion criteria or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint true, but the description adds value by specifying Base64 encoding for data and the user confirmation step. No contradictions, and it enriches understanding of the tool's behavior beyond the annotation alone.
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 extremely concise, using one line with a warning emoji. It avoids redundancy and communicates key points efficiently, though it could be slightly expanded for 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?
With 3 required parameters and an output schema, the description omits any mention of return values or side effects. It does not clarify whether the attachment is replaced or added, leaving gaps for the agent, especially given the destructive hint.
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 compensate. It clarifies that 'data' is in Base64, but income_id and filename receive no additional explanation beyond their names. Only one of three parameters benefits from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates the attachment of an income' with specific verb and resource. It also mentions Base64 data format. However, it does not differentiate from sibling tools like delete_income_attachment or get_income_attachment, missing explicit scope distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Confirm with user' as a usage note, advising confirmation before action. However, it provides no guidance on when to use this tool versus other attachment-related tools (e.g., delete_income_attachment) or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's 'Lista' aligns. The description adds that it covers specific account types, but does not disclose pagination, ordering, or whether all accounts are returned. Beyond the annotation, behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded. The second sentence with 'type:' is somewhat terse but not wasteful. A clearer structure could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and an output schema, the description adequately conveys the core purpose. The mention of account types adds context. However, it lacks information on result ordering, pagination, or if filtering is possible (despite no parameters). Still, for a simple list tool, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and 100% schema coverage, the baseline is 3. The description adds 'type: cash|bank|card|associate' but this is not a parameter; it may describe output. This does not enhance parameter understanding 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?
The description clearly states the tool lists bank accounts, cards, and associate accounts, which is specific and distinct from get_account (single account). However, the mention of 'type: cash|bank|card|associate' suggests filtering, but the input schema has no parameters, leading to slight confusion.
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 like get_account. There is no mention of prerequisites or exclusions. The sibling list tools (list_customers, etc.) are similar, but no differentiation 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 destructiveHint=true, so mutation is expected. The description adds a warning emoji and mentions 'Actualiza', consistent with mutation, but does not detail repercussions of updates.
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 short and front-loaded with a warning. It efficiently conveys the purpose and parameter shape, but could be better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. However, the description omits prerequisites (e.g., expense must exist) and error conditions, leaving gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It briefly outlines the payment object structure with example fields, but lacks details on required fields, constraints, or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action: 'Actualiza pagos de un gasto' (updates payments of an expense) with an example. However, it does not differentiate from sibling tools like mark_expense_paid.
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, nor any context on prerequisites or constraints such as requiring the expense to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true, and the description adds a warning emoji and 'Confirmar con usuario', reinforcing the destructive nature. However, it does not disclose additional behavioral traits such as required permissions, irreversibility, 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 short and front-loads the warning with a bullet-like structure for parameter conditions. It is efficient, but the mixed language (Spanish) and lack of formal structure reduce clarity slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 21 parameters (6 required) and an output schema (not shown), the description covers the conditional business_type logic and some enum values but fails to explain the purpose of required fields like region, address, or postal_code. The return value is not mentioned, though the output schema may compensate.
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?
Despite 0% schema description coverage, the description explains conditional requirements for business_type (name/surname_1 vs business_name) and lists allowed values for default_invoice_language and tax_id_type. This adds significant meaning beyond the schema, though some required parameters like region, address, etc. are not explained.
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 'Crea un cliente' (creates a customer) and includes a warning to confirm with the user. It distinguishes from sibling tools like create_provider or create_invoice. However, the title is null and the description is in Spanish, which may reduce clarity for non-Spanish agents.
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 'Confirmar con usuario', suggesting the tool should only be used after user confirmation, but provides no explicit guidance on when to use this tool versus alternatives like update_customer or delete_customer. There is no context for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description is consistent with a destructive action. The description adds the warning emoji and enumerates payment methods, but does not disclose other behavioral traits like irreversibility or account balance impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two lines) and front-loads the purpose. However, the mix of Spanish and English and lack of structured formatting (e.g., bullet points) slightly reduces clarity.
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 6 parameters with no schema descriptions and no param info in the description (except payment_method), the description is insufficient for agents to correctly invoke the tool. An output schema exists but is not described.
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 adds semantics for payment_method (listing three options). Parameters like amount, concept, origin_account, destination_account, and date remain unexplained, leaving the agent with minimal 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 clearly states it creates a transfer between accounts ('Crea traspaso entre cuentas'), which distinguishes it from tools like create_expense or create_income. However, it does not explicitly compare to siblings or highlight unique aspects beyond 'entre cuentas'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit instruction: 'Confirmar con usuario' (confirm with user), which tells the agent to ask for confirmation before executing. It also lists payment method options, guiding selection. No when-not-to-use or alternatives 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 declare readOnlyHint=true and idempotentHint=true, so the agent knows it is safe and idempotent. The description adds minimal behavioral context beyond stating it returns details. It does not disclose the output format, but an output schema exists, reducing the burden.
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 (one short phrase) but lacks structure. It does not follow a pattern like action+resource+scope. While there's no wasted text, it 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. However, for a tool with one required parameter, the description is very minimal and does not address potential edge cases or prerequisites. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'transfer_id' is self-explanatory and the description implies it identifies the transfer. However, schema description coverage is 0% and the description provides no additional meaning or constraints beyond the parameter name and type.
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 'Detalle de un traspaso' clearly indicates it retrieves details of a single transfer. It distinguishes from the sibling list_transfers by implying a single item retrieval. However, it lacks an explicit verb in English and does not differentiate from other 'get_*' tools like get_customer.
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 when-to-use or when-not-to-use guidance is provided. It is implicitly used for obtaining full details of a specific transfer, with list_transfers as an alternative for an overview. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only includes a warning emoji and the bare action. Annotations already indicate destructiveHint=true. No additional behavior is disclosed, such as whether charges are replaced or merged, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—one line with a warning emoji and a parameter template. It is front-loaded and efficient, though the template could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and the destructive nature, the description is minimally complete. It provides the essential purpose and parameter structure, but lacks details on error states, return values, or behavior for missing income_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides a detailed template for the charges array: [{id?, paid, amount, date, payment_method, destination_account}]. This adds significant meaning beyond the schema, clarifying expected fields and that id is optional.
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 updates charges of an income ('Actualiza cobros de un ingreso'), which is specific and matches the name. However, it does not explicitly differentiate from similar sibling tools like update_income or update_invoice_charges, though the charge structure provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 update_income (which might update income metadata) or update_invoice_charges (similar for invoices). The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'irreversible' and 'confirm with user' beyond the destructiveHint annotation, providing clear behavioral context about permanence and user interaction.
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 a single line and a warning emoji. It front-loads the key action and consequence, though it could include parameter details.
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, return values need not be explained. However, the single parameter lacks description, and the usage guidance is minimal. It is adequate for a simple delete but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the expense_id parameter. The parameter name is self-explanatory, but the tool description should explicitly specify its role.
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 deletes an expense and emphasizes irreversibility. However, it does not explicitly differentiate from sibling delete tools like delete_expense_attachment, though the resource name 'expense' is distinct.
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 instructs to confirm with the user, which is a usage guideline for destructive actions. It lacks details on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns about destructive effects (destructiveHint=true) and explains the behavior for income_lines and charges: with ID updates, without ID creates, omitted deletes. This adds valuable behavioral context beyond the annotation.
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?
Very concise single sentence with visual warning. Front-loaded with important safety note. Efficient but could benefit from clearer structure for the array rules.
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 9 parameters (4 required) and no schema coverage, the description provides key behavioral logic for arrays but lacks details on other parameters, error handling, or success conditions. An output schema exists, so return values need not be explained, but overall completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the semantics for income_lines and charges arrays, but other parameters like income_id, customer, date, etc., are not described. Partial compensation.
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 'Actualiza ingreso' (update income) with a warning, clearly indicating the verb and resource. However, it is in Spanish and could be more explicit about the overall action, distinguishing it from sibling tools like create_income or delete_income.
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 update_income vs alternatives (e.g., update_income_charges, update_income_attachment). The warning to confirm with user is included, but no context about when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, indicating safe read operation. Description adds no further behavioral details (e.g., response format, pagination). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the purpose. Front-loaded with no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema, the description is sufficient. However, adding a brief note about the tag context (e.g., linked to entities) would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Description adds nothing beyond schema, but baseline for 0 params is 4. No need for additional param info.
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 the tool lists all available tags, with a specific verb and resource. However, it does not distinguish from sibling list_* tools, though the resource 'tags' is unique among them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 list_accounts or list_customers. An agent would need to infer from context that this is specifically for tags.
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 destructiveHint annotation already flags this tool as destructive. The description adds a warning emoji and confirmation instruction, which aligns with the annotation. However, it does not disclose other behavioral traits such as side effects on invoice status, permissions needed, or email delivery guarantees.
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 (one line), which is good, but it lacks structure and is insufficient for a tool with 9 parameters. Important information about parameters and return values is missing, making it under-specified.
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 9 parameters, no parameter descriptions, a destructive hint, and an output schema, the description is incomplete. It does not mention prerequisites (e.g., invoice existence), return value, or potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning the description must explain parameter meanings. However, the description does not mention any parameter, leaving the agent to infer from names only. Parameters like 'cc_me', 'show_card_payment', and 'include_pdf' are not self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Envía la factura por email') and the object (invoice). It is distinct from sibling tools, which are CRUD or other operations on invoices. The warning emoji and instruction to confirm further clarify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to confirm with the user before executing, providing a clear usage guideline. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_invoice_pdf or get_invoice_public_link), though the context implies it is for direct email sending.
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 include destructiveHint=true. The description adds a warning emoji and lists the specific update actions, but does not elaborate on side effects or undoability.
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 line with an appropriate warning front-loaded. It is efficient but could benefit from additional context in English.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with three parameters and an output schema, the description covers core functionality. However, it lacks details on date format, the effect of null values, and an English translation for broader usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains the purpose of expense_id and date parameters ('asignar a gasto y/o cambiar fecha'), adding value 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?
The description specifies the resource (document) and actions (assign to expense, change date). It clearly states what the tool does, but does not explicitly differentiate from sibling tools; however, the sibling tools have different resource names.
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 instruction 'Confirmar con usuario' (confirm with user) provides a usage guideline, but it does not specify when to use this tool versus alternatives or provide prerequisites.
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 include destructiveHint=true. The description adds the need for user confirmation, which is a critical behavioral trait beyond the annotation, though it doesn't detail other implications like overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short phrases, front-loading the action and adding only necessary details. No wasted 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?
Despite having an output schema and annotations, the description omits important context like file size limits, accepted formats, or linking to expenses. For 4 parameters with zero schema descriptions, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description clarifies that the 'data' parameter must be Base64-encoded, which is essential. However, it does not explain 'filename', 'date', or 'expense_id' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Sube' (upload) and resource 'documento al buzón' (document to mailbox), differentiating it from other resource-focused create 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 siblings like create_customer or update_document. The instruction 'Confirmar con usuario' is a user directive, not an AI usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds the explicit warning of irreversibility ('irreversible') and the need for user confirmation, providing helpful behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single line with a warning emoji, and front-loads the critical destructive action. Every word earns its place with no 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?
For a simple delete tool with output schema and annotations, the description is minimal but covers the essential destructive context. However, it lacks parameter explanation and fails to mention the attachment relationship, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the income_id parameter or how to obtain it. It only mentions 'income' in the resource context, failing to add meaning beyond the schema's bare type.
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 'Elimina' (deletes) and the resource 'adjunto de un ingreso' (attachment of an income), specifying the exact operation. It effectively distinguishes from sibling tools like delete_expense_attachment by naming the specific resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by requiring user confirmation ('Confirmar con usuario'), but lacks explicit guidance on when to use this tool versus alternatives like delete_income or delete_expense_attachment. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds that the operation is irreversible and requires user confirmation, which goes beyond the destructiveHint annotation. Provides important behavioral context for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a warning emoji and two key points: action and confirmation requirement. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple one-parameter delete tool with output schema present, but does not mention any side effects or cascading deletions. Could be more complete.
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 information about the transfer_id parameter. Agent receives no guidance on what to provide beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Elimina' (delete), resource 'traspaso' (transfer), and emphasizes irreversibility. It distinguishes from sibling delete tools by specifying 'transfer'.
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?
Includes instruction to confirm with user, implying when to use, but does not explicitly state when not to use or mention alternative tools. Guidelines are minimal but present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat safety. It adds minimal behavioral context (listing, not modifying). 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 very short (two sentences) and front-loaded with the main purpose. It is efficient but could be slightly more structured (e.g., listing available filters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the readOnly annotation and presence of an output schema, the description does not explain pagination, default sort order, or how to interpret the output. With 10 parameters and zero schema descriptions, the tool is under-documented for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds meaning for one parameter (payment_method with enum values). Other parameters like origin_account, dates, limits, sort, pagination are left unexplained, forcing reliance on parameter names which may be ambiguous.
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' (list) and the resource 'traspasos entre cuentas' (transfers between accounts). It also provides the allowed values for payment_method, distinguishing it from other list tools for 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for listing transfers, but lacks explicit guidance on when to use vs. alternatives like get_transfer (single record) or list_accounts (different entity). However, the context from sibling tool names and the tool's name is clear enough for an AI agent.
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 only declare destructiveHint: true. The description adds behavioral context: the emoji warning and 'Confirmar con usuario' indicate that this operation is destructive and requires user approval. It also tells the agent to look at create_customer for valid values, which is useful beyond the annotation.
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, consisting of a single line with a warning and two instructions. It is front-loaded with the warning icon, making key information prominent. However, it lacks structure (e.g., separating warnings from instructions) but remains efficient.
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 for a complex tool with 22 parameters, 7 required, and destructive behavior is severely incomplete. It does not specify that customer_id must exist, how partial updates work (PATCH vs PUT), or any error conditions. The reference to create_customer is helpful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 22 parameters (7 required). The brief mention to 'Ver create_customer' does not directly add meaning to the parameters here. The description fails to compensate for the lack of schema descriptions, leaving the agent without guidance on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Actualiza un cliente' (updates a customer), which is a specific verb and resource. It distinguishes itself from sibling tools like create_customer and delete_customer by implying it is for modifying existing customers. The warning emoji and call to confirm with user add clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Confirmar con usuario' (confirm with user) and references create_customer for valid values. This tells the agent when to proceed carefully and where to find input constraints, though it does not explicitly state when not to use this tool versus alternatives like create_customer.
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?
While the destructiveHint annotation already flags the tool as destructive, the description adds the important context that the action is irreversible and requires user confirmation. This provides behavioral transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a warning emoji, front-loading the key information. Every word is meaningful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description covers the essential behavior (deletion, irreversibility, need for confirmation). It does not mention the output schema, but per guidelines that is not required. Minor room for improvement: could note any side effects or dependents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the only parameter (document_id), and the description does not explain what document_id represents, how to obtain it, or any constraints. The description adds no semantic value for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('deletes a document') and the resource ('document'), distinguishing it from sibling tools like delete_customer or delete_invoice. The irreversibility is explicitly noted, leaving no ambiguity.
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 includes a usage guideline: 'Confirm with user', indicating this tool should not be used without user consent. However, it does not specify when to use it over alternatives (e.g., why not use another delete tool for a different entity) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, indicating a write operation. The description adds a visible warning emoji and user confirmation requirement, plus explicit structure for expense_lines and payments. This goes beyond the annotation without contradicting it. However, it does not fully describe all behavioral traits (e.g., idempotency, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and uses line breaks to separate concerns. It front-loads the purpose and warning. However, the inline parameter structures could be cleaner (e.g., proper formatting), and the information is somewhat crammed into a single block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects), the description partially explains the most complex fields (expense_lines, payments) but omits required fields like date, draft, provider, and optional ones like tags. With an output schema present, return values need not be covered, but overall completeness is adequate but not thorough.
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 0% description coverage, so the description must compensate. It provides subfield details for expense_lines (description, base, tax, retention, imputation, expense_type, investment, investment_data) and payments (amount, payment_method, paid, origin_account, date, destination_account), plus document_type and vat_eu conditions. This adds significant meaning, though several parameters (date, draft, provider, document_number, annotations, tags) are not explained.
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 'Crea un gasto' (creates an expense), providing a specific verb and resource. It distinguishes from siblings like create_income by focusing on expenses. The warning emoji and 'Confirmar con usuario' do not detract from the clear purpose.
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 (e.g., create_income or update_expense). The only usage hint is 'Confirmar con usuario' (confirm with user), which is a safety note, not a when-to-use condition.
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 indicate destructiveHint=true. The description adds value by warning to confirm with the user, and by detailing the structure of invoice_lines and charges, including possible enum values for tax and payment methods. This provides behavioral context beyond the mere destructive flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise given the complexity, starting with a warning and then listing parameter details in a bullet-like format. It is front-loaded with the key instruction. Minor verbosity from repeated examples, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are not needed. However, with 14 parameters and complex nested objects, the description only covers a subset (invoice_lines and charges). Required field 'issued' and optional fields like customer, description, date are left unexplained, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the structure of invoice_lines and charges, and lists allowed values for sell_type, tax, tax_regime, tax_subjection_code, and payment_method. However, many parameters (issued, customer, date, etc.) are not described, leaving gaps.
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 'Crea una factura' (creates an invoice) and includes a warning to confirm with the user. It distinguishes this tool from siblings like create_expense, create_income, etc., which create different entity types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to confirm with the user before executing, which is a safety guideline. However, it does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives like create_document or update_invoice. The context is implied by the tool name and sibling list.
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 explicitly labels the action as 'irreversible' and requires user confirmation. The annotation destructiveHint: true is present, and the description adds the need for user confirmation, which is beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a warning icon, conveying all essential information without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, irreversibility, and user confirmation, but lacks parameter details. With an output schema present, return values are not needed, but the parameter gap reduces completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no description for expense_id), and the description does not explain the parameter. It only appears in the schema without any added meaning, which fails to help the agent understand the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'elimina el adjunto de un gasto' (delete expense attachment), using a specific verb and resource. This distinguishes it from siblings like delete_expense (delete whole expense) and delete_income_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Confirmar con usuario' (confirm with user), indicating when to use this tool (only after user confirmation). It does not explicitly list alternatives, but the sibling names and context make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds the explicit warning of irreversibility and the need for user confirmation, offering behavioral context not captured by annotations alone.
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 conveys the essential action and warning, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and a destructive annotation, the description provides sufficient context about the action and required caution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the `income_id` parameter, which has 0% schema description coverage, leaving the agent without guidance on what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Elimina un ingreso') and the resource, including a warning of irreversibility, which distinguishes it from sibling tools like delete_expense.
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 instruction 'Confirmar con usuario' provides context for safe usage, but there is no explicit guidance on when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as destructive. The description adds 'irreversible' and a user confirmation requirement, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences to convey purpose, irreversibility, and the need for user confirmation. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and user confirmation, but lacks information about output or error handling. Given the tool's simplicity and the presence of an output schema, some additional context would be beneficial.
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 adds no meaning for the invoice_id parameter. The sole parameter is implied by the tool name, but the description does not clarify its format or required nature.
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 deletes an invoice and is irreversible, which matches the name and distinguishes it from other invoice-related tools like void_invoice.
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 instructs to confirm with user, providing a usage hint, but does not specify when not to use this tool or mention alternatives like void_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true, so the description does not need to restate that. It adds minor behavioral context (sorting example, summary behavior) but does not disclose any additional traits like authentication needs or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two short sentences, front-loading the core distinction and key parameter usage. Every sentence adds essential value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complex input schema (10 parameters) and no schema descriptions, the description does not explain the purpose of parameters like initial_date, end_date, customer, tags, min_total_limit, max_total_limit, page, page_size, or the output schema. It leaves the agent with incomplete information for tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage for 10 parameters, the description only explains two parameters (sort and summary). It provides some semantic value but fails to cover the remaining eight parameters, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Lista ingresos (no facturas)' which clearly distinguishes it from the sibling tool 'list_invoices'. It also includes a sorting example, making the purpose specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a sorting example and explains the summary parameter. The phrase 'no facturas' implicitly guides the agent to use this tool for incomes instead of invoices, but it lacks explicit when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description explicitly states the operation is irreversible and requires user confirmation, adding valuable behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with critical info (destruction, irreversibility, confirmation), and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and an output schema, the description covers the essential behavioral aspects (irreversible, confirm). Missing parameter description is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the provider_id parameter, despite 0% schema coverage. The agent receives no guidance on what value to pass or its meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Elimina un proveedor') and resource ('proveedor'), with additional emphasis on irreversibility. It distinguishes delete from sibling create/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to confirm with user and notes irreversibility, providing clear usage context. However, it does not explicitly mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: automatic current year for drafts without specified dates, sort example, and summary functionality reducing tokens. Annotations already declare readOnlyHint=true, so the description supplements with specific query behaviors.
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 relatively concise, conveying key points in a few sentences. It could benefit from better structuring (e.g., bullet points), but it is not verbose and front-loads 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 13 parameters and an output schema, the description covers core filtering (issued, dates, sort, summary) but omits many filters and pagination details. The output schema exists, so return values are documented, leaving moderate gaps in 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?
With 0% schema description coverage, the description compensates by explaining issued, dates, sort, and summary parameters. However, many parameters (customer, description, serie, tags, min_total_limit, max_total_limit, page, page_size) are not described, leaving significant gaps.
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 it lists invoices, distinguishes between issued and drafts, and mentions summary mode. The verb 'Lista' and resource 'facturas' are specific, and the description differentiates it from siblings like list_expenses or list_income.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using the issued parameter to toggle between issued and drafts, mentions automatic year for drafts without dates, and explains the summary parameter for reduced tokens. However, it does not explicitly state when to use this tool versus other list tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true). The description adds transparency by detailing the search scope (multiple fields) and the summary flag's effect on returned fields. It does not contradict annotations and provides useful behavioral context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences in Spanish, front-loaded with the main action, and contains no unnecessary words. Every sentence provides valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not shown), the description covers the search behavior and summary option adequately. It could mention pagination explicitly, but the schema provides defaults. Overall, it is fairly complete for a list 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?
With schema description coverage at 0%, the description compensates by explaining the 'q' parameter (searches in specific fields) and the 'summary' parameter (returns a reduced set of fields). The 'page' and 'page_size' parameters are not explained but are standard pagination with defaults; the description adds meaningful value for the non-obvious 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 clearly states it lists providers ("Lista proveedores") and explains the search parameter and summary behavior. However, it does not explicitly differentiate from sibling list tools like list_customers, so it is clear but not explicitly distinguishing.
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 through the search and summary options but provides no explicit guidance on when to use this tool versus alternatives like get_provider or other list tools. No when-to-use or when-not-to-use advice is given.
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?
Beyond the destructiveHint annotation, the description discloses that the 'data' parameter must be Base64 encoded and that user confirmation is required. This adds useful behavioral context. However, it does not mention side effects like replacing or deleting the previous attachment, which would be expected for an update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line with a warning emoji, the main action, data format requirement, and a user confirmation note. Every sentence adds value. There is no repetition of schema annotations or other unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple update tool: it states the purpose and a key constraint (Base64). However, it lacks context about the effect on existing attachments (e.g., replacement or deletion), potential requirements (e.g., existing expense must exist), and does not guide the agent on handling errors or outcomes. The presence of an output schema is noted but not described, which is acceptable per rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only adds semantic meaning for the 'data' parameter by stating it must be in Base64 format. For 'expense_id' and 'filename', no additional meaning is provided beyond the schema's property names and types. Given that schema description coverage is 0%, the description partially compensates but is not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Actualiza el adjunto de un gasto' (updates the attachment of an expense), specifying the verb and resource. It distinguishes from siblings like get_expense_attachment, delete_expense_attachment, and create_expense by focusing on updating an existing attachment.
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 includes 'Confirmar con usuario' (confirm with user), implying this tool should be used with caution and explicit user consent, which provides some usage context. However, it does not explicitly state when to use this tool over alternatives like delete_expense_attachment plus create_expense, nor does it list prerequisites or forbidden scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the warning emoji and instruction to confirm with the user, which goes beyond the destructiveHint annotation by specifying a required user interaction. This provides additional behavioral context, alerting the agent to a necessary step before invocation.
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 sentences with a warning symbol. It is front-loaded with the key action and a critical usage note. Every word serves a purpose, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive annotation and presence of an output schema, the description adequately covers the need for user confirmation. It does not explain return values (unnecessary due to output schema), and the parameter details are left to the schema. For a destructive mutation tool, the description is sufficiently complete with the usage instruction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not mention any parameter. With 7 parameters (5 required), the description provides no semantic guidance about what each parameter represents or how to use them, leaving the agent without field-level understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Actualiza un traspaso' (update a transfer), using a specific verb and resource. It clearly distinguishes itself from sibling tools like create_transfer, delete_transfer, get_transfer, and list_transfers by indicating an update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Confirmar con usuario' (confirm with user), providing a clear usage guideline about when to use this tool—only after user confirmation due to its destructive nature. It does not explicitly state when not to use or list alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, and description adds 'irreversible' and 'confirm with user,' providing behavioral context beyond what the annotation alone conveys.
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?
Description is extremely concise with no wasted words; every sentence adds value: states action, irreversibility, and needed confirmation.
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?
Provides essential purpose and safety guidance but lacks explanation for the parameter and return values. With an output schema present, return values need not be described, but parameter semantics are missing.
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 sole parameter 'customer_id' (integer, required), leaving the agent to infer its meaning from context alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Elimina un cliente (irreversible)' with a specific verb ('elimina') and resource ('cliente'), distinguishing it from siblings like create_customer, update_customer, and get_customer.
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?
Includes 'Confirmar con usuario' indicating the need for user confirmation before use. Provides clear context for usage but does not explicitly state when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds useful context that the link includes a Stripe payment button, beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded and concise. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema and clear parameter, description adequately covers functionality. Could mention that the link is public or that it requires a valid invoice, but overall sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the single required parameter 'invoice_id' is self-explanatory from its name and tool purpose. Description does not add further details on parameter formatting or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides a public link for an invoice to share with the client, including a Stripe payment button. This distinguishes it from siblings like get_invoice (detail), get_invoice_pdf (PDF), and send_invoice_email (email).
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 sharing a link with clients, but does not explicitly state when not to use or mention alternatives. No explicit guidance on choosing between this and related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the destructiveHint annotation: it automatically fetches the expense, sets paid=True for all payments, and updates. It also specifies the payment_date format (yyyy-MM-dd). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (3 sentences) and front-loaded with the core action and a warning emoji. Each sentence serves a purpose: action, process, and date format + user confirmation. It is efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (2 required) and an output schema exists, the description covers the main behavior and the payment_date format. However, it omits details about the payment_method parameter and does not mention the return value, though the output schema may fill that gap. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must add meaning. It partially does by specifying the payment_date format (yyyy-MM-dd) and implying the role of expense_id. However, the payment_method parameter is left unexplained, and the description does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Marca todos los pagos de un gasto como pagados' (marks all payments of an expense as paid). It distinguishes itself from the sibling tool update_expense_payments by claiming it is faster and more automated, providing a clear verb-resource-scope definition.
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 mentions when to use this tool (to mark all payments as paid quickly) and names a faster alternative (update_expense_payments). It includes a confirmation step ('Confirmar con usuario'), but lacks explicit when-not-to-use scenarios or other alternatives beyond the one mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true, covering safety and idempotency. The description adds that the result is Base64 content, providing useful behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. Every word is informative and the description is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple read-only tool: it specifies the input (implicitly via schema), the output format (Base64), and its safe nature (via annotations). The output schema exists, so return details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description should compensate by explaining the parameter invoice_id, but it does not. However, the single integer parameter is self-explanatory given the tool's purpose, so a moderate score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Descarga' (download) and the resource 'PDF de la factura' (invoice PDF), distinguishing it from sibling tools like get_invoice (returns invoice data) and get_invoice_public_link (returns a link).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool's purpose but does not explicitly guide when to use it versus alternatives like get_invoice_public_link or send_invoice_email. The context implies it is for obtaining the PDF file content directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true. The description adds behavioral context beyond annotations: it explains that q searches across specific fields and that summary=True returns a subset of fields. This adds useful detail without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences front-loading the core action and then adding parameter specifics. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, optional paging), the description covers search and summary but omits pagination behavior entirely. With an output schema present, return format is covered, but missing paging guidance leaves the description slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden. It explains the 'q' parameter (searches in razon social, direccion, CIF, telefono, email) and 'summary' (returns id, tradename, cif, email). However, 'page' and 'page_size' are left unexplained, making it partially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' (lists) and the resource 'clientes' (customers). It distinguishes itself from siblings like 'get_customer' by specifying search capabilities across multiple fields and a summary mode, making its purpose and scope specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing/searching customers but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_customer for a single customer). No when-not-to-use or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true; description adds context: it modifies invoice charges, sets paid=True, updates payment_date. Includes warning emoji and confirmation note. Discloses behavioral traits beyond annotation, though lacks info on idempotency or handling of already-paid charges.
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 plus a warning emoji; purpose is front-loaded. Efficient but the warning emoji does not add structural clarity. Overall good conciseness with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations and output schema presence, description covers core effect, usage hint, and one parameter format. Does not mention impact on existing payments or partial payments, but sufficient for agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds payment_date format (yyyy-MM-dd) but does not describe invoice_id or payment_method. Partial compensation, placing score at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it marks all charges of an invoice as paid, using specific verbs and resource. It distinguishes itself from sibling tool update_invoice_charges by noting it's faster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Faster than update_invoice_charges', indicating when to use this tool over an alternative. Also notes 'Confirm with user' implying a batch operation needing confirmation. Good guidance but does not mention other similar tools like mark_expense_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?
The description adds detail beyond the destructiveHint annotation by explaining the update/create/delete logic for invoice lines and charges, though it omits other potential side effects or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a reference) with no redundant information, using a warning emoji and a clear directive.
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 the description covers the key array behavior and leverages the output schema, it does not explain the effect of omitting optional parameters or provide full context for a destructive tool with many parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only clarifies the invoice_lines and charges parameters; the remaining 11 parameters are left undescribed, relying on their names for meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Updates invoice' and details the behavior for lines/charges (update with id, create without, delete if omitted), clearly distinguishing from siblings like update_invoice_charges and create_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises to confirm with the user ('Confirmar con usuario') for a destructive action and directs to create_invoice for structure, but does not explicitly state when to use this tool over alternatives like update_invoice_charges.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint: true annotation, the description explains the CRUD behavior: charges with id are updated, without id are created, omitted are deleted. This provides clear behavioral transparency about side effects and data manipulation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences and a list. The warning emoji and 'Confirmar con usuario' front-load important context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), the description need not detail return values. It covers input parameters well with structure and behavior. Minor gaps: doesn't specify date format or payment_method enumeration, but overall complete for a CRUD tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing the structure of charges (id?, paid, amount, date, payment_method, destination_account) and the CRUD logic for each. This adds crucial meaning absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates invoice charges (e.g., marking as paid) in Spanish, which is the verb and resource. It distinguishes from siblings like mark_invoice_paid or update_income_charges by specifying 'cobros de una factura' (invoice charges).
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 mark_invoice_paid or update_income_charges. The only usage hint is 'Confirmar con usuario' (confirm with user), which is a safety note rather than a selection criterion.
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?
Description adds value beyond the destructiveHint annotation by noting irreversibility and the need for user confirmation. It also adds the constraint 'Solo facturas Verifactu', which is not in annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise yet packed with essential information: action, scope, irreversibility, and confirmation requirement. Every element is justified and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive action, the description covers the key aspects (what, irreversible, scope, confirmation). No mention of return value, but an output schema exists. Slightly incomplete for a fully self-contained description.
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 does not mention the invoice_id parameter or provide any additional context. While the parameter is simple, the description should clarify its role (e.g., the ID of the invoice to void).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('anula factura'), the scope ('Verifactu'), and the irreversibility. It clearly distinguishes from sibling tools like delete_invoice by emphasizing this is a specific Verifactu void operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that it only applies to Verifactu invoices and advises confirmation with the user. However, it does not explicitly compare to alternatives (e.g., delete_invoice) or state when not to use it beyond the invoice type constraint.
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 communicate readOnlyHint and idempotentHint, so the description adds limited new behavioral context beyond listing returned fields. It does not disclose potential authorization needs, data source, or cache behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no redundant information. Every word is necessary.
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 zero parameters, clear annotations, and existence of an output schema, the description is sufficient for a simple retrieval tool. It covers the key fields returned, though it could mention that this is the user's own company data.
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 in the input schema (100% coverage), so the description does not need to add parameter meaning. The baseline of 4 is appropriate as it adds no confusion.
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 returns 'Datos del negocio: nombre, CIF, dirección, series de facturación, logo' (business data: name, tax ID, address, billing series, logo), which is a specific verb and resource. It distinguishes from siblings as other get_* tools are for different entities (e.g., customer, account).
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 retrieving company data, and sibling tools clarify alternatives for other entities. However, it does not explicitly state when to use this tool versus others or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a warning icon and explicit 'confirm with user' instruction beyond the destructiveHint annotation. It details the CRUD behavior for sub-entities (lines/payments), providing transparency on data modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) yet packs essential information: purpose, user confirmation requirement, and sub-entity behavior. Every word earns its place, and the structure is front-loaded with the warning and action.
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 complexity (11 parameters, 7 required, destructive action, output schema), the description adequately covers the update behavior and sub-entity rules. However, it lacks details on parameter format, return value, error states, and idempotency, which could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains the behavior for expense_lines and payments parameters (update/create/delete rules). Other critical parameters like expense_id, date, draft, provider, etc., remain undocumented, leaving significant ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an expense, using the verb 'Actualiza' (updates) and the resource 'gasto' (expense). It distinguishes from sibling tools like create_expense and delete_expense by focusing on update behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to confirm with the user before execution, aligning with the destructive nature. It explains the behavior for lines and payments (update/create/delete based on ID presence). However, it does not explicitly mention when not to use this tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. Description adds the exact return format, which is helpful. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second states return structure. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only aggregate with zero parameters, the description fully covers what the tool does and its output. Sibling tools provide context for when this is appropriate.
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?
No parameters in input schema, so schema coverage is 100%. Description adds nothing about parameters, but baseline is 3 per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a summary of balances from all accounts (bank, cards, cash) with a specific return structure. It distinguishes from sibling tools like get_account (single account) and list_accounts (list) by being an aggregate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Una sola llamada' (single call) implying efficiency. While it doesn't explicitly list when to avoid, the context of sibling tools provides clear alternatives. No exclusions given, but minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains it aggregates data and calculates VAT, indicating a read-only operation. Annotations already provide readOnlyHint=true, so the bar is lower; the description adds value by detailing the return structure and the aggregation logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: first states purpose and input, second explains aggregation, third gives output structure. No redundant information; all sentences are necessary and well-organized.
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 low complexity (2 params, output schema described) and annotations, the description covers purpose, input range, behavior, and output shape. It lacks error handling or edge cases, but is sufficient for a read-only summary 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?
Schema has 0% description coverage, so the description must compensate. It specifies the valid quarter range (1-4), adding semantic clarity missing from the schema, which only defines integer type without constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a quarterly VAT summary, specifying that it aggregates invoices and expenses to calculate VAT payable. It differentiates from sibling tools by offering a single-call aggregation instead of manual iteration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Una sola llamada en vez de iterar manualmente,' advising when to use it as an alternative to manual calls. It does not specify when not to use it or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds key behaviors: automatic iteration over all pages, exclusion of voided/paid invoices, and return structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences covering purpose and behavior, plus a clear parameter note and return format. Every sentence adds value, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the return format and pagination behavior. It lacks explicit mention of permissions or error cases, but for a read-only tool with one optional parameter, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully explains the 'year' parameter with an example and default behavior ('Sin year devuelve todos los pendientes'). This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a summary of pending collection invoices, automatically paginates, and excludes voided and paid invoices. It distinguishes from siblings like 'list_invoices' by focusing on pending collections.
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 explains automatic pagination and filtering by year, but does not explicitly contrast with sibling tools like 'list_invoices' or 'get_invoice'. It provides clear context on what the tool does and when to use it.
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:

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

Score Badge

Copy to your README.md:

[![cuentica-mcp MCP server](https://glama.ai/mcp/servers/dacmail/cuentica-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dacmail/cuentica-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/dacmail/cuentica-mcp'

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