Frihet MCP Server

Server Quality Checklist

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

Latest release: v1.16.3
Disambiguation4/5
Most tools have distinct purposes, but with 148 tools, some overlap exists (e.g., send_invoice vs send_einvoice, list_invoices vs search_invoices). Overall, the actions and targets differentiate tools sufficiently.
Naming Consistency3/5
Many tools follow verb_noun pattern, but there are inconsistencies like 'leave_request_create' (noun_noun_verb) and prefixes (frihet_, gestoria_) that break uniformity. Still readable overall.
Tool Count1/5
148 tools is excessive for an MCP server. While the server covers a broad ERP scope, the count is far beyond the typical 3-15 range, making the surface overwhelming.
Completeness3/5
Covers many domains comprehensively (invoicing, e-invoicing, tax models, HR), but missing basic CRUD for clients (no create_client or delete_client), which is a notable gap in the client lifecycle.
Average 4/5 across 148 of 148 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 4 community issues answered or closed in the last 6 months
- 119 commits in the last 12 weeks
- Last stable release on August 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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 provide minimal behavioral hints (readOnlyHint=false, destructiveHint=false). The description adds that context is preserved but does not disclose side effects (e.g., notifications, permissions, whether thread is auto-created).
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?
Has two paragraphs (English and Spanish) that repeat the same information. Could be more concise by using one language, but front-loaded with the action and examples.
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?
Covers the essential purpose, parent types, and use cases. Lacks details on thread creation behavior (if thread doesn't exist) and permissions. Output schema exists but is not shown; description does not need to cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with bilingual explanations. The description adds a concrete example mapping to parameters, reinforcing meaning of enum values.
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?
Clearly states it sends a message in a contextual thread between gestor and client, and lists the parent types. Distinguishes the send action from list/bulk/template siblings, but does not explicitly mention them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of when to use (chasing documents, replying, annotating) and a concrete example. Does not specify when not to use or mention alternatives like gestoria_messages_list or template tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the returned fields (capacity, owner info, license number), which provides some context beyond annotations but no additional behavioral traits like rate limits or state changes.
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 (two sentences) and front-loaded with purpose. The bilingual text adds length but is not excessive. Could be more concise by dropping one language, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers the tool's purpose and main returned fields. For a read-only list tool with annotations, it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all 6 parameters. The description does not add any meaning beyond the schema; it only mentions returned fields, not parameter details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists rental properties with specific fields (name, address, etc.). The verb 'list' and resource 'properties' are explicit. However, it does not differentiate from sibling list tools (e.g., list_invoices) other than by name, which is acceptable but not exemplary.
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, nor when not to use it. The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool's safety profile is clear. The description adds general context about webhooks (HTTP POST notifications) but does not disclose additional behavioral traits like pagination or ordering. This adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences per language. It front-loads the main action. The bilingual text is slightly redundant but not excessive. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are documented externally. The description covers the tool's purpose and basic context. It does not mention pagination or filtering, but given the schema covers those, it is adequate for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 100%, meaning all parameters have descriptions in the schema. The tool description adds no further explanation of parameters beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all configured webhooks') and the resource. It is a specific verb+resource. Although there are sibling tools like get_webhook, create_webhook, etc., the description does not explicitly differentiate from them, but the intent is clear.
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 (e.g., get_webhook). It simply states what it does. There is no mention of 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 indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds context that it logs CRM activities, which is consistent. No additional behavioral details like permissions or side effects are provided, but annotations cover the basics.
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 two sentences plus a repeated bilingual version. It is reasonably concise but includes Spanish repetition, making it slightly longer than necessary. Front-loading is good with a clear action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (3 required) and an output schema (not shown). The description doesn't explain return values, but the output schema covers that. For a logging tool, the description is adequate but could mention response behavior (e.g., returns created activity ID).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented in the schema. The description provides an example that demonstrates parameter usage (clientId, type, title, description) but does not add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Log' and resource 'CRM activity against a client', making the purpose clear. It provides examples of activity types (calls, emails, meetings, tasks) and distinguishes from siblings like list_client_activities (listing vs creating) and create_client_note (notes vs activities). However, it does not explicitly differentiate from all 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Use to track calls, emails, meetings, or tasks', which implies when to use. It gives an example but lacks explicit guidance on when not to use or alternatives. Among siblings, create_client_note is a related alternative, but not 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 destructiveHint=true and idempotentHint=true. The description adds 'cannot be undone,' reinforcing irreversibility. But no additional context about permissions, side effects, or error cases.
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?
English part is succinct and front-loaded. The Spanish translation duplicates content, adding length without new information, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and an output schema, the description fully covers what the agent needs: the action, the irreversibility warning, and the input requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id'. The description adds no extra meaning beyond the schema's description, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete') and resource ('deposit'), making the purpose unambiguous. However, it does not differentiate from sibling delete tools (e.g., delete_invoice, refund_deposit), missing an opportunity to guide selection.
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 refund_deposit or other delete tools. Lacks prerequisites, exclusions, or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive. Description adds status transition detail. No mention of permissions, reversibility, or side effects, but consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, includes essential information. Spanish translation adds length but not excessive. Could be slightly tighter.
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?
Covers action and status change. Lacks error scenarios, prerequisites, or return value explanation, but output schema exists.
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 has 100% coverage with bilingual descriptions. Description references id and reason in example but adds minimal meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Refund a deposit'), the target resource ('the client'), and the effect ('transitions status to refunded'). It distinguishes from sibling tools like delete_deposit or create_deposit.
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 vs alternatives like delete_deposit or create_deposit. The example gives context but not decision rules.
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 'Get' which is consistent, but provides no further behavioral details (e.g., authorization requirements, rate limits). With annotations covering the safety aspects, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences in two languages) and gets straight to the point. It could be slightly more efficient by dropping the Spanish duplicate, but it remains clear 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?
Given that an output schema exists (not shown but indicated true), the description does not need to explain return values. For a simple retrieval tool, the description covers the essential purpose. No mention of edge cases or prerequisites, but the tool's simplicity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a bilingual description for the single required parameter 'id'. The description merely restates 'by its ID', adding no extra meaning. Baseline 3 is correct when schema coverage is high.
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 'Get a single deposit by its ID', using a specific verb and resource. It distinguishes from sibling tools like list_deposits (which retrieves multiple) and create/update/delete_deposit.
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 (e.g., list_deposits for multiple deposits, get_invoice for invoices). Context is implied by the tool name, but explicit usage conditions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description adds value by specifying return fields (totals by tax rate, deductible IVA, net amount due, filing deadline) and providing an example period.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences in English and a Spanish translation, plus an example. It is front-loaded with essential information, though the Spanish repetition adds minor 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 tool is simple (one parameter, read-only, output schema exists), the description covers the main purpose, return fields, and example input. It does not mention whether the period parameter is optional (required: 0), but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'period' is fully described in the schema (format YYYY-QN or YYYY) and the description gives an example value ('2026-Q1'). Since schema coverage is 100%, the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get IVA (VAT) quarterly summary for Modelo 303 filing in Spain', providing a specific verb and resource. It distinguishes from sibling tools like get_modelo_130_summary by explicitly naming the form number and country.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives (e.g., other tax summary tools like get_modelo_130_summary). The context signals show many similar tools, but the description does not differentiate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false. Description adds no extra behavioral context (e.g., auth requirements, rate limits). The annotations sufficiently cover safety and idempotency, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, one in English and one in Spanish. Concise and front-loaded with the core action. Could be slightly tighter (e.g., drop Spanish if not needed), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a complete output schema and minimal required input, the description is sufficient for a simple get-by-id operation. It is complete enough given the tool's low complexity and existing metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (id). Description says 'by its ID' which merely repeats the schema description. No additional meaning or constraints are added beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get a single product/service by its ID', specifying a specific verb (Get) and resource (product/service). It distinguishes from siblings like list_products (which lists all) and create_product (which creates).
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 provided on when to use this tool vs alternatives (e.g., list_products for multiple products). The description does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the fields returned, but does not disclose additional behavioral traits such as authorization requirements, rate limits, or response size. Given strong annotations, this is adequate but not exceptional.
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, front-loads the primary action, and lists return fields. The bilingual text (English/Spanish) adds some redundancy but is justified for a multilingual audience. It is efficient overall.
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 read tool with annotations and output schema present, the description adequately conveys the purpose and returned data. It could mention that the output schema details the full structure, but that is already implied. The description is complete enough given the contextual signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'id' parameter. The description only restates 'by ID', adding no new semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details of a recurring invoice template by ID, and enumerates the returned fields (name, frequency, next run date, etc.), distinguishing it from sibling tools like list, create, update, delete, pause, resume, and run.
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 explicit guidance on when to use this tool vs alternatives like list_recurring_invoices. It does not state prerequisites, exclusion criteria, or scenarios where this tool is preferred. The implicit context ('by ID') is insufficient.
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?
Discloses key behaviors: an invitation email is sent, the member must accept before gaining access, and lists available roles. Annotations confirm a write operation with no destructive or idempotent traits, and the description adds context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise but includes bilingual text that duplicates information. The key details are front-loaded, but the repetition reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the invitation flow, role options, and example. Assumes output schema explains return values. Missing prerequisites (e.g., required permissions) and fails to mention that the invitee must not already be a member, but overall adequate for a simple invite action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by providing an example and expanding role meanings (e.g., 'admin (manage account, no billing)'), which helps the agent understand parameter usage.
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?
Clearly states 'invite a new member to the workspace by email address', using a specific verb and resource. Distinguishes from sibling tools like list_team_members and remove_team_member, though fails to explicitly note that inviting an existing member is not allowed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that an invitation email is sent and acceptance is required, but does not specify when to use this tool over alternatives (e.g., update_team_member_role for role changes) or include prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds the optional pagination detail but doesn't disclose any other behavioral traits (e.g., sorting, rate limits). This is adequate given the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two languages but still efficient) and front-loaded with the English version. It could be more succinct but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, all parameters are documented in schema, and there is an output schema. The description covers the core function. It could mention ordering or that it returns all notes for a client, but it's complete enough for a listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters described). The description only mentions 'optional pagination' which aligns with limit/offset but adds no deeper semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists notes for a client with optional pagination. It uses a specific verb ('list') and resource ('notes'), and distinguishes itself from sibling tools like create_client_note or list_client_activities.
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 vs alternatives, no exclusions, and no context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds 'PATCH semantics' and 'Only the provided fields will be changed', which is consistent but does not significantly expand on behavioral aspects like permissions, side effects, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences in English and a Spanish translation. It is front-loaded with the key purpose and behavior. Could be slightly shorter without the redundant Spanish text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with an output schema present, the description covers the essential update behavior and provides an example. It does not explain return values, but the output schema likely covers that. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description only adds an example ('id='abc123', amount=750, notes='Updated retainer amount') but does not provide additional semantics beyond what the schema already describes.
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 'Update' and the resource 'deposit', and specifies 'PATCH semantics' and 'Only the provided fields will be changed', which distinguishes it from other tools like delete_deposit or refund_deposit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example but does not explicitly state when to use this tool versus alternatives (e.g., create_deposit, delete_deposit). The guidance is minimal, only indicating that only provided fields are changed.
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 states permanence and irreversibility ('cannot be undone'), which adds context beyond the annotation destructiveHint=true. It reinforces the destructive nature, though the annotation already covers this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences (one per language), no wasted words. It front-loads the core action and key warning.
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 operation with two parameters, annotations, and output schema, the description is adequate. It covers the destructive nature and permanence, though could mention if this is a soft or hard delete, and any cascading effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with bilingual descriptions for both parameters. The tool description adds no extra semantic information about parameters, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('permanently delete a contact') and the resource ('from a client'), with bilingual text. It distinguishes itself from sibling delete tools by specifying the resource as client contact, but does not explicitly differentiate from similar tools like delete_client_note.
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 when to use soft-delete or update instead. No prerequisites or conditions 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?
The description discloses that the tool returns DNS records (CNAME) that must be configured before verification, which adds useful behavioral context beyond the annotations. However, it does not mention idempotency, error handling, or whether the tool can overwrite existing domains. Annotations are all false, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences in English plus Spanish bilingual repetition. It is front-loaded with the key purpose. The bilingual content is slightly redundant but does not detract significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but could benefit from mentioning next steps after adding (e.g., use frihet_portal_domain_verify to complete configuration). The output schema exists, so return values are covered. The description is adequate but not fully complete regarding the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters adequately. The description adds an example for the 'domain' parameter but does not mention 'workspaceId' or provide additional semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add), the resource (custom domain to Frihet client portal), and the purpose (white-label branding). It also distinguishes from sibling tools like frihet_portal_domain_verify and frihet_portal_domain_remove by noting that DNS records must be configured before verification.
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 adding a custom domain, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., frihet_portal_domain_verify, frihet_portal_domain_remove). It also does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds only that it lists sales with filters, which is obvious from the tool name, and does not provide additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (plus Spanish translation) that is concise, front-loaded, and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a complete output schema, full annotation coverage, and 100% schema description coverage, the description is adequate. It mentions the filter types but does not explain pagination behavior, which is partially covered in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions filters by date range, terminal, or status, which adds some context beyond the parameter descriptions in the schema, but not significantly more.
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 'List' and the resource 'POS sales', and mentions optional filters by date range, terminal, or status, which distinguishes it from related tools like get_sale.
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 sales with filters but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds no behavioral information beyond what annotations provide. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is duplicated in English and Spanish, making it twice as long as necessary. While it is front-loaded with English, the bilingual content is inefficient and reduces 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 adequately covers the tool's purpose and common filters. Given that an output schema exists and schema coverage is 100%, the description does not need to explain return values. However, it lacks details about pagination behavior (cursor vs offset) and ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters have descriptions in the schema. The description mentions filter types but does not add semantic meaning beyond what the schema already provides. It is appropriate to give a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List bank transactions with optional filters.' It specifies the resource (bank transactions) and the action (list), and mentions the available filter dimensions. It distinguishes from sibling tools like categorize_transaction or match_transaction_to_invoice which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by listing use cases: 'useful for reconciliation, expense matching, and cash flow analysis.' However, it does not explicitly state when not to use this tool or contrast it with alternatives such as search_invoices or list_expenses, which could also be used for financial analysis.
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 a write operation (readOnlyHint=false). The description adds value by noting that the first invoice is generated on the next scheduled run date. However, it does not disclose other behaviors like overwrite rules, permission requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a concrete example. Bilingual text adds length but maintains clarity. No unnecessary words, though the example could be more compact. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. The description covers the main purpose, parameters, and a key behavioral note. For a creation tool with 7 parameters, it is sufficiently complete, though it could mention uniqueness constraints on templateName.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description provides an example with values and bilingual explanations, but this adds minimal meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new recurring invoice template, with specific verbs ('Create') and resource ('recurring invoice template'). It distinguishes from sibling tools like create_invoice (one-off) and update_recurring_invoice (modification).
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 setting up recurring billing templates and lists required parameters, but lacks explicit when-to-use or when-not-to-use guidance versus alternatives. No exclusions or prerequisites 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, idempotentHint, and non-destructive. Description adds 'Poll' which aligns but no extra details on rate limits, authentication, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise English paragraph with useful status code list. Spanish translation is somewhat redundant but acceptable. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations are present, description covers purpose, return values, and common status codes for interpretation. Adequate for a polling 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?
Single parameter invoiceId has 100% schema coverage with description matching. Description does not add further semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state 'Poll the status of a FACe invoice submission' with specific verb and resource. Distinguishes from sibling tools like face_submit and other status 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?
Description implies polling but lacks explicit when-to-use vs alternatives. While the FACe context is clear, no guidance on when not to use or comparisons to get_einvoice_status or ticketbai_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the three modes and the requirement for DIR3 codes. Annotations are minimal (no readOnly, destructive, idempotent hints contradicted), so the description carries the burden but does not fully disclose potential side effects or idempotency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with English, and includes a Spanish translation. Each sentence adds value, though the bilingual format slightly increases length. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's specific domain, the description covers prerequisites (DIR3), modes, return value, and references the sibling tool for subsequent status polling. It is sufficiently comprehensive for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions in the schema. The description provides additional context for the 'mode' parameter (e.g., default is production, mock is safe) but largely repeats schema information. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it submits a Facturae invoice to the Spanish FACe B2G portal, with specific prerequisites (DIR3 codes) and return value. It distinguishes itself from the sibling face_status by noting the returned reference can be used with that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three modes (mock, sandbox, production) with guidance on when each is appropriate, including that mock is safe for dev/test. However, it does not explicitly state when to use this tool versus alternatives (e.g., face_status for polling) or provide 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, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that it returns per-party totals, but does not clarify the default behavior if the optional 'period' parameter is omitted, leaving ambiguity.
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 and front-loaded with key details, but it repeats the same information in Spanish, increasing length unnecessarily. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only summary with one optional parameter and an output schema, the description covers purpose, threshold, return content, and an example. Missing default behavior for 'period' is a minor gap, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'period' parameter already described as a year in YYYY format. The description repeats the example but adds no additional meaning or constraints 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 an annual summary of operations exceeding €3,005 per counterparty (Modelo 347, Spain), specifying it returns per-party totals for clients and vendors. The title reinforces the threshold and annual nature, distinguishing it from other Modelo summaries.
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 Spanish annual operations reporting but does not explicitly compare to sibling Modelo summaries (e.g., 303, 130) or provide when-not-to-use guidance. No exclusions or alternatives 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no behavioral traits beyond these, missing opportunities to mention output format or that it returns a single object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences (English and Spanish) with zero unnecessary words. 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 get-by-id tool with full annotations and output schema, the description is complete. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description. The description only restates 'by its ID', adding no new 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 action (Get), the resource (webhook configuration), and the method (by its ID). It effectively distinguishes from the sibling tool list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like list_webhooks. Usage is implied (when you know the ID), but no context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation idempotentHint is reinforced by explicit statement 'Idempotent: re-approving an already approved leave is a no-op.' Additionally, it discloses logging behavior (timestamp, approver) not covered by annotations. Adds valuable context beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes redundant bilingual text, doubling the length without adding unique information. It front-loads the purpose, which is good, but the redundancy reduces 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 presence of an output schema and annotations, the description covers idempotency and logging. However, it does not mention conditions (e.g., cannot approve if already rejected) or return values. Adequate but leaves room for more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline score is 3. The description does not add any parameter-specific meaning beyond the schema's brief descriptions. It mentions logging but does not connect to 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 explicitly states 'Approve a pending leave request' using a clear verb+resource structure. It distinguishes from siblings like leave_reject and leave_cancel, making its purpose unmistakable.
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 via 'TRUST AREA — HR DECISION' but does not explicitly specify when to use or alternatives. The idempotency note is a behavioral hint, not a usage guideline. Lacks direct mention of when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutating operation (readOnlyHint: false) but not destructive. The description adds that status starts as 'pending' awaiting approval. However, it does not disclose other side effects like notifications or required permissions. Given minimal annotations, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences in English and Spanish, conveying essential info efficiently. The bilingual content is somewhat redundant but does not harm clarity. It 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward creation tool, the description covers purpose, types, date format, and initial status. It does not explain return values (though output schema exists), error handling, or prerequisites, but remains adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description reiterates the date format and lists types, but adds little beyond what the schema provides. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new leave/PTO request for an employee.' It mentions specific leave types, date format, and initial status, clearly distinguishing it from sibling tools like leave_approve, leave_cancel, leave_list, and leave_reject.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on leave types and date formatting, but fails to specify when to use this tool versus alternatives (e.g., when to create vs. list or approve requests). It does not offer explicit usage or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds minimal extra behavioral context (optional pagination, product reusability). Annotations carry the transparency burden.
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 per language, front-loaded with English. Efficient but bilingual repetition slightly reduces conciseness. 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?
Output schema exists to document return values. Description covers purpose and core behavior. Missing details like default ordering or full response structure, but adequate for a list tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description mentions 'optional pagination' but does not add specific parameter details beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all products/services with optional pagination, and defines products as reusable items for invoices/quotes. This distinguishes it from sibling tools like get_product (single) and create_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like search_invoices or get_product. The purpose is clear but lacks when-not or alternative recommendations.
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=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the exact return fields and invite status categories (pending/active), but does not discuss pagination, rate limits, or error handling beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is split into English and Spanish, doubling length unnecessarily. While the English part is efficient, the duplication reduces conciseness. No structural aids like bullet points are used.
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?
Output schema exists, and description covers basic return fields and utility. However, it lacks explanation of filtering behavior (role/status) and pagination (limit/offset defaults or ordering). For a simple list tool, 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?
Schema description coverage is 100% with clear descriptions for all 4 parameters (role, status, limit, offset) including enums and constraints. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all workspace members and specifies the return fields (ID, name, email, role, invite status). It distinguishes from sibling tools like invite_team_member, remove_team_member, and update_team_member_role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'useful for access management and auditing,' providing some context but lacks explicit guidance on when to use this tool vs alternatives or exclusions. No when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that only provided fields change (PATCH semantics) and gives an example, consistent with idempotentHint annotation. However, it does not disclose potential side effects like triggers upon status change or validation constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two clear sentences in English (plus a Spanish translation that doesn't harm). The example is front-loaded, making the purpose immediately clear.
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 high parameter count and presence of an output schema, the description is somewhat complete but lacks details on behavioral nuances like updating nested objects or side effects. The relationship to sibling tools is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description only adds an example for id and status, providing marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'existing quote' with 'PATCH semantics', and provides an example. It distinguishes from sibling tools like create_quote and delete_quote by specifying the update method and behavior.
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 modifying existing quotes but does not explicitly state when to use this tool versus others or provide exclusions. The example gives a common use case but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's not read-only and idempotent. The description adds context about manual classification and tax mapping, but does not disclose overwrite behavior or potential side effects. With annotations bearing part of the burden, this is adequate but not thorough.
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 plus an example in two languages. It front-loads the purpose and includes relevant details without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters and presence of an output schema, the description covers the essential intent and usage. It lacks some details like category validation, but the schema examples compensate. It is complete enough for an 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 100% with parameter descriptions. The description provides an example that clarifies usage but does not add new meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'apply a category' and the resource 'bank transaction' and the purpose of manual classification for tax deduction tracking. An example is provided, making it unambiguous. It is easily distinguishable from siblings like 'match_transaction_to_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 implies use for manual classification but does not explicitly state when to use this tool versus alternatives like automatic categorization or matching. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about the auto-categorization logic and return fields but does not significantly extend behavioral disclosure beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences per language (English and Spanish), front-loading the main action. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (listing rules with optional filters), annotations, and output schema (not shown but present), the description covers the main functionality and return values. It could mention pagination behavior, but the schema parameters handle that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists bank auto-categorization rules and explains what these rules do (auto-categorize transactions). It distinguishes from siblings like frihet_bank_rule_create (create rules) and categorize_transaction (manual categorize) by focusing on listing existing rules. The return fields are also mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing rules but does not explicitly state when to use this tool versus alternatives (e.g., frihet_bank_rule_create for creating rules, categorize_transaction for manual categorization). No when-not guidance is 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 already indicate read-only, non-destructive, idempotent behavior. The description adds that results are sorted newest first and provides an example, which is useful but doesn't conflict 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?
Extremely concise: two sentences with core functionality, an example, and bilingual information. No redundant content, key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers major features (pagination, date range, sorting). Output schema exists, so return values are documented. Missing mention of category/vendor filters, but they are in schema. Adequate for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage). The description adds an example showing common parameter usage, but no additional semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists expenses with optional pagination and date range filters, and returns results sorted by date. It is specific to expenses and distinguishes from sibling list tools like 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 on when to use this tool versus alternatives (e.g., search for expenses, other expense actions). Users must infer from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds output fields but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in English and Spanish, front-loading purpose and listing return fields without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the description mentions returned fields, it is largely complete. Slight room for noting pagination implicit in limit/offset but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter information; all parameter semantics are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all recurring invoice templates' with a specific verb and resource, and lists the returned fields. It distinguishes from siblings like list_invoices by focusing on recurring templates.
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. The name and description imply usage for listing recurring invoice templates, but lacks exclusions or comparisons to alternatives like get_recurring_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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate those. The description adds the return fields (guest, dates, channel, total) but does not disclose pagination behavior, defaults, or other side effects. It provides adequate but minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in English and Spanish. It is front-loaded with the main purpose and uses no filler. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 8 parameters, the description covers the most common use cases and return fields. It lacks explicit mention of pagination or field selection, but the schema fills those gaps. Slightly above adequate for a list tool with comprehensive structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description groups filters (property, status, date range) which adds some semantic grouping, but does not explain pagination parameters (after, limit, offset) or fields. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all reservations'), the resource ('for the workspace'), and the scope with optional filters. It also mentions the returned fields (guest, dates, channel, total). This sets it apart from sibling tools like get_reservation or list_properties.
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 explains what the tool does and lists optional filters, but it does not explicitly indicate when to use this tool versus alternatives like get_reservation for a single reservation. Usage is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, fully covering safety and idempotency. The description adds filter context but does not reveal additional behavioral traits (e.g., pagination behavior, sorting defaults). With strong annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual (English and Spanish), which doubles its length but is a common pattern for multilingual tools. It is front-loaded with the English purpose and use cases, then repeats in Spanish. While not excessively long, it could be more concise by omitting the Spanish if a single language suffices for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (as indicated by context), the description does not need to explain return values. It covers purpose, filters, and use cases adequately. For a simple list tool with strong annotations, it provides sufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the input schema (100% coverage), so the tool description does not need to add parameter-level details. The description merely mentions filter categories, which aligns with the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'time tracking entries', specifies optional filters (user, project, date range, billable status), and lists use cases (timesheets, billing, cost analysis). This differentiates it from sibling tools like get_time_entry and get_time_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (generating timesheets, billing reports, project cost analysis) but does not explicitly state when not to use it or mention alternative tools. However, the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it supports filtering and search across content, and gives an example. No contradictions. The description provides useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose. The example is helpful. The bilingual text adds length but is not excessive. Could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and detailed annotations, the description covers the main capabilities and provides an example. It does not explicitly mention pagination, but the schema handles that. Overall adequate for a search 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 coverage is 100%, but the description adds meaning for the 'query' parameter (searches across client names and invoice content) and provides a concrete example. Other parameters are adequately described in 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 clearly states it searches and filters invoices, with specific capabilities like status and date range filtering, and the query parameter searches across client names and content. However, it doesn't explicitly differentiate from sibling 'list_invoices', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example but does not specify when to use this tool vs alternatives like 'list_invoices' or 'get_invoice'. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context: the deposit status transitions to 'applied'. Annotations provide idempotentHint=true, which is consistent but not elaborated. The description does not contradict annotations and adds meaningful state-change info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with an example and bilingual text. It is clear and front-loaded, though the Spanish translation adds redundancy for an English-focused agent. Still, it is efficient and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and mentions the optional invoiceId for applying to an invoice. Given the output schema exists and parameters are simple, the description is reasonably complete, though it could mention prerequisites or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented structurally. The description adds an example but does not provide additional semantic meaning beyond what the schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a deposit to an invoice or marks it as used, and transitions status to 'applied'. It distinguishes from sibling tools like refund_deposit or update_deposit by specifying the action on invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example but no explicit guidance on when to use this tool versus alternatives like refund_deposit or update_deposit. Usage is implied but not clarified with when-not or alternative conditions.
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 idempotentHint=true and destructiveHint=false. The description adds specific behavioral details: stamps clockOutAt and computes durationMinutes. It explicitly states idempotency, reinforcing the annotation. No contradictions. The description adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English part is concise (two sentences) and front-loaded. The Spanish translation adds length but serves a bilingual user base, which is acceptable. No filler 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 simple tool (1 param, good annotations, output schema exists), the description covers key aspects: action, idempotency, and computed result. A minor gap is the lack of prerequisites (e.g., entry must be open). Output schema likely handles return info, so no need to describe it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description effectively repeats the schema's description for entryId ('Open attendance entry ID'). It adds no new information about the parameter's format or constraints. With high coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close an open attendance entry'), the resource ('attendance entry'), and specifics ('Stamps clockOutAt and computes durationMinutes'). It also notes idempotency. While it doesn't explicitly differentiate from sibling 'attendance_clock_in', the verb 'clock out' and the name make 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 implies usage (closing an open entry) but provides no explicit when-to-use or when-not-to-use guidance. There's no mention of prerequisites (e.g., must have an open entry) or contrast with alternatives like 'attendance_clock_in'. The idempotency note is helpful but insufficient for full usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write nature is clear. The description adds no further behavioral details such as idempotency, limits, or side effects beyond the basic verb and purpose.
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 reasonably concise at three sentences including a bilingual translation and an example. The structure is clear, though the bilingual part adds some redundancy for English readers.
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, 100% schema coverage, and existence of an output schema, the description is complete enough. It covers the essential purpose, parameters, and usage context without requiring extensive elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by providing a concrete example with parameter values, illustrating typical usage and expected data format.
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 'Add' and resource 'a note to a client', and distinguishes notes as free-form text entries from sibling tools like log_client_activity, which might be more structured.
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 via an example but does not explicitly state when to use this tool versus alternatives like log_client_activity or list_client_notes. No when-not-to-use or exclusion criteria 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?
Description adds 'cannot be undone' beyond destructiveHint annotation. However, it is bilingual and somewhat repetitive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences in English followed by Spanish translation. No unnecessary detail, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, description and schema are sufficient. Output schema exists but not shown; description doesn't need to elaborate return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. Description does not add further meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Permanently delete a note from a client' with specific verb and resource. Distinguishes from sibling tools like list_client_notes and create_client_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives or prerequisites. Implied usage is clear but lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds emphasis on the permanent nature ('cannot be undone'), which reinforces the destructive behavior. It does not contradict annotations and provides additional context beyond what annotations offer.
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 (plus Spanish translation) that front-load the action and parameter. No wasted words; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 parameter, clear annotations, output schema exists), the description is complete. It explains the action, the necessary parameter, and the irreversible consequence. No additional information is 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?
Schema description coverage is 100%, so the schema already documents the 'id' parameter. The description does not add any additional meaning beyond what is in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Permanently delete a product by its ID.' It specifies the resource (product) and the operation (delete), distinguishing it from sibling tools like update_product or get_product. The information is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool vs alternatives. It lacks context about prerequisites, conditions, or exclusions. The warning about irreversibility is helpful but does not constitute usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that deletion is permanent and cannot be undone, providing additional context beyond annotations. No contradictions noted. No mention of authentication or rate limits, but for a simple delete this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the key action. The Spanish repetition is somewhat redundant but serves a multilingual audience. Every sentence is meaningful, though could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signal true), the description does not need to explain return values. It covers the destructive nature and irreversibility. It could mention prerequisites or error scenarios, but for a delete operation the information is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter 'id' is described as 'Quote ID / ID del presupuesto'. The description adds no further meaning or examples beyond what the schema already provides, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete') and resource ('quote'), specifying it is permanent and by ID. It distinguishes from sibling tools like 'update_quote' or 'get_quote'. The bilingual text does not hinder clarity.
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 does not explicitly state when to use this tool versus alternatives. It implies usage when intending to delete a quote, but lacks guidance on when not to use it (e.g., if deletion is not allowed due to dependencies). No comparison with sibling tools is 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 already indicate destructiveHint=true, but the description adds specific context: 'cannot be undone' and 'may affect existing expenses referencing this vendor'. This provides behavioral transparency beyond annotations, though no details on authorization or return value are given (output schema exists).
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, front-loaded with the key action in English, and includes a warning. The bilingual repetition adds slight redundancy but does not detract significantly. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, an output schema, and annotations covering safety traits, the description adequately covers the tool's purpose and key behavioral warning. It mentions the main side effect (affecting expenses), which is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single required 'id' parameter. The description mentions 'by their ID' but does not add any additional semantics or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'vendor', and specifies the action is permanent. It distinguishes from sibling tools like 'list_vendors', 'get_vendor', 'create_vendor', and 'update_vendor' by focusing on deletion.
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 warns that the action cannot be undone and may affect existing expenses, providing implicit usage guidance. However, it does not explicitly state when to use this tool versus alternatives or when not to use it (e.g., if vendor has pending expenses).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and idempotent. Description adds that the portal reverts to default subdomain, providing useful behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded with key action and effect. Bilingual repetition is slightly redundant but acceptable for audience. Every sentence is purposeful.
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 1-parameter destructive tool with output schema and clear annotations, the description adequately covers the behavior and result. Example aids understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'domain' with 100% schema description coverage. Baseline is 3; the description includes an example ('domain='portal.miempresa.com''), which adds marginal value but does not significantly enhance 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?
Clearly states 'Remove a custom domain' and specifies the resource (Frihet client portal). Distinguishes from siblings like add and verify by its action and effect.
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, but the verb and context make usage clear. Sibling names imply alternatives, but there is no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's addition of 'Returns full contact details' adds some context but not critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, bilingual, and front-loaded with the core purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema present), the description is complete enough for an AI 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 100% for the single parameter 'id', and the description does not add extra meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single client by ID and returns full contact details, distinguishing it from sibling tools like list_clients or update_client.
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?
Usage is implied by the name and description, but there is no explicit guidance on when to use or not use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds context about the return content (items, statuses, station, table) but no additional behavioral traits. This is adequate but not exceptional.
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 efficiently convey the purpose and return content, including a Spanish translation. No wasted words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, output schema exists) and rich annotations, the description covers all necessary context: what the ticket includes, and the fact it's a single retrieval. The output schema handles detailed structure, so this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'id' parameter, which is clearly described. The overall description adds meaning about what the tool returns, but does not enhance the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a single kitchen ticket by ID and returns full details including items, statuses, station, and table reference. This distinguishes it from sibling tools like list_kitchen_tickets and update_kitchen_ticket.
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 does not provide explicit guidance on when to use this tool versus alternatives like list_kitchen_tickets. While the operation is straightforward, no when-not or alternative usage is 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, destructiveHint=false, and idempotentHint=true. The description adds that it defaults to the current month, which is useful but not extensive. No behavioral 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 concise and front-loaded with the primary purpose. It includes bilingual text (English and Spanish) which, while doubling length, is justified for a multilingual audience. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations provide safety traits, the description adequately covers the tool's inputs and outputs. It lists the summary contents and default behavior. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'month' has a description in the schema with format and default note. The description adds minimal extra meaning beyond the schema, just the mention of current month default. Schema coverage is 100%.
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 complete monthly financial summary with specific items (revenue, expenses, profit, etc.). The verb 'Get' and resource 'monthly summary' are specific, and the tool is distinct from siblings like get_modelo_303_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to answer questions about financial performance, cash flow, or monthly P&L.' This provides clear context. However, it does not mention when not to use it or list alternative tools for more granular queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns booking details, but does not disclose other behaviors like auth requirements or rate limits. Given annotations cover the safety profile, description adds minimal extra 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?
Two clear English sentences with a Spanish translation that is redundant. Concise and front-loaded, but the bilingual duplication slightly reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lists return fields, which is sufficient given the existence of an output schema. The tool is simple with one parameter and clear purpose, so the description is complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'id' parameter described as 'Reservation ID / ID de reserva.' Description mentions 'by ID' but adds no further semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action: 'Get a single reservation by ID.' It specifies verb and resource, and lists return fields. It distinguishes from siblings like list_reservations (list) and create_reservation (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage context: use when you have a reservation ID and need details. No explicit when-not or alternatives, but the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds that it returns contact details, which is beyond annotations but not rich behavioral context. No mention of auth, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences in English and Spanish, front-loaded with purpose and return info. No superfluous content.
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 get-by-ID tool with an output schema (present), the description adequately covers purpose, parameter, and return value hint. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter described. Description adds no additional meaning beyond the schema's description of 'Vendor ID'. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a single vendor/supplier by ID and returns full contact details. Verb 'Get' and resource 'vendor/supplier' are specific. Differentiates from sibling tools like list_vendors, create_vendor, etc.
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?
Does not explicitly state when to use this tool versus alternatives (e.g., list_vendors for multiple vendors). Usage is implied by the tool's simple nature, but no explicit guidance is 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 already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral details such as security masking of IBAN and the specific fields returned, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences in English followed by the same in Spanish. While efficient, the bilingual repetition may be unnecessary for an AI agent, but it remains clear 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?
Given the presence of a full output schema (implied) and complete annotation coverage, the description adequately rounds out the tool's behavior. It mentions returned fields and security, but does not cover potential edge cases like empty results or rate limits.
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 provides full coverage (100%) with descriptions for both 'limit' and 'offset'. The description does not add additional semantic meaning or usage guidance for these parameters beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists all connected bank accounts for the workspace, specifying the exact fields returned (alias, IBAN with masking, currency, balance, timestamp). This distinguishes it from the sibling tool 'get_bank_account', which likely retrieves a single account.
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 clearly indicates usage for listing all bank accounts, but does not mention when not to use it or provide alternatives like 'get_bank_account' for single account retrieval. No explicit guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive nature. Description adds minimal behavioral context beyond stating the email action. No additional traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear English sentences followed by Spanish translation. Could be more concise by dropping the duplicate translation, but not excessively long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main action and precondition. Output schema exists, so return values are covered. Could mention error cases like invoice not found, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description's mention of optional recipient override repeats the schema. Baseline 3 maintained.
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 ('Send'), resource ('invoice'), and method ('via email'). It distinguishes from siblings like get_invoice and update_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?
Provides precondition: 'The invoice must exist and should not already be cancelled.' Does not explicitly mention when not to use, but the precondition implies avoidance for cancelled invoices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) cover the key behavioral traits; the description reinforces PATCH semantics but adds no major new insights beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences and an example; the bilingual duplication slightly impacts conciseness but is acceptable.
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 high parameter count and full schema/ output schema, the description provides sufficient context for an update tool, though it could mention any field-specific constraints (e.g., status transitions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description adds an example and general PATCH behavior but does not elaborate on individual 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 'Update an existing invoice using PATCH semantics' and provides a concrete example, distinguishing it from create or delete invoice 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 explains partial update behavior ('Only the provided fields will be changed') and gives an example, but does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark idempotentHint=true and destructiveHint=false. The description adds PATCH behavior and an example but no further behavioral context (e.g., permissions, error states). Annotations cover the safety profile, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an example. The bilingual duplication slightly reduces efficiency, but the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 100% parameter coverage, the description adequately explains the tool's partial update behavior. It could mention error handling or prerequisites, but it is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds marginal value. The example illustrates usage of id, hours, description, but does not clarify parameter syntax beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing time entry using PATCH semantics' and provides a concrete example. This distinguishes it from sibling tools like create_time_entry, delete_time_entry, and list_time_entries.
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 PATCH semantics ('Only provided fields are changed'), which informs when to use this tool for partial updates. It does not explicitly exclude scenarios or name alternatives, but the context is clear for this resource.
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 idempotentHint=true. The description adds useful context: PATCH semantics, only provided fields change, and an example. This goes beyond annotations to clarify non-destructive, partial update behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes an example, but the bilingual text (English and Spanish) adds length. Still, every sentence serves a purpose and the example is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested object, output schema present), the description covers the core operation. It does not detail return values or error cases, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions. The description adds an example and clarifies that only submitted fields are updated, which enhances understanding of how parameters behave together.
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 'Update an existing vendor using PATCH semantics' with a specific verb and resource. It distinguishes from sibling tools like create_vendor or delete_vendor by emphasizing that only provided fields change.
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_vendor (to read first) or create_vendor (if vendor doesn't exist). The description does not state prerequisites or scenarios where this tool 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 declare no readOnly or destructive hints, and the description confirms it's a create operation. However, it does not disclose side effects like confirmation emails or immediate channel sync implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in English and one in Spanish, front-loaded with purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, nested objects, and output schema, the description covers the essentials but could mention what the tool returns (e.g., reservation ID) or date validation 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?
Schema coverage is 100%, so baseline 3. The description adds minimal info beyond schema, only listing required fields and optional guest data, without further detail.
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 'Create', the resource 'reservation', and the context 'manually (not via channel sync)', distinguishing it from sibling tool sync_channel.
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 notes when to use (manual creation) and contrasts with channel sync, but does not mention when not to use or other alternatives like importing from channels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds context by listing events and mentioning a signing secret, but does not disclose potential side effects (e.g., URL validation, test notification sent), rate limits, or authentication requirements. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes an example, but is repeated in both English and Spanish, doubling length without adding value. The structure is front-loaded with the main verb and resource, but the bilingual repetition is not efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description does not need to explain return values. It covers the main functionality, required parameters, and available events. It lacks mention of permissions or URL accessibility requirements, but overall is sufficiently complete for a webhook creation 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 coverage is 100%, so baseline is 3. The description adds value by listing all available events and showing an example with url, events, and secret. It also implies the active parameter defaults to true (schema confirms). This goes beyond the schema's basic 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 'Register a new webhook endpoint' with specific verb ('register') and resource ('webhook endpoint'). It lists available events and provides an example, distinguishing it from sibling tools like get_webhook, update_webhook, delete_webhook, test_webhook, list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what to specify (URL, events, secret) and provides a list of available events. It gives an example usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., update_webhook), nor does it mention prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey safety (readOnlyHint, idempotentHint). The description adds important operational details: signed download URL valid 24 hours, CP1252 encoding, and honest backend availability response. These go beyond what annotations specify.
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 informative but verbose due to bilingual repetition (English and Spanish). Key information is front-loaded, but the dual-language text makes it longer than 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 presence of an output schema and complete parameter coverage, the description covers essential aspects: purpose, available formats, date constraints, encoding, and backend behavior. It does not need to document return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining each format's purpose in plain language, specifying ISO 8601 and inclusive date range, and noting output encoding – details not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export accounting data in DATEV EXTF format' with a specific verb and resource. It lists three distinct export formats, uniquely identifying this tool among siblings (no other DATEV-specific tool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. While the description mentions compatibility with DATEV Kanzlei-Rechnungswesen, it does not compare the tool to sibling export utilities like einvoice_export or face_submit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, not destructive. Description adds specific behavioral details: returns installment amounts, due dates, payment status, and cumulative total vs M200 projection. Also explains the three payments. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and includes an example. The repetition in Spanish is acceptable for a bilingual context but adds length. Overall concise 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?
Given the tool's simplicity, annotations covering safety, and a complete input schema, the description fully explains the tool's behavior and output. It mentions cumulative total vs M200 projection, which is additional useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds an example and explains the enum values (1P=April, etc.), but the parameter descriptions in the schema already cover what they do. The description doesn't add significant new 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?
Clearly states it gets a summary for Modelo 202 installment payments, specifies the three installments (1P, 2P, 3P) and what is returned (amounts, due dates, status, cumulative total vs M200 projection). Distinguishes from other modelo summaries by naming the specific form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an example and describes the tool's purpose, but does not explicitly state when to use this tool versus alternatives (e.g., other modelo summaries like 200, 180). No guidelines on prerequisites or limitations.
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, idempotentHint, and not destructiveHint. The description adds that it returns a counterparty list, operation totals, and filing deadline, which aligns with read-only behavior. However, it does not elaborate on other behaviors like data freshness or authentication requirements beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two brief sentences in English followed by a Spanish translation. It is front-loaded with the essential information, though the bilingual duplication adds minor length without extra content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (1 optional param), annotations, and presence of an output schema, the description adequately covers the tool's behavior: it specifies the return types (counterparty list, totals, deadline) and includes an example. No further context is needed for a read-only summarization 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?
The sole parameter 'year' is fully described in the schema (100% coverage) with an example and default behavior. The description reiterates the example 'year='2025'' but adds no additional semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an IGIC Modelo 415 summary, an annual declaration of operations with third parties over €3,005 in the Canary Islands, distinguishing it from similar models like Modelo 347 for peninsular Spain. The verb 'Get' and specified resource 'Modelo 415 Summary' provide 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly equates this to the Canary Islands equivalent of Modelo 347, guiding when to use this tool versus other fiscal declaration summaries. It also notes the €3,005 threshold, implying when it applies, but does not explicitly state when not to use it or list direct 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, destructiveHint, and idempotentHint, so the description does not need to repeat these. The description adds useful behavioral context by specifying the exact data returned (aggregated IGIC fields), which aligns with the read-only expectation and adds clarity beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two clear sentences in English followed by a Spanish translation. It is front-loaded with purpose and quickly lists outputs. The bilingual content adds length but is appropriate for the target audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present, comprehensive annotations), the description fully covers the necessary context. It specifies the returned fields, providing a complete understanding of what the tool produces without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the 'year' parameter. The description only adds an example value ('year='2025''), which is helpful but does not provide additional semantics or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving the annual IGIC Modelo 425 summary for Canary Islands businesses. It lists returned data (IGIC collected, deductible, net payable, filing status) and uses specific verbs ('Get', 'Returns'). The title and name differentiate from sibling summary tools (e.g., modelo_180, modelo_200).
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 title and context ('annual IGIC recap'), but it does not explicitly state when to use this tool versus other summary tools (e.g., quarterly models). No guidance on prerequisites or conditions for use 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 cover safety (readOnly, idempotent, non-destructive). Description adds that it returns URL or binary info, but no additional behavioral context (e.g., size limits, auth needs).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences (bilingual) with no unnecessary words. Front-loaded with the core action. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and existing output schema; description sufficiently conveys function and output. Minor lack of error handling mention but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'id' is documented in schema with description 'Invoice ID / ID de la factura'. Description does not add extra meaning beyond schema, so baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states that the tool retrieves the PDF for an invoice, specifying the output as a URL or binary info. Distinguishes from sibling 'get_invoice' which returns invoice data, not PDF.
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?
No explicit 'when to use' or alternatives, but the context of siblings (only tool to get PDF) and description implying PDF retrieval makes usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, nondestructive. Description adds specific return fields (net income, expenses, payments, amount due) and an example, enhancing understanding of behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus example; front-loaded with purpose. Bilingual content is justified for context. No filler, but example could be integrated more tightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool (1 param, no required) and existence of output schema, description sufficiently explains purpose, return values, and usage context. No gaps for agent to select and invoke.
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 already describes the single parameter with format and example. Description repeats the example but adds no new meaning beyond schema. Baseline 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states verb 'Get' and resource 'IRPF estimated payment summary for Modelo 130 filing' with target users and returned fields. Distinguishes from sibling tax form tools by naming specific tax and audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context (quarterly IRPF for Spanish freelancers) but lacks explicit when-to-use, when-not-to-use, or alternatives guidance. Implied differentiation from other tax models via name, but no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns full quote with line items and totals, which is beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in English, then Spanish repetition. Slightly redundant but front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with single parameter, output schema present, and description clearly states what is returned. Fully adequate for retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (id parameter described). Description adds no additional meaning or examples beyond the schema field description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Get'), specific resource ('quote/estimate by its ID'), and distinguishes from siblings like list_quotes or create_quote. Also specifies what is returned (full quote with line items and totals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives (e.g., list_quotes). It's implied but not stated. Lacks when-not or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds details on return content but no new behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, though it duplicates content in Spanish. The key information is front-loaded, but the bilingual redundancy slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description adequately explains what is returned (full sale details with key fields), covering all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'id' parameter already described as 'Sale ID / ID de venta'. The description's mention of 'by ID' adds no new 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 'Get a single POS sale by ID' and lists the returned fields (terminal, items, etc.), making it distinct from sibling tools like list_sales or refund_sale.
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 context (requires an ID) and specifies the scope (single sale), but does not explicitly mention when not to use it or suggest alternatives like list_sales for finding IDs.
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 and destructiveHint=false. Description adds details about returned fields (hours, costs) and filtering behavior, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two terse sentences in English followed by Spanish translation. No extraneous words; front-loads purpose and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and 100% parameter coverage, description covers core functionality. Missing explicit mention of grouping option, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context about 'date range' (from/to) and 'user ID for per-member breakdowns', but does not cover groupBy or projectId beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get', resource 'aggregated time tracking summary', and scope 'workspace or specific team member'. Distinguishes from sibling 'list_time_entries' which returns raw entries.
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?
Description implies usage for aggregated data with date filtering and optional user filter, but does not explicitly contrast with alternatives like 'list_time_entries' or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds little beyond stating 'List'. The description does not disclose pagination behavior (cursor-based via 'after' parameter) or other traits. With annotations present, the bar is lower, but the description provides minimal additional behavioral insight.
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 in English plus a bilingual note. It is front-loaded with the action, no redundant words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, optional filters, and an output schema, the description covers the essential purpose and filter options. It does not mention pagination explicitly, but the parameters cover that. For a read-only list tool with output schema, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters. The description mentions some filters but adds no new semantics beyond what's in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', resource 'leave/PTO requests', and scoping 'with optional filters'. It lists specific filter dimensions (employee, status, period), distinguishing it from sibling list tools. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases ('HR dashboards, calendar views, balance tracking') which implies when to use, but it does not explicitly state when not to use this tool or compare it to alternatives among siblings. However, the context is sufficiently clear for a listing tool.
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 context beyond annotations: 'TRUST AREA — HR DECISION' signals permission level, and labor-law compliance emphasizes regulatory implications. Annotations confirm idempotentHint=true, and description aligns by noting reason is mandatory for each rejection. 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?
Extremely concise: two sentences in English followed by Spanish translation. Front-loaded with trust area and purpose. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with 2 required params and output schema. Description covers purpose, mandatory nature of reason, and compliance context. Could briefly state that only pending requests can be rejected, but implied by 'pending leave request'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions. The description merely reiterates that reason is mandatory, adding minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Reject' and the specific resource 'pending leave request'. Distinguishes from siblings like leave_approve, leave_cancel, and leave_request_create by emphasizing rejection with mandatory reason.
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?
Indicates 'TRUST AREA — HR DECISION' suggesting HR role, but does not explicitly state when to use versus alternatives like leave_cancel or leave_approve. No exclusions or when-not scenarios 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?
Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds that pagination is optional and details what is returned (calls, emails, etc.). However, it omits potential constraints like date range or sorting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise English sentences with a Spanish translation. No fluff, front-loaded with the primary action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers purpose, resource, and pagination. Missing details like ordering or error scenarios, but overall sufficient for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description only adds context about optional pagination, which is already implied by limit and offset, so little extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'all CRM activities for a client', and specifies the types of activities returned (calls, emails, meetings, tasks). It distinguishes from siblings like log_client_activity (create) and list_client_notes (notes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the general use case (listing CRM activities) but lacks explicit guidance on when to use this tool versus alternatives, no when-not-to-use or context-specific instructions.
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 and destructiveHint=false. The description adds value by mentioning optional pagination and the fields returned, which is consistent and helpful but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences in English and Spanish, no wasted words, front-loaded with key information. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (expected to cover return format), the description sufficiently mentions returned fields. Missing ordering info, but overall adequate for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described. The description adds 'optional pagination' but does not provide new details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'contacts for a client', and specifies the returned fields. It distinguishes well from siblings like list_clients 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is clear (when you need contacts for a client), but no explicit guidance on when not to use this tool or alternatives. Siblings include delete_client_contact but no creation/update tool, so no direct alternative is 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=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the returned fields and filtering capabilities. It does not contradict annotations and provides useful behavioral context beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences in English and the same in Spanish. It is front-loaded with the core purpose, features, and return fields. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full annotation, the description covers the main aspects: purpose, search/filter support, and return fields. It does not mention pagination or ordering, but those are detailed in the schema. Slightly lacking in completeness but still solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description mentions free-text search and active/inactive filter, aligning with params 'q' and 'isActive', but adds no new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the kitchen menu catalog, with specific features like free-text search and active/inactive filtering, and explicitly lists return fields. It distinguishes from sibling list tools (e.g., list_products) by targeting the kitchen menu catalog.
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 does not explicitly state when to use this tool vs alternatives, nor does it provide when-not-to-use guidance. While the purpose is clear, the lack of comparative or contextual usage instructions limits its helpfulness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds the returned data fields (label, device type, location, connection status), which is useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences (English and Spanish), no wasted words. Front-loaded with key 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?
With output schema and annotations, description is adequate. Could mention pagination behavior but not necessary given schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. Description does not add additional meaning to parameters beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'list all configured POS terminals (Stripe Terminal readers) for the workspace' with specific fields returned. Clearly differentiates from sibling tools like 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives, but the tool's function is straightforward and implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds value by specifying that it returns contact info, tax IDs, and addresses, and mentions optional pagination and search, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with key information, and provides bilingual support (English/Spanish) without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 5 optional parameters, the description covers the main purpose and return fields. It could be more complete by mentioning that pagination uses cursor or offset, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds no new information about parameters beyond stating 'optional pagination and search'; it does not explain how to use parameters like 'after' vs 'offset' for pagination.
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 'List all vendors/suppliers with optional pagination and search' and specifies return fields (contact info, tax IDs, addresses). This distinguishes it from sibling tools like get_vendor (single vendor) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as get_vendor for a single vendor or search_invoices. The description only implies usage for listing with optional filters.
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?
Discloses that the generated invoice is a draft, requiring separate review and sending. Annotations already indicate non-read-only and non-destructive; description adds context on the draft nature and manual trigger. Missing effects on the template's schedule or idempotency, but adequate given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, front-loaded with the action. Bilingual text adds length but serves international users. Could be more concise, but structure is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Description covers main action and use case but omits parameter option (draftOnly=false) and possible side effects on the recurring template schedule. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds only an example for templateId but no extra meaning for draftOnly beyond what the schema already provides. No additional semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (manually trigger immediate generation) and resource (recurring template). Includes specific use cases (billing ahead, recovering missed runs) and an example. Distinguishes from sibling tools like create_invoice and send_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?
Explicitly states when to use (billing ahead, recovering missed runs). Implies when not to use by noting the invoice is a draft and must be sent separately, hinting that send_invoice is for sending. Does not fully exclude other scenarios or detail 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 are minimal (readOnlyHint=false, destructiveHint=false, etc.). The description adds behavioral context: it performs a write operation that reverts an invoice, and in the Spanish market it generates VeriFactu-compliant R1-R5 rectificativa. This goes beyond the annotations by specifying compliance details and the effect on the invoice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the first sentence front-loading the main action. It includes a bilingual paragraph for Spanish users, which is slightly redundant but serves a clear audience need. No wasted sentences, but length could be reduced for English-only contexts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and market differences, which is adequategiven the presence of an output schema and parameter descriptions. Missing are prerequisites (e.g., invoice must exist and not be fully credited) and error conditions, but these are not critical for initial selection. Overall complete enough for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already having bilingual descriptions in the input schema. The tool description itself does not add additional semantics for parameters. Per guidelines, when schema_coverage is high, baseline is 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a credit note (factura rectificativa) for an existing invoice, specifying it reverses all or part of an invoice for compliance. It distinguishes the tool from siblings like create_invoice and refund_sale by mentioning market-specific behavior (VeriFactu in Spain, standard negative amounts elsewhere), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use the tool: to generate a credit note for an existing invoice. It provides context about market-specific compliance requirements but does not explicitly state when not to use it or name alternatives. However, the context is sufficient for an agent to decide based on the invoice and market.
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 a non-read-only mutation. The description adds a requirement (minimum a name) and includes an example, which enriches behavioral transparency beyond the annotations. However, it does not detail further behavioral traits like idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient with two sentences plus an example. It is front-loaded with the core purpose. The bilingual repetition slightly reduces conciseness, but overall it is clear and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a modest parameter set (5) with 1 required, and an output schema exists. The description explains the purpose, required field, and usage context. It lacks detail on validation or error handling, but for a simple creation tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description goes beyond by providing a concrete example with parameter values (name, email, taxId, address), demonstrating the structure and acceptable data. This adds meaning that aids selection and invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new vendor/supplier' with a specific verb and resource. It distinguishes from sibling tools like list_vendors, get_vendor, etc., by explicitly stating the creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by mentioning that vendors are used when tracking expenses and purchase orders, giving a clear usage scenario. It does not explicitly list alternatives or when not to use, but the context is sufficient for a creation tool with no direct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds crucial context: 'permanently delete' and 'cannot be undone', which reinforces the irreversible nature. No contradiction with annotations; the description enriches behavioral understanding beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two English sentences and two Spanish equivalents. It is front-loaded with the key action. The bilingual repetition is slightly redundant but still efficient. No unnecessary fluff; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no nested objects, and an output schema exists), the description is adequate. It specifies the core action and its irreversibility. For a delete operation, this completes the context needed by an agent, though it could briefly mention the output format.
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 tool description does not add any parameter-specific information beyond what is already in the input schema. The schema covers 100% of parameters with a clear description for 'id'. Thus, the baseline score of 3 is appropriate, as the description adds no extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('permanently delete') and the resource ('expense by its ID'). The verb 'delete' and the noun 'expense' are specific, and the mention of 'ID' clarifies the input. This distinguishes it from sibling tools like 'update_expense' or 'list_expenses'.
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 when wanting to remove an expense permanently, but it does not explicitly state when to use this tool versus alternatives (e.g., 'update_expense' for modifications). No when-not-to-use guidance is provided. The inclusion of 'This action cannot be undone' hints at caution but is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but description adds 'permanently delete' and 'cannot be undone', reinforcing the irreversible nature. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in English and Spanish, front-loaded with the main action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-ID tool with output schema, the description covers essential aspects: action, permanence, and required ID. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description, but description adds no additional meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (permanently delete) and resource (invoice by ID), distinguishing it from sibling tools like get_invoice or update_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?
Only warns that action cannot be undone, but does not provide explicit guidance on when to use this tool vs alternatives (e.g., credit notes) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructive, idempotent), the description adds that deletion is permanent, does not affect previously generated invoices, and requires confirmation. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences in English and Spanish. It is front-loaded with key information and contains no redundancy, though the bilingual version slightly lengthens it.
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 destructive nature and the output schema, the description covers key aspects: permanence, scope (template only), and safety requirement. It is complete enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description reiterates the need for 'confirm=true' but does not add new information beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for permanently deleting a recurring invoice template, distinguishing it from deleting generated invoices. The verb 'delete' and resource 'recurring invoice template' are specific, and it differentiates from sibling tools like 'delete_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?
The description explains that it deletes only the template and future runs, not past invoices, and requires the 'confirm' parameter to prevent accidental deletion. It provides clear context for when to use the tool, though it does not explicitly mention alternatives like pause or resume.
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 context beyond annotations by stating 'Notifications will stop immediately', aligning with destructiveHint. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, clear sentences front-loading the action and effect. Bilingual redundancy is acceptable for scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple delete operation, one parameter, annotations present, and output schema exists, the description fully covers necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (id) which is fully described in the schema. The description adds no additional meaning beyond the schema's bilingual description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Permanently delete a webhook by its ID', specifying the verb and resource. Differentiates from sibling tools like get_webhook, create_webhook, update_webhook, and test_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when wanting to permanently remove a webhook, but does not explicitly specify when not to use or mention alternatives like update_webhook for temporary disabling.
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 details what is copied (line items, client, tax rate, notes) and what is stripped (original ID, document number, status, timestamps), plus the new invoice starts as 'draft'. Annotations (destructiveHint: false) align with non-destructive creation, and the description adds valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual, front-loaded with the core action, and each sentence adds value. It is appropriately sized, though the Spanish repetition slightly reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (duplicating with several field groups) and the presence of an output schema, the description covers the key aspects: what is copied, what is reset, and the resulting draft status. It is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema sufficiently documents parameters. The description adds limited extra meaning: it mentions the new invoice defaults to today's date and allows providing a due date, but does not elaborate on the id parameter beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it duplicates an existing invoice for a new period, copying line items and client data while stripping identifiers and resetting status. This distinguishes it from siblings like create_invoice (new from scratch) or update_invoice (modify existing).
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 explicitly suggests usage for recurring invoices ('Perfect for recurring invoices — duplicate last month's invoice and adjust if needed.'), providing clear context. However, it does not mention when not to use it or alternatives like create_invoice for new invoices.
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 (idempotentHint=true, destructiveHint=false) are not contradicted. The description adds important behavioral context: role requirement, trust area, and what the action does (updates status, records audit trail). No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but unnecessarily includes a full Spanish translation after the English part, creating redundancy. It could be more concise by using one language or a shorter format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, an output schema, and moderately rich annotations, the description fully covers purpose, effect, role requirements, and a usage warning. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds minimal extra meaning. It provides an example entry ID ('gl_2026_q1_042') but otherwise repeats schema info.
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 ('Approve a General Ledger journal entry'), the resource, and the effect ('Sets entry status to 'approved' and records the approver + timestamp'). It distinguishes from sibling tool 'frihet_gl_entry_reject'.
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 required role ('gestor/admin'), warns it's a 'TRUST AREA action', and advises to double-check entry ID. It provides context for when to use but does not explicitly list situations when not to use (beyond the trust area warning).
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=true and destructiveHint=false, so the tool is safe. The description adds behavioral details such as returning messages newest first, using 'before' for pagination, and providing a 'hasMore' flag, which complements the annotations with useful execution 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 English part is concise and front-loaded with the core purpose and key usage details. The Spanish repetition is somewhat redundant but does not detract significantly. The description efficiently conveys all necessary information in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description appropriately covers the key aspects: what is listed, ordering, pagination, and the hasMore flag. It does not cover error handling or exhaustive parameter explanations, but these are standard for list tools and not required for completeness here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the description adds little beyond the schema. It clarifies the usage of 'before' (message ID or ISO timestamp) and 'limit' (max 100, default 50), but these are also present in the schema descriptions. No additional semantic depth is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists messages in a gestor/cliente thread, with ordering (newest first) and pagination details. It explicitly distinguishes from siblings like 'gestoria_message_send' by specifying the thread context, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (listing messages in a thread) and how to paginate using 'before' and 'hasMore'. However, it does not explicitly state when not to use it or mention alternatives like 'gestoria_message_send', but the distinction is implicit due to the list vs. send nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds return field details but no further 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences (English and Spanish), front-loaded with purpose, and no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple retrieval tool with output schema, annotations, and single parameter. No gaps in explaining what the tool does and returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, and description does not add additional meaning beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets full details of a single time tracking entry by ID and lists the returned fields (project, user, hours, etc.). Distinguishes from sibling tools like list_time_entries.
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?
Implicitly suggests use for retrieving one entry, but does not explicitly mention alternatives or when not to use. Could be improved by referencing list_time_entries for multiple entries.
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 aligns with annotations (readOnly, idempotent, non-destructive) and adds value by specifying return content (contact info, tax IDs, addresses). 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 in English and Spanish, no wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks mention of field selection ('fields' parameter) and filtering ('stage'), which are important for agent to know. Output schema exists but description could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add significant insight beyond schema, e.g., omitting mention of 'fields' or 'stage' 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?
Description clearly states verb 'List', resource 'clients/customers', and scope 'all with optional pagination', distinguishing it from sibling tools like get_client.
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?
Mentions optional pagination and return fields, but lacks explicit guidance on when to use this vs. get_client for a single client or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds sorting order (newest first) and pagination methods (cursor/offset), going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with an example, front-loaded. Bilingual text adds length but is acceptable. No extraneous 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?
With output schema present, return values are covered. Description covers purpose, pagination, sorting, and filters. Adequate for an 8-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for all parameters. The description adds an example but no new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states "List all deposits" with verb and resource, specifies sorting order (newest first), and distinguishes from sibling tools like get_deposit or create_deposit.
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 example usage and mentions optional pagination/date filters, but does not explicitly compare to sibling tools. However, as the only list tool for deposits, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety is covered. Description adds no additional behavioral traits beyond what annotations provide, which is adequate but not enhanced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two effective sentences in English, front-loaded with purpose and usage. However, the entire description is duplicated in Spanish, which adds unnecessary length for English-speaking agents. Still, the structure is clean.
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, the description covers purpose, return fields, and alternative usage. Annotations cover safety, schema covers params, and output schema exists. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters (limit, offset) with 100% description coverage. The tool description does not add any additional meaning or context about parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all kitchen stations' and specifies returned fields (id, name, active status). Explicitly distinguishes from sibling tool kitchen_flow_summary by directing users there for ticket load and bottlenecks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool for listing stations, and when to use kitchen_flow_summary instead for per-station load/bottlenecks. Provides clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it affects fiscal reconciliation records and is idempotent (re-matching same document is a no-op). Annotations already provide idempotentHint=true, so this reinforces it. 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 front-loaded with key information and is reasonably concise. The bilingual content adds length but does not hinder clarity. Could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (100% schema coverage), annotations, and an output schema, the description adequately covers its purpose, requirement (confirm=true), and idempotency. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The description provides an example but does not add significant new semantic meaning beyond what the schema already conveys.
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 'Link a bank transaction to an invoice or expense document.' This is a specific verb+resource pairing that distinguishes it from sibling tools like categorize_transaction which serves a different 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 indicates this tool is for reconciliation ('TRUST AREA — RECONCILIATION') and explicitly requires 'confirm=true' to proceed. However, it does not explicitly state when not to use it or mention alternative tools, which would provide stronger guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description adds context about audit logging and backdated edits, reinforcing the behavioral implications. It doesn't contradict annotations and adds value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with front-loaded context ('TRUST AREA — FISCAL REOPEN') and clear sentences. Bilingual content adds some redundancy but is acceptable for the intended use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose, required parameters, and warns about consequences. An output schema exists, so return values are covered. It's mostly complete, though prerequisites like 'period must be closed' are implied not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's mention of reason for audit and confirm=true aligns with schema descriptions but doesn't add substantial new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reopen a closed accounting period' with a specific verb and resource. It also mentions 'allows backdated edits to invoices/expenses', distinguishing it from the sibling 'period_close' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires a compliance reason and 'confirm=true', and warns 'use with extreme caution'. It provides clear context for when to use, though it doesn't explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by detailing status values and their meanings, especially the polling recommendation for 'submitted' state, which goes beyond basic 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 front-loaded with purpose and status list. The bilingual Spanish section is redundant but not excessively long. It is generally efficient, though a single language would improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, 100% schema coverage, and existence of an output schema, the description covers the key behaviors (polling, status values). It doesn't need to explain return values as the output schema exists. Adequate for a polling status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (invoiceId) with schema description already explaining it's the Frihet invoice ID. The description adds that it's the same ID used in ticketbai_submit, providing helpful cross-reference. Baseline 3 is appropriate as schema coverage is 100%.
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 polls the hacienda acknowledgment status for a TicketBAI submission, returning the TBAI identifier, territory, and confirmation/rejection state. It uses specific verbs and resource, and distinguishes from related tools like ticketbai_submit.
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 after submission and provides polling intervals for the 'submitted' status. While it doesn't explicitly state when not to use, the context is clear. It could mention alternatives like get_einvoice_status but isn't required.
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 idempotentHint=true and destructiveHint=false. The description adds that PATCH semantics are used and only provided fields change, aligning with idempotency. No contradictions, and it adds context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information in two English sentences, followed by a Spanish repetition. While efficient, the bilingual aspect adds length; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested address object), output schema existence, and annotation coverage, the description is reasonably complete. It explains the update semantics and provides an example, though it does not detail nested parameter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description includes an example (id, email, phone) and bilingual notes about modifying only provided fields, adding practical guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'client,' specifying PATCH semantics and that only provided fields change. This distinguishes it from sibling tools like create_client or delete_client.
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 updating existing clients but does not explicitly state when to use versus alternatives like create_client or get_client. No when-not conditions or alternative tool names 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?
Given that annotations already indicate idempotentHint=true and non-destructive, the description adds value by specifying PATCH semantics and partial update behavior ('Only the provided fields will be changed'). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and an example, but includes redundant bilingual text. It is front-loaded with clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters (1 required) and an output schema, the description covers essential behavior (partial update) and usage. It does not detail error handling or validation, but given the output schema exists, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds an example of usage (id, amount, category) and clarifies that only provided fields are changed, adding 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 'Update an existing expense using PATCH semantics' and provides an example with id, amount, and category. It distinguishes from sibling tools like list_expenses, delete_expense, etc.
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 updating an expense but does not explicitly state when to use this tool vs alternatives (e.g., other update tools). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds specific return fields (timestamp, hash, response code, QR URL), 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 sentences in bilingual format, each earning its place. Front-loaded with key information, no fluff. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, annotations, output schema present), the description is complete enough to understand the tool's behavior without ambiguity.
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 invoiceId has full schema description coverage (100%). The tool description does not add additional semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 VeriFactu submission status for a specific invoice, listing returned fields. This distinguishes it from sibling tools like send_invoice, get_einvoice_status, ticketbai_status, and verifactu_resubmit.
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 checking status after submission but provides no explicit guidance on when to use this tool versus alternatives like get_einvoice_status or ticketbai_status. Context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's a write operation (readOnlyHint=false). Description adds that it returns an attendance entry with status 'open' and that mood and location are optional. This provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences (plus Spanish translation) that concisely capture the tool's purpose and key details. No extraneous 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?
For a simple clock-in tool, the description is complete enough. It covers the basic action, optional fields, and pairing. With annotations and output schema present, additional details are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description briefly mentions mood and location as optional but adds little beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Record an employee clock-in' with optional mood and location, and mentions that it returns an entry with status 'open'. It distinguishes itself from sibling attendance_clock_out by noting the pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Pair with attendance_clock_out to close the entry', providing clear context for when to use it. It doesn't explicitly state when not to use it, but the pairing instruction is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent, non-destructive mutation. The description adds no behavioral traits beyond stating it records a deposit. It does not mention side effects, auth needs, or idempotency behavior. With annotations covering the mutation type, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences in English (plus Spanish translation). It front-loades purpose and requirements, with no filler. Every sentence is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 10 parameters (100% schema coverage) and presence of an output schema, the description covers core purpose, required params, and example. It does not explain optional parameters, but the schema handles that. It is sufficiently complete for a creation 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 coverage is 100%, so baseline is 3. The description adds value by explicitly highlighting required parameters (clientId and amount) and providing an example with values. This helps clarify usage beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Record a new deposit from a client' with specific verb and resource. It provides use cases (advance payments, retainers, security deposits) and distinguishes from sibling tools that update, delete, refund, apply, list, or get deposits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires clientId and amount, gives an example, and lists use cases. However, it does not explicitly state when not to use it or provide direct comparisons with alternative tools like apply_deposit or refund_deposit. Still, the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying required fields (name and unit price) and giving an example. Annotations indicate non-destructive behavior, and the description aligns with that.
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 bilingual, which makes it slightly longer. While front-loaded with English, the Spanish repetition adds verbosity. Could be more concise by omitting the Spanish or reducing it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and the parameter schema with full coverage, the description explains the tool's purpose and usage context sufficiently, including integration with invoices and quotes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's mention of required fields and the example provides additional clarity, reinforcing parameter semantics without redundancy.
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 'Create a new product or service in the catalog' with a specific verb and resource. It distinguishes from sibling tools like 'list_products' and 'update_product' by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that products can be referenced when creating invoices and quotes for faster data entry, providing context for use. However, it does not explicitly state when not to use it or alternatives beyond those 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 lack clear hints (readOnlyHint: false, destructiveHint: false). The description adds that the default status is 'draft' and mentions future conversion to invoices, providing some behavioral context. However, it does not disclose other behaviors like permission requirements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and one example. It front-loads the core purpose and requirements, then adds a practical example. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, but schema covers them all) and the presence of an output schema, the description covers the essentials. It includes required fields and a future use case (conversion to invoice), but could mention that clientId can back-fill address/taxId.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 14 parameters have descriptions). The description adds an example showing clientName and items structure, which enhances understanding beyond the schema. However, it doesn't explain nuanced parameters like clientLocation or equivalenceSurchargeRate.
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 'Create a new quote/estimate for a client' and specifies required fields (client name, at least one line item), providing a clear verb-resource-action. It distinguishes from siblings like update_quote and create_invoice by mentioning future conversion to invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (initial quote creation) and notes quotes can be converted to invoices. It does not explicitly exclude alternatives (e.g., update_quote for modifications), but the purpose is well-understood.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description aligns with this by stating it 'logs' a time entry, but adds no further behavioral context beyond the example. Given annotations carry the burden, the description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences (plus bilingual repeat) that front-load the main purpose and key parameters. Every sentence adds value without redundancy or 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 tool has an output schema (not shown but indicated true) and 100% schema coverage, the description covers the essential aspects: action, required fields, optional billable, and an example. It is complete enough for an agent to use correctly, though it could mention default behavior for userId or billable more explicitly.
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 100% description coverage, explaining each parameter. The description adds value by providing a concrete example (projectId='proj_abc', hours=2.5, etc.), which helps clarify how to format the inputs, exceeding what the schema alone offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Log a time entry for a project.' It specifies the required fields (projectId, hours, date) and an optional one (billable). This distinguishes it from sibling tools like list_time_entries, get_time_entry, update_time_entry, delete_time_entry, and get_time_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with an example and highlights when to set billable=true. However, it does not explicitly state when not to use this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds specific return fields (collected, deductible, net due, carryover), complementing annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise English sentences followed by Spanish translation. Core purpose front-loaded. Bilingual redundancy acceptable; 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?
Complete for a single-optional-param read tool with full schema coverage, annotations, and output schema. All necessary information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter fully with 100% coverage. Description reinforces format with example period='2026-04', but adds no new semantic detail beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope: 'Get IGIC Modelo 418 summary' for large enterprises in Canary Islands. Distinguishes from other tax model tools like get_modelo_303_summary.
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?
States applicable condition: annual turnover exceeds 'grandes empresas' threshold. Provides example period. No explicit alternatives but context implies exclusive use for IGIC large enterprises.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds retry guidance and 48-hour propagation timing, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus an example, front-loaded. Bilingual text adds slight redundancy but remains concise.
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?
Complete for a simple verification tool: explains prerequisite, retry behavior, statuses, and propagation delay. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, description only adds an example domain. Baseline 3 is appropriate as the schema already documents 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?
Explicitly states 'Verify DNS propagation for a custom portal domain', specifies the resource and action, and distinguishes from sibling tool frihet_portal_domain_add by naming it as prerequisite.
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?
Clear context: use after domain_add, retry if status is pending. Provides an example. No explicit when-not-to-use, but the narrow purpose makes it obvious.
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, destructiveHint, and idempotentHint. The description adds specifics: paginated results, sorting by issue date, and filtering capabilities. It does not contradict annotations and provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example; front-loaded with key functionality. The bilingual text adds length but is still relatively concise. Could be slightly trimmed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, full schema coverage, and output schema, the description covers the main aspects: purpose, filtering, pagination, sorting, and an example. It is complete enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-defined. The description adds an example and clarifies that pagination is optional. It repeats some schema info but provides clear context beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists invoices with optional pagination and filters, and specifies the sort order (newest first). This distinguishes it from related tools like 'get_invoice' (single) and 'search_invoices' (likely more extensive).
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 explains what filters are available but does not explicitly state when to use this over siblings like 'search_invoices' or 'get_invoice'. Usage context is implied but no when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: 'The next invoice will be generated on the next scheduled cycle date after resumption.' Annotations provide idempotentHint=true, and description confirms non-destructive, non-readOnly behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences (English and Spanish) that front-load the key action and effect. 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 tool's simplicity (1 required param, high schema coverage, annotations present), the description adequately explains the effect. It could mention prerequisites (e.g., template must be paused) but is still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the single parameter 'id' 100% (with bilingual explanation). The description does not add new meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resume a paused recurring invoice template') and the resource ('recurring invoice template'), with a specific verb. It distinguishes from siblings like 'pause_recurring_invoice' and 'create_recurring_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?
The description implicitly tells when to use (when a template is paused), but does not explicitly mention when not to use or provide alternative tools. However, the context from the name and sibling tools makes it 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 indicate idempotentHint=true and destructiveHint=false. The description adds that it triggers a sync, with direction (pull/push/both) and returns sync status/counts. This goes beyond annotations by clarifying the effect on data (pulls reservations, pushes calendar). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences in English and then Spanish, no fluff. It is front-loaded with the key purpose and actions. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two params, output schema exists, and the description explains sync direction and return values (status/counts). No critical gaps; it covers purpose, parameters, and output well. Could mention that sync may take time or that it is an async operation, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: channelId and direction are described in the schema. The description mentions pulling and pushing, which aligns with the direction parameter but adds no new details beyond the schema. With full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers a manual sync of a booking channel, specifying it pulls new reservations and/or pushes calendar updates. This distinguishes it from sibling tools (no other sync tool exists), so it is a specific verb+resource pair.
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 communicates when to use: when you need to manually sync a channel (pull/push). There are no alternative sync tools among siblings, so explicit when-not or alternatives are not necessary, but it could briefly mention that automatic syncs exist or that this is for manual triggers.
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 and destructiveHint=false, so the description's role is reduced. It adds domain context (HR/operational/financial anomalies) and mentions filtering capabilities, which is useful beyond 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 two bilingual sentences with no wasted words. It front-loads the core purpose and immediately provides usage guidance and filtering options. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 6 parameters (0 required), output schema present, and clear annotations, the description adequately covers what the tool does, what anomalies it detects, and how to filter. No missing elements given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description groups parameters into type, severity, period, and gives example values for type (e.g., duplicate_clock_in). This adds context but does not provide syntax or formats beyond what the schema already describes.
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 'List HR / operational / financial anomalies detected by the system', specifying the verb (list) and resource (anomalies). It provides concrete anomaly type examples, distinguishing it from sibling tools which deal with other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for daily HR review and compliance audits', giving clear usage context. It also mentions filtering by type, severity, or period. While it does not explicitly exclude use cases, the context is sufficient for this unique tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation tool (readOnlyHint=false). The description adds significant behavioral context: auto-generated invoice number, default draft status, today's date, and support for advanced features like IRPF, equivalence surcharge, series, prepayment, and global discount. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with essential information, and includes a helpful example. The bilingual content (English and Spanish) adds redundancy but is not excessive. Every sentence contributes meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (19 parameters, 3 enums, output schema present), the description covers core behavior, prerequisites, defaults, and advanced features. It does not need to explain return values due to the output schema. The context is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing an example that demonstrates how to use common parameters (clientName, items, taxRate, irpfRate) and highlights advanced features (IRPF, surcharge, series, prepayment, discount) that correspond to schema properties.
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 'Create a new invoice' and specifies required parameters (client name, at least one line item). It distinctively identifies the creation action compared to sibling tools like get_invoice, update_invoice, and delete_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?
The description explicitly states prerequisites (client name, at least one line item) and defaults (auto-generated number, draft status, today's date). It provides an example but does not explicitly state when not to use or mention alternatives, though none are directly relevant.
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?
Exceeds annotations by detailing the soft-delete behavior, requirement for confirmation, and consequences (excluded from billing reports but retained for audit). 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is functional but includes bilingual repetition, making it longer than necessary. While not overly verbose, the Spanish translation adds redundancy without substantial value for AI agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and output schema, the description fully covers the operation's effect, requirements, and consequences. No missing context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by emphasizing 'confirm=true' requirement, but that is already present in the schema. No additional parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('soft-delete') and resource ('a time entry by ID'), distinguishing it from other delete operations by specifying it's a soft-delete. The bilingual text reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires 'confirm=true' to prevent accidental deletion, providing a key usage requirement. It implies when to use (for soft-deletion with audit retention) but does not explicitly state when not to use or compare with alternatives like update_time_entry.
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 and idempotentHint=true. Description adds valuable context about the content of the audit trail (state transitions, actors, timestamps) and provides an example, going beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a relevant example. No superfluous content. Spanish translation adds little value but does not harm. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description is complete. Annotations cover safety, output schema exists, and the description adequately describes the return value (audit trail).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (entryId) with full schema coverage (100%). The description does not add meaning beyond the schema's description; the example is helpful but not essential. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Retrieve') and resource ('full audit trail for a General Ledger entry'). Specifies exact data returned (state transitions, actors, timestamps) and provides an example. Distinct from sibling tools like frihet_gl_entry_approve.
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 directs use for 'investigate approval history or compliance audits.' No exclusions or alternatives are needed given the tool's uniqueness; 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's safe. The description adds value by detailing the returned data fields and providing a usage example (year='2025') and deadline, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences in English and two in Spanish, front-loaded with purpose and key details. Every sentence adds value (purpose, returned fields, deadline, example). 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?
The description is complete for a simple read tool with one parameter and an output schema (present but not shown). It covers purpose, target users, deadline, example, and parameter meaning. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the 'year' parameter. The tool description adds an example ('year="2025"') which is helpful but not essential. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get Modelo 200 summary' for annual corporate income tax return, lists returned fields (taxable base, deductions, tax rate, etc.), and distinguishes from other tax summary tools via the sibling list. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the target users (Spanish SLs and SAs) and gives the filing deadline, providing clear context. It does not explicitly state when not to use it, but the sibling list implies alternatives for other tax forms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so this is a non-read, non-destructive operation. The description transparently states the link is time-limited and single-use. It could elaborate on side effects (e.g., no client record created until registration), but overall adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear paragraphs with bilingual text. It is front-loaded with the core purpose and includes role requirement and example. Minor redundancy from bilingual text reduces conciseness slightly, but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (1 required) and an output schema (not shown but present). The description covers purpose, role, example, and key behavior (time-limited, single-use). It does not explain the output format, but the output schema presumably covers that. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by providing a concrete example (email='...', expiresInHours=72) and bilingual context, helping the agent understand typical usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a time-limited, single-use self-onboard invitation link for a prospective client. It distinguishes itself from sibling tools by specifying a unique purpose: client self-registration without manual data entry by the gestor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires gestor/admin role and provides a usage example. It does not explicitly list when not to use or alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint, idempotentHint) are consistent; description adds default behavior and scope requirement, plus output structure details.
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?
Bilingual description adds length, though information is front-loaded. Each sentence provides value, but could be more concise if single-language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and tool is read-only, description covers all needed aspects: what it returns, defaults, and usage.
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?
Only one parameter (ownerUid) with schema description; description adds context about defaulting to caller and elevated scope, enhancing 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 cross-client AR aging report with specific bucketed totals, per-workspace breakdown, and top overdue invoices, distinguishing it from sibling tools like 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions use cases (dunning prioritisation, end-of-month chase lists) and provides context on defaults and elevated scope requirement, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful context by specifying the exact return fields (alias, IBAN last 4, currency, balance, sync timestamp), enhancing transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consists of two sentences (English and Spanish), front-loads the action, and includes only essential information. Every sentence is informative and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and an output schema exists. The description provides a list of return fields, further aiding understanding. Despite the presence of many sibling tools, the description is complete for its straightforward purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter 'id' is already well-documented in the schema. The description does not add additional semantic meaning beyond what is in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'single connected bank account by ID', and lists the return fields, distinguishing it from siblings like list_bank_accounts which retrieves all accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a specific account by ID, which implicitly differentiates it from list_bank_accounts, but it does not explicitly state when to use this tool versus alternatives or provide context for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant context beyond annotations (read-only, idempotent, non-destructive): polling behavior, honest unavailability, and return fields. 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 English portion is concise and front-loaded with key purpose and behavior. The Spanish duplicate adds no value for English agents and could be omitted, but overall the description is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description covers polling behavior, expected response fields, and honest error handling. Missing details on invalid workflowRunId or rate limits, but generally sufficient for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter (workflowRunId) is well-described in the schema. The description does not add new parameter semantics beyond contextualizing the polling process. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls the status of an e-invoice dispatch workflow, specifying what is returned (current step, ack ID, download URLs). This verb+resource combination distinguishes it from sibling tools like send_einvoice and other status endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit polling interval (5-10 seconds) and termination conditions ('succeeded', 'failed', 'cancelled'). Also notes honest 'unavailable' response. Lacks explicit alternatives or when-not-to-use, but given context of e-invoice, usage 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 and idempotent behavior. The description adds that it returns full invoice including line items, totals, and status, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences in English and Spanish, front-loaded with the key action, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately explains the return value (full invoice with line items, totals, status). It is complete for a get-by-ID tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'id' is well-described. The description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single invoice by its ID', specifying the action and resource. It distinguishes from sibling tools like list_invoices (multiple invoices) and get_invoice_pdf (returns PDF).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing a single invoice by ID, but does not explicitly mention when not to use or alternatives. Given the simplicity and name, it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the description's role is lighter. It adds value by describing what data is returned (retentions per tenant, property, annual aggregate) and includes an example, fully aligning 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 concise (two sentences plus an example) and front-loaded with the essential purpose. Every sentence contributes meaning, and the bilingual format is a minor addition that does not harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, full annotation coverage, and an output schema, the description provides complete context: what the tool does, what it returns, and an example. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes the parameter 'period' as 'Year in format YYYY'. The description adds an example ('period='2025'') but does not provide significant additional semantics beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the IRPF annual summary for rental income withholdings (Modelo 180 in Spain), specifying it returns retentions per tenant, property, and annual aggregate. This distinguishes it from sibling tools like get_modelo_130_summary which target different tax forms.
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 indicates this tool is for rental income withholdings under Modelo 180, providing clear context. However, it does not explicitly state when to use it versus other modelo summaries, though the naming and context make the distinction apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds minimal behavioral context beyond confirming it returns totals. It does not mention potential error conditions, authentication needs, or rate limits. The description adds value by describing return content but not behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences in English followed by a bilingual Spanish repetition. Every sentence serves a purpose: defining the tool, specifying outputs, and providing an example. No superfluous words. The most important information comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no enums, output schema exists) and the richness of annotations and schema, the description covers the essential aspects. It explains the purpose, return values, and parameter usage. No significant gaps; the example aids understanding. The presence of an output schema compensates for any missing detail on return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the 'period' parameter with a description and format. The description adds an explicit example ('period='2025'') and repeats the format in Spanish. This provides concrete usage guidance, raising the score above baseline 3. No other parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting the IVA annual summary for Modelo 390 filing in Spain. It specifies the returned data (full-year totals by rate, deductible IVA, annual balance) and includes an example with 'period'. This distinguishes it from similar annual models (like Modelo 180, 347, etc.) by naming 'Modelo 390' and 'annual'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for annual IVA summary through the term 'annual recap' and the example with a year. However, it does not explicitly state when to use this tool versus other modelo summaries (e.g., quarterly). No exclusion criteria or alternatives are mentioned, but the context of 'annual' provides sufficient guidance for a knowledgeable user.
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: mentions potential schedule rollback after approval. Annotations already indicate idempotency and non-destructive nature; description enriches with use-case-specific behavior. 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, front-loaded with verb, includes bilingual text. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter. Annotations cover idempotency; description covers usage scenarios and side effects. Output schema exists for return values. Complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (leaveId) with full schema coverage (100%). Description adds no extra meaning beyond what the schema already provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (cancel), the resource (leave request), and distinguishes between use cases (employee before approval or HR after approval). Differentiates from sibling tools like leave_approve, leave_reject, and leave_request_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context on when to use (by employee before approval, by HR after approval) and mentions a consequence (schedule rollback). Lacks explicit comparison to alternatives like leave_reject, but still offers clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds value by specifying returned fields (id, station, status, table ref, items), providing clarity beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, bilingual, front-loaded with main action. No redundant information; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 optional parameters, output schema exists, annotations present. Description covers purpose, filters, and return fields; pagination parameters are adequately documented in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has full description. The description reiterates optional filters by status/station but does not add new semantic information 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?
Descriptions states 'List all kitchen order tickets for the live order board', clearly specifying verb and resource. It distinguishes from siblings like get_kitchen_ticket (single ticket), update_kitchen_ticket (mutation), and list_kitchen_stations (different entity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for viewing live board tickets with optional filters. It does not explicitly state when not to use or suggest alternatives, but the context of filters and the sibling tools list provides enough differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-destructive and idempotent behavior. The description adds context that no invoices are generated while paused and that the template is preserved, which goes 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 very concise (two sentences in English) with no unnecessary words. It is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, no nested objects, has output schema), the description completely explains the purpose, effect, and relationship to sibling. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' has a clear description in the schema. The description adds no additional meaning beyond the schema, which already covers 100% of 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 action ('Pause an active recurring invoice template') and the effect ('No new invoices are generated while paused'). It also distinguishes the tool from its sibling 'resume_recurring_invoice' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (pausing an active template) and explicitly names the alternative for resuming. No exclusions or 'when not to use' are given, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds that it returns the matrix but does not disclose additional behavioral traits beyond what annotations convey. 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 concise with two sentences plus a Spanish translation. Every sentence adds value and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no inputs) and has an output schema. The description fully covers its purpose and usage scenarios. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema description coverage is 100%. The description does not need to add parameter information, and the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full role-to-permission matrix for the workspace, listing every role, its permissions, and protected resources. It is distinct from sibling tools like 'permissions_me' and uses specific verbs and resource naming.
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 use cases: security audits, role design, and compliance reporting. However, it does not specify when not to use this tool or differentiate it from similar permission-related tools like 'permissions_me'.
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?
Beyond annotations (destructiveHint=true), the description adds key behavioral details: the action is irreversible, funds return to the original payment method, and confirm is a mandatory safety check. This fully informs the agent of consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences in English and a Spanish translation. It front-loads the core action and key requirements. The bilingual content is necessary but adds length; still efficient overall.
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 destructive action, the description covers irreversibility, payment method, confirm requirement, and partial refund. It does not detail return values, but an output schema exists. Sibling differentiation (e.g., refund_deposit) is missing but the tool name and description sufficiently narrow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description reiterates the purpose of 'confirm' and 'amountCents' but adds no new meaning beyond the schema. The 'reason' parameter is not mentioned, though its enum values are clear in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Refund a POS sale'), resource ('POS sale'), and scope ('in full or partially'), distinguishing it from sibling tools like refund_deposit. The verb 'refund' and resource 'POS sale' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool (for refunding POS sales) and includes a critical prerequisite ('MUST pass confirm=true'). However, it does not explicitly contrast with alternatives like refund_deposit or state when not to use, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, aligning with the dispatch action. The description reveals key behavior: returns immediately with a workflowRunId, async nature requiring polling, and honest 'unavailable' response. This adds value beyond the minimal 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 well-structured with bullet points for formats and modes, making it scannable. The bilingual text adds length but serves dual-language users. The first sentence is clear and action-oriented. Minor redundancy in the Spanish section but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers async behavior, format mapping, dispatch mode constraints, and error handling. An output schema exists but is not shown; the description does not explain return values, but the emphasis is on the workflowRunId. Given the tool's complexity (3 required params, many enums), the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context for format enums (e.g., which format for which country) and dispatch modes (e.g., 'chorus_pro=French portal'). This helps the agent choose appropriate values, going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Dispatch an e-invoice') and resource ('e-invoice'). Distinguishes from sibling tools like send_invoice (sends a regular invoice) and get_einvoice_status (polls for completion). The description includes specific formats and dispatch modes, making the purpose precise.
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 when to use (dispatching e-invoices with specific formats) and mentions async polling via get_einvoice_status. It also notes the 'unavailable' response if the backend is not deployed. However, it does not explicitly contrast with send_invoice or other invoice-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety profile. Description adds default eventType and example, but doesn't explicitly state the test event is actually sent to endpoint or discuss permissions/errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences (plus translation) that front-load action and purpose with zero 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?
Output schema exists, so return values are covered. Description provides sufficient context for a simple test tool, including parameter details and use case.
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 covers both params with descriptions. Description adds value with example usage and default for eventType, exceeding baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'fire' and resource 'webhook endpoint', clearly distinguishing from other webhook tools (get, create, update, delete) by being a test action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes usefulness for verifying reachability, signature, TLS. Lacks explicit when-not-to-use or prerequisites (webhook must exist), but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating non-destructive and idempotent behavior, the description adds value by specifying the workflow status progression (queued → preparing → ready → served) and listing the exact statuses and station reassignment, which goes beyond the annotation fields. 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 highly concise: two sentences in English and Spanish, front-loading the key action and purpose, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, 1 required), an output schema exists, and the description covers the essential purpose and usage. There is no missing information that would hinder correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with bilingual descriptions for each parameter. The description adds marginal value by listing the status progression examples, but the meaning is already fully conveyed by the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Advance' and the resource 'kitchen ticket', and distinguishes it from sibling tools like get_kitchen_ticket and list_kitchen_tickets by stating the key actions: updating status and reassigning station.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to advance a ticket through the workflow) and lists specific use cases (status change or reassignment). It doesn't explicitly mention when not to use it, but the purpose is unambiguous and no alternative tool exists among siblings for the same action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining PATCH semantics and the side effect that changes to lineItems/taxRate only affect future invoices. No contradiction with annotations (idempotentHint=true, readOnlyHint=false).
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 English portion is concise and front-loaded, with two sentences covering key points. The inclusion of a Spanish translation doubles length but is a business requirement. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavioral aspects (partial update, future-only effect) and is sufficient given the presence of an output schema and annotations. Could mention error conditions or prerequisites, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds specific behavioral notes for lineItems and taxRate parameters, clarifying their future-only impact, which provides additional 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 action ('update'), the resource ('recurring invoice template'), and the specific semantics ('PATCH', partial update). It distinguishes this tool from siblings like create, delete, pause, resume, and run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about partial update and future-only effect, but does not explicitly state when to use vs alternatives or exclude certain scenarios. The agent can infer usage from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses PATCH semantics and partial update behavior, aligning with idempotentHint; 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences (plus Spanish translation) front-load the key behavior.
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?
Complete given 5 params, output schema present, and simple semantics; example aids understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters at 100%, description adds an example using id and active but no further 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?
Clearly states 'update an existing webhook configuration using PATCH semantics', distinguishing it from create, delete, and test webhook siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for updating and gives an example (disabling a webhook), but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. Description adds that it creates an audit trail entry per attempt and requires confirm=true, which is useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is bilingual (English and Spanish), doubling length but serving a multilingual user base. Key info is front-loaded: purpose, idempotency, audit trail, requirement. Could be more concise by dropping the trust area tag, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations (idempotentHint) and required params, the description covers the essential behavioral points: idempotency, audit trail, confirm requirement, and invoice status condition. Lacks error scenarios or response details, but output schema may cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds the constraint that confirm must be true and that invoiceId must belong to a failed invoice. This provides meaningful behavioral context beyond the bare 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?
Clearly states the tool re-submits a failed or rejected VeriFactu submission to AEAT. The phrase 'TRUST AREA — COMPLIANCE' sets domain context. Distinguishes from siblings like 'send_invoice' (new submission) and 'verifactu_status' (status check).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Only use on invoices with status="failed".' and 'Requires confirm=true.' Provides clear when-to-use context. Lacks explicit when-not-to-use or alternatives, but condition is precise enough for correct selection.
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 details key behaviors: interest calculation based on EU directive, auto-calculation from days overdue, and creation of a debit note. Annotations (readOnlyHint=false, destructiveHint=false) align with this, and additional context is provided beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual, making it longer than necessary. While clear and front-loaded, the duplication of content in two languages reduces conciseness for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main function and auto-calculation feature. It assumes the invoice is overdue, which is clearly stated. Given the output schema exists, it is sufficiently complete for a tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that amount and daysOverdue can be auto-calculated if omitted, supplementing the schema's override descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies late payment interest to overdue invoices, calculates based on EU Late Payment Directive, and creates a debit note. It is specific and distinct from sibling tools like create_credit_note.
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 indicates the tool is for applying late fees to overdue invoices but does not explicitly contrast with alternatives or state when not to use it. However, the context of sibling tools implies its specific role.
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 and destructiveHint=false. The description adds that signed XML for Facturae requires a workspace signing certificate and returns a signed download URL valid for 24 hours, which are important behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information in English, followed by Spanish translation. While slightly longer due to bilingual content, every sentence adds value and no information is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not cover return values. It adequately covers purpose, format selection, signed behavior, and URL expiration. Minor gap: does not mention potential error conditions or prerequisites beyond cert for signed Facturae.
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?
Schema coverage is 100%, but the description adds significant value: it explains how to choose format based on recipient country, clarifies that signed only applies to Facturae, and mentions certificate configuration requirement. This goes beyond the schema's enum and type info.
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 exports an invoice as e-invoicing XML, lists supported formats, and specifies the signed option. It distinguishes itself from siblings like send_einvoice and validate_einvoice_xml by focusing on generating the XML file.
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 per-country format guidance (e.g., ES->facturae, DE->xrechnung-cii/ubl) and explains the signed parameter's use case. Does not explicitly mention when not to use or alternatives, but the context is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds that it returns rate, base, and amount due, and explains the regional context. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences per language plus an example, no fluff. Front-loaded with essential info. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but implied) and full schema coverage, the description is complete enough. It explains the tax, region, returns, and gives an example. Could mention rate source but that's minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description reinforces with an example (ncCode='8471', amount=1000), adding practical value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates AIEM for goods in the Canary Islands, using a specific verb and resource. It distinguishes from siblings (e.g., get_modelo_180_summary) by focusing on a specific tax calculation rather than summary reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use it (calculate AIEM for a product) and provides context about AIEM being a surcharge over IGIC for protected industries. It lacks explicit when-not-to-use or alternatives, but the purpose is clear and no sibling directly competes.
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 mutation (readOnlyHint=false) and non-destructiveness. The description adds that rules apply automatically and use AND logic, providing helpful 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 concise with three sentences and an example. It is front-loaded with purpose. The bilingual version adds no harm but is not essential. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter descriptions, the description covers the essential logic and provides an example. It does not mention prerequisites or error cases, but overall is sufficient for use.
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 100% schema description coverage, baseline is 3. The description adds an example and explains the AND logic for conditions, enhancing understanding beyond schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a bank auto-categorization rule. It distinguishes from siblings like 'frihet_bank_rules_list' by focusing on creation. The example illustrates the purpose well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to create a rule) and provides an example. It does not discuss when not to use or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint true, destructiveHint false), description explains it sets status to 'rejected' and records rejector+reason in audit trail. Adds TRUST AREA context. 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?
Four sentences covering purpose, effect, role, and example. Bilingual without redundancy. Every sentence adds necessary information; 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?
With output schema present and annotations, description covers core aspects: action, effects, requirements, and example. Slight omission of output details, but output schema compensates. Reasonable 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?
Schema has 100% description coverage. Description adds an example (entryId='gl_2026_q1_042', reason='Importe incorrecto...') that clarifies expected formats and usage, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Reject a General Ledger journal entry pending review', specifying the action and resource. Distinguishes from sibling tools like 'frihet_gl_entry_approve' (approve) and 'frihet_gl_entry_audit_log' (audit log).
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?
Specifies role requirement ('gestor/admin role') and mandatory reason. Implicitly contrasts with approve/audit tools by naming the action. Could explicitly state when not to use, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which show non-readonly, non-destructive), description reveals the tool is a forward-compatible stub that returns NotImplementedYet until certificates are issued, plus mode behaviors. This fully prepares the agent for expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but includes redundant bilingual content (English and Spanish) which nearly doubles length. Front-loaded with purpose, but the duplication could be trimmed without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and only 2 parameters, the description fully covers tool behavior, current limitations, and mode environments. No gaps in information needed for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for both parameters (mode enum, invoiceId). Description repeats mode explanations already present in schema, adding no new semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool submits invoices to Polish KSeF system, with explicit modes (mock, sandbox, production). Distinguishes from generic einvoice tools by specifying the national system.
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 clear usage context for each mode and discloses that the production endpoint is not yet active, guiding agents to use mock/sandbox for testing. Lacks explicit alternatives for other e-invoicing systems, but the tool name implies Poland-specific 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that quotes are 'proposals sent to clients before they become invoices' and lists supported statuses. No contradictions; description complements annotations well.
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 brief and front-loaded with purpose. It includes both English and Spanish, which adds length but provides clarity for multilingual users. No wasted sentences, though the bilingual repetition could be slightly trimmed for English-only agents.
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 listing tool with 9 optional parameters and an output schema, the description explains the business context (quotes are proposals), supported filters, and pagination. It is complete enough for an AI agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with bilingual descriptions. The description adds value by grouping functionality ('optional pagination and filters') and providing a concrete example (status='sent', from='2026-01-01', limit=20). The example helps clarify usage beyond schema 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?
The description clearly states 'list all quotes/estimates' with optional pagination and filters. It distinguishes quotes as proposals before invoices, differentiating from sibling tools like list_invoices and get_quote. The verb 'list' and resource 'quotes' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to list quotes with filters and pagination) and gives an example. It does not explicitly state when not to use or mention alternatives, but the context of sibling tools and the detailed description make usage 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?
Description adds context beyond annotations (readOnly, idempotent) by listing returned fields and use cases. No contradiction; annotations confirm safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. Bilingual addition (Spanish) slightly increases length but still focused. Would benefit from removing duplicate if not needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, description fully covers what the tool does and why it's useful. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; description doesn't need to cover them. Baseline 4 for zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Return' with specific resource 'current workspace onboarding state' and detailed fields (persona, steps, percent). Distinct from sibling 'onboarding_persona_set' which sets persona.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases (in-app guidance, sales follow-up triggers, partner program tracking). Doesn't specify exclusions or alternatives, but context is sufficient.
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 read-only, idempotent, non-destructive, and closed-world. The description adds that the tool exports staged data and does not calculate payroll, which aligns with annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with bullet points for formats. The final Spanish sentence is redundant as the rest of the description is already bilingual. Slightly more wordy than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, formats, date format, and what the tool does not do. Since there is an output schema, it need not explain return values. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are already bilingual and detailed in the schema. The tool description adds minimal new info (e.g., the note about not calculating payroll) but largely repeats the schema content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool's purpose: exporting payroll data in gestoria-compatible format. It lists five specific formats and emphasizes that Frihet does not calculate payroll, distinguishing it from other payroll tools like payroll_checklist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (export staged data) and what it does not do (no payroll calculation). It specifies supported formats and date format. However, it does not mention alternatives among sibling tools for 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral info beyond annotations: lists what gets frozen (invoices, expenses, journal entries, bank reconciliations), requires confirm=true, and notes idempotency. 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?
Relatively concise with key info front-loaded. Bilingual duplication adds some length but not excessive. Could be slightly tighter by dropping the Spanish repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavioral effects, requirements, idempotency, and relationship to sibling. Output schema exists so return values not needed. Complete for a destructive, idempotent tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Description reinforces that confirm must be true and mentions type, but adds no new parameter-level detail beyond what schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool closes a monthly or quarterly accounting period, freezing invoices, expenses, etc. Distinguishes from sibling period_reopen by noting reopened periods can be opened with that tool.
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 requires confirm=true and states idempotency. Gives context for when to use and hints at alternatives (period_reopen for reopening). Could be more explicit about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it returns effective role+permissions, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in English plus Spanish translation. The Spanish is redundant but not detrimental. Could be slightly more streamlined, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return value (effective role + permissions). Output schema exists to provide structure. No mention of error cases or authentication, but adequate for a safe read operation.
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?
No parameters. Schema coverage is 100%. Description adds no parameter info, which is appropriate. Baseline 4, but score 5 for perfect handling of zero-param case.
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 explicitly states 'Return the caller's effective role + permissions in the current workspace', with a specific verb, resource, and context. Distinguishes from sibling `permissions_matrix` which likely returns broader permissions.
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?
Clearly states use cases: client-side UI gating, debugging access errors, capability discovery. Does not explicitly mention when not to use or alternatives, but the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds prerequisites and optional behavior. It does not explicitly confirm idempotency but the annotation covers that. The mention of prerequisites adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences in English and Spanish, front-loaded with the core purpose, and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema exists), the description covers prerequisites and optional parameters. It does not explain the output, but that is handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds meaning by explaining the 'to' parameter as an optional override and the 'id' parameter's constraints (must exist, not expired/rejected), which are not fully captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (send), the resource (quote/estimate), and the method (via email). It distinguishes itself from siblings like send_invoice by targeting quotes specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: the quote must exist and not be expired/rejected. It also mentions the optional recipient override, but does not explicitly exclude alternatives like send_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds behavioral context: it is a role change operation requiring specific permissions (admin/owner) and cannot target the owner. While it doesn't detail side effects like notifications or audit logs, it sufficiently supplements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise English sentences with no redundant information. Key info is front-loaded: purpose, permissions, exception, and example. The structure is clean and efficient, earning its space.
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 two-parameter tool with an output schema, the description covers purpose, permissions, exception, and provides an example. It doesn't explain return values (handled by output schema). Minor gap: potential downstream effects of role change, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description provides a concrete example (memberId='mbr_abc123', role='admin') which adds slight value, but not substantially beyond the schema's parameter descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Change the role of an existing team member', specifying the verb and resource. It distinguishes from siblings like 'invite_team_member' and 'remove_team_member' by focusing on role changes, and explicitly mentions the owner role exception, differentiating from an ownership transfer flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to change a role) and who can use it (workspace admins or owners). Also provides a clear exclusion: cannot change the owner's role, directing to a dedicated ownership transfer flow. This offers complete guidance on 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns company name, address, and validity status from official EU registry, which is consistent. No contradictions; behavioral traits are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in English followed by Spanish translation (appropriate for bilingual context). Front-loaded with purpose and key usage instruction. No superfluous content.
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 lookup tool with output schema implied, description covers purpose, usage, parameters, and expected output. Mentions intra-EU invoicing compliance context. No gaps given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. Description adds example values and clarifies that vatNumber is without country prefix, providing additional meaning beyond schema. Lowers cognitive load for agent.
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 validates an EU VAT number via VIES system, with specific verb 'validate' and resource 'EU VAT number'. It distinguishes itself from siblings as the only VAT validation tool among many invoice and accounting 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?
Provides clear guidance: 'always validate before adding a EU client', essential for intra-EU invoicing compliance. Includes an example. Does not explicitly mention when not to use, but context makes usage clear; no direct alternative tool exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: variable interpolation, dueDateOffsetDays relative to bulk-send, attachmentRequired enforcement. 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?
Contains both English and Spanish versions, which is useful for bilingual contexts but slightly redundant. Front-loaded with purpose, includes example for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations covering non-read, non-destructive nature, description sufficiently explains behavior, parameters, and usage context for a creation 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?
Schema descriptions cover all parameters, but description adds concrete context like variable interpolation and example, enhancing understanding 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?
Clearly states verb 'Create' and resource 'reusable document request template'. Differentiates from siblings like gestoria_template_bulk_send and gestoria_message_send by specifying bulk-send purpose.
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?
Implies usage for creating templates intended for bulk-sending, but lacks explicit guidance on when to use this vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by explaining what the setting affects (module visibility, chart-of-accounts, checklist). Annotations already provide idempotentHint; description confirms and elaborates on consequences.
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?
English portion is front-loaded and clear, but the Spanish duplicate adds roughly 50% more text unnecessarily. Still overall concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one enum parameter, idempotent, no destructive effects), the description covers purpose, behavior, and parameter meaning fully. Output schema exists to handle return values.
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?
Adds meaning to the single parameter by explaining each persona with real-world context (e.g., 'autonomo' means self-employed in Spain). Schema coverage is 100% but description enriches understanding significantly.
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 sets the workspace persona and enumerates the four supported personas with descriptions. Differentiates from sibling 'onboarding_status' which likely reads rather than writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states idempotent behavior (no-op on repeated calls) but does not compare with alternatives like 'onboarding_status'. The description implies when to use but lacks explicit when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, consistent with a report generation tool. The description adds behavioral context: it aggregates hours and estimates cost in EUR, and implies it is non-destructive. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences in English and one in Spanish. Every sentence adds information: purpose, aggregation details, use cases, and format examples. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not needed in description), the description fully covers the tool's purpose, usage, parameter format examples, and use cases. It is complete for a report generation tool with good annotations.
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 100% coverage with descriptions for both parameters. The description adds value by providing concrete format examples for the period parameter ('YYYY-MM', 'YYYY-QN', 'YYYY') and bilingual labels, which helps the agent understand expected input beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an overtime report, aggregates regular vs overtime hours per employee and total cost in EUR. It specifies the resource (overtime report) and action (generate), and distinguishes from sibling tools like list_time_entries or get_time_summary by focusing on overtime aggregation and cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is 'Useful for payroll prep and labor-law audits,' providing clear context for when to use. It does not explicitly mention when not to use or name alternatives, but the use cases are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to mention it. However, it adds value by describing status values and the missingFields array, which gives insight into behavior 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 concise and well-structured: purpose first, then bullet-pointed statuses, then usage note and format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, output schema exists), the description covers purpose, usage, status meanings, and format. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so baseline is 3. The description reiterates month format but doesn't add new semantics 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 lists all employees for a given month with payroll readiness status, which is specific and distinct from siblings like payroll_export. It includes status values and usage hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use BEFORE payroll_export to identify gaps', providing clear guidance on when to use this tool instead of alternatives. Also specifies month format.
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?
Discloses important behavioral traits beyond annotations: immediate loss of access, preservation of created records, restriction on removing owner, and confirmation requirement. Annotations already indicate destructive and idempotent, but description adds concrete details.
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?
Very concise: 4 sentences in English, front-loaded with the main action. Bilingual inclusion is justified for audience. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 params), annotations, and presence of output schema (context signal), the description covers all essential behavioral aspects: access loss, record preservation, owner restriction, confirmation requirement. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% of parameters with descriptions. The description reinforces confirm as a safety measure but does not add significant new meaning beyond the schema for either 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 'Remove a member from the workspace' with specific verb and resource. It distinguishes from sibling tools like invite_team_member and update_team_member_role by focusing on removal and noting preservation of records.
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 clear usage context: removing a member, immediate loss of access, cannot remove owner (requires transfer first), and requires confirm=true. Lacks explicit alternatives or prerequisites like permissions, but gives strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes PATCH semantics and partial update behavior, adding value beyond annotations. Aligns with idempotentHint=true and destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded key info. Bilingual content is a minor overhead but does not hinder clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers partial update semantics. Output schema (present but not shown) would handle return values, so no gap.
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 covers all 5 parameters (100% coverage). Description includes an example that adds concrete usage context, elevating above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), resource (product), and method (PATCH semantics), distinguishing it from create and delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that only provided fields are changed, giving a clear usage pattern. However, it does not explicitly compare with alternatives like create_product or delete_product.
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 discloses key behaviors beyond annotations: triggers per-client notification handler, honours opt-out flag, uses periodOverrides for template variables, returns per-client outcome with success count/failures/duration, and trust area requirement. This provides rich behavioral context that annotations (only readOnlyHint=false, etc.) do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual (English/Spanish), which doubles its length but is necessary for the audience. It front-loads the core action and then adds extra details in a logical order. Every sentence adds value: bulk limit, notification, opt-out, periodOverrides, output, trust, example. No fluff, though bilingual repetition slightly reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bulk send with overrides, notifications, opt-out, trust area), the description covers all essential aspects: purpose, usage context, behavioral details, parameter semantics with example, and output summary. Since an output schema exists, the description's mention of 'per-client outcome with success count, failures, and total duration' is sufficient.
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 100% parameter coverage with descriptions. The description adds value by providing a concrete example (templateId='tpl_iva_q', clientWorkspaceIds=['ws_a','ws_b','ws_c'], periodOverrides={quarter:3, year:2026}) that clarifies usage, especially for the nested periodOverrides object. This exceeds the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends the same document request template to up to 500 client workspaces. It specifies the verb 'Send', the resource 'document request template', and the scope 'up to 500 client workspaces'. This distinguishes it from siblings like 'gestoria_message_send' (presumably single message) and 'gestoria_template_create' (template creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that each request triggers notifications, respects opt-out, uses periodOverrides, and requires recipients to have accountant access (RGPD). It provides context for when to use this tool (bulk sending) but does not explicitly list alternatives or when not to use it. The sibling 'gestoria_message_send' is implied as an alternative for single sends.
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, destructiveHint, and idempotentHint, confirming safety. The description adds the specific behavior of returning the current open or most recently closed period when periodId is omitted, which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English portion is two concise sentences that immediately convey the purpose and default behavior. There is no fluff; the Spanish translation is auxiliary. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with comprehensive annotations and an output schema, the description fully covers the necessary information: what it returns, possible states, and default behavior. No gaps.
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 input schema has 100% coverage for periodId with a description. The description adds critical context: 'Without periodId returns the current open or most recently closed period', explaining the parameter's optionality and default behavior, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Get', the resource 'current accounting period state', and lists possible states (open/closing/closed/reopened). It distinguishes from sibling tools period_close and period_reopen by being read-only. The default behavior without periodId is clearly stated, making the tool's purpose unmistakable.
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 clearly implies when to use: to check the accounting period state. Although it does not explicitly state when not to use or mention alternatives, the read-only nature and default behavior provide sufficient context. The sibling tools for mutating operations (period_close, period_reopen) are evident from the sibling list.
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?
Beyond annotations (which only show non-readOnly, non-destructive), the description adds key behaviors: territory auto-detection from workspace address, return of TBAI ID and QR code URL, and sandbox vs production distinction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient with two short paragraphs (English and Spanish). It front-loads key actions and outputs. The bilingual repetition costs some conciseness but is justified for the region.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (territory detection, sandbox, production requirements, output fields), the description covers all critical aspects. It mentions return values (TBAI ID, QR URL) even though output schema exists.
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 100% coverage with basic descriptions. The description adds meaning: sandbox is for test endpoints, invoiceId is a Frihet invoice ID. It also notes territory auto-detection, which is not in schema but is relevant context.
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 submits an invoice to the Basque Country TicketBAI system, a specific verb+resource. It distinguishes from siblings like 'ticketbai_status' and other e-invoicing tools by naming the system and territory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains when to use sandbox=true for tests and notes production requires a valid certificate. It implies usage context (Basque Country invoicing) but does not explicitly state when not to use or compare with alternatives like 'ksef_submit'.
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 specific behavioral details beyond annotations: the validators used (KOSIT, Mustang, etc.) and the return format (errors with severity, XPath, message, rule ID). It also clarifies the honesty policy for unavailable backends. Annotations already indicate read-only and idempotent, but the description enriches transparency.
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 efficient and front-loaded with the core purpose. However, it includes bilingual content (English and Spanish) which adds length; while not excessive, it could be streamlined for an AI agent. Overall, it remains concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, output schema exists), the description is fully adequate. It covers the purpose, usage timing, edge cases (unavailable backend), and validation process. With output schema present, return values need no further explanation. No gaps remain.
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 100% description coverage, so each parameter is already explained. The tool description adds extra context for the 'format' parameter, stating it 'determines which validator and ruleset to apply', which aids understanding beyond the enum list. This incremental value merits a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates e-invoice XML against schema and schematron rules, specifying the verb 'validate' and resource 'e-invoice XML'. It distinguishes from sibling tools like 'send_einvoice' and 'get_einvoice_status' by focusing on pre-dispatch validation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using the tool 'before dispatch to catch errors early', providing a clear use case. It also warns about the 'unavailable' response when the backend is not deployed, setting expectations. Although it does not compare with alternatives, the guidance is sufficient for the 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 already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context: it aggregates data, returns a bottleneck flag, and provides wait times. 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 English portion is concise and front-loaded. However, the Spanish duplicate makes the description longer than necessary. It's still readable and efficient enough for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, a relatively simple output, and comprehensive annotations, the description fully explains the tool's purpose, usage, and return values, making it complete for an AI agent.
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?
No parameters exist, so the schema fully covers them. The description adds no parameter information, but none is needed. Baseline for 0 params is 4, but the description's clarity on output compensates for the lack of param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates open kitchen tickets per station and flags the bottleneck. It specifies the returned fields (openTickets, oldest wait, isBottleneck). This distinguishes it from siblings like list_kitchen_tickets or get_kitchen_ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instruction: 'Call this first to diagnose kitchen throughput issues before drilling into individual tickets.' Provides a clear when-to-use and implies not to use for other purposes.
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:

[![frihet-mcp MCP server](https://glama.ai/mcp/servers/Frihet-io/frihet-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Frihet-io/frihet-mcp)

Score Badge

Copy to your README.md:

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

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