WAzion MCP Server

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation2/5
There is significant overlap and ambiguity between tools, especially in areas like contact management (multiple import/delete tools), WhatsApp workflows (create, update, delete, bulk operations), and AI corrections (set_ai_error vs set_customer_ai_error). Descriptions help but many tools have unclear boundaries, such as various list_* and get_* tools that seem to retrieve similar data with minor variations. This makes it difficult for an agent to confidently select the right tool without deep context.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun pattern (e.g., create_campaign, list_agents, update_task), using snake_case throughout. However, there are minor deviations like 'dry_run_workflow' (underscore in verb) and some tools with mixed language (Spanish and English in names, e.g., 'add_contacts_to_list' vs 'anadir comentario a cliente' in description). Overall, the pattern is predictable but not perfectly uniform.
Tool Count1/5
With 346 tools, the count is extremely high and feels overwhelming for the apparent scope of a customer service and marketing platform. Many tools appear redundant or overly granular (e.g., multiple delete tools for different entities, numerous get_* queries for similar stats). This volume will confuse agents and likely includes many tools that could be consolidated into fewer, more general-purpose ones.
Completeness5/5
The tool set is remarkably complete, covering CRUD operations, queries, mutations, and lifecycle management across all domains (e.g., WhatsApp, email, calendar, knowledge base, campaigns). There are no obvious gaps; every major functionality has corresponding tools for creation, retrieval, update, deletion, and auxiliary actions like testing, exporting, and configuration. The surface is exhaustive for the platform's purpose.
Average 3.4/5 across 346 of 346 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
No annotations provided. The description uses both 'restore' and 'get', which may imply different actions (mutative vs read-only), but it does not clarify whether the tool modifies state or simply retrieves. Side effects and authorization requirements are not mentioned.
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 a single sentence, achieving conciseness, but it includes contradictory information about language filtering, reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose and the lack of output schema, the description is incomplete. It does not explain what constitutes a 'default prompt', whether language is inferred, or what the output represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters with 100% coverage, so baseline is 4. However, the description mentions 'language [query]' which falsely implies a parameter. This mismatch misleads the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'restore/get default prompt' but ambiguously includes 'language [query]' despite the input schema having no parameters. This vagueness fails to distinguish from sibling tools like 'get_prompt' or 'save_prompt'.
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 such as 'get_prompt' or 'rollback_prompt'. Context signals and sibling names indicate potential for confusion.
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?
No annotations provided, so description must cover behavior. It only says 'shows purchase history' without explaining pagination, output format, or data freshness. The mention of '[query]' is misleading and contradicts the actual parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but includes unnecessary and misleading '[query]'. Conciseness is good but at the expense of accuracy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and the description fails to explain the return structure, pagination, or meaning of credits. Incomplete for a paginated list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for page and limit. The description adds no value and actually misleads by referencing a non-existent query parameter. Baseline 3 reduced due to misinformation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'View purchase history of credits', which is a specific verb and resource. However, it mentions '[query]' which does not exist in the input schema, causing confusion. It does not differentiate from sibling like get_credit_history.
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., get_credit_history). No exclusionary language or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose whether the tool is read-only, destructive, or any behavioral traits. For a stats tool, it is likely read-only, but it is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—one line. It front-loads the key idea but lacks structure like usage examples or return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain what the response contains (e.g., hourly counts, averages). A stats tool should describe its output to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions. The description does not add significant 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Distribucion horaria de mensajes WhatsApp' (hourly distribution) but the tool name says 'response_time_stats'. This mismatch between name and description creates confusion about what the tool actually does.
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 the many sibling WhatsApp tools like get_whatsapp_message_logs or get_whatsapp_conversation_history. No context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description includes [mutation] hint but no other behavioral details (e.g., whether it overwrites or appends, permissions needed). Minimal 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?
Description is a single line with a mutation tag. It is concise and front-loaded, but could include more key info without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, multiple sources, and many sibling tools, the description is incomplete. It does not cover all sources mentioned in schema, nor explain how it relates to other import tools. No output schema so return values unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is described. Description adds context that manual and conversations sources are supported, but does not explain csv/txt or clarify relationship between phones_text and phones. Baseline 3 with marginal addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it imports contacts to a bulk marketing list and mentions manual and conversations sources, but does not differentiate from sibling tools like import_contacts_csv, import_contacts_manual, etc. The purpose is clear but lacks distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 the many sibling import tools. With specific alternatives for each source, the description should indicate scenarios, but it provides none.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states 'using AI' without explaining side effects, rate limits, or what happens to the conversation (e.g., overhead of translation). This is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), but it includes a placeholder '[query]' that may confuse agents. While concise, it lacks structure and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema or annotations, the description fails to provide essential context such as return format, pagination, or limits. This leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions for all parameters. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'translate' and the resource 'conversation' using AI. However, it does not differentiate from sibling tools like toggle_auto_translate or get_ai_summary, which may also involve translation or summarization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions AI analysis and tag suggestion but does not explain how the AI works, whether it modifies customer data, or what the output looks like. The parameters imply summary capabilities unrelated to tagging, creating confusion.
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 a single sentence, which is concise, but it includes a placeholder '[query]' and lacks structure (e.g., bullet points or sections). It is adequate but not well-formed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain how parameters like summary_type, days, and hours relate to the tagging purpose, leaving the agent unsure of the tool's actual capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 8 parameters. The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it auto-tags customers with AI by analyzing the conversation, which is a clear purpose. However, the input schema includes parameters like summary_type, days, hours, and target_language that suggest the tool may also perform summarization or translation, creating a mismatch. It does not differentiate from siblings like 'add_customer_tag'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_customer_tag' or 'update_customer_tags'. There are no context signals or exclusions 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?
No annotations are provided, and the description does not disclose any behavioral aspects such as read-only nature, rate limits, or what data is returned. It only says 'shows recent executions'.
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 a single sentence, which is concise but lacks important details needed for an AI agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling tools, the description is incomplete. It does not explain the response format or provide enough context to differentiate from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 83% coverage, so the schema already documents parameter meanings. The description adds no extra parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it shows recent executions of automatic WhatsApp workflows, but the term 'workflows' is vague. It does not distinguish from sibling tools like 'get_whatsapp_workflow_logs' or 'get_workflow_session_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its many siblings. No when-not or alternative tools 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?
No hay anotaciones, por lo que la descripción debe revelar comportamientos. Solo menciona que obtiene permisos, pero no dice si es de solo lectura, si requiere autenticación, o si hay efectos secundarios. La presencia del fragmento '[query]' sin explicación añade confusión.
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?
La descripción es una sola oración concisa, pero la inclusión de '[query]' al final parece fuera de lugar y no está explicada, lo que reduce la claridad. Es breve pero no enteramente efectiva.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
La herramienta tiene un solo parámetro y no tiene esquema de salida, por lo que la descripción debería especificar qué devuelve con más detalle. Solo dice 'permisos configurados' y 'registro completo', sin estructura. La ambigüedad del '[query]' y la falta de contexto sobre permisos disponibles hacen que sea incompleta para el agente.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
El esquema tiene 100% de cobertura de descripción para el parámetro 'id', pero la descripción añade un extraño '[query]' que no coincide con el esquema. Esto puede engañar al agente sobre la existencia de un parámetro adicional. No se agrega valor semántico más allá del esquema.
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?
La descripción indica claramente que el objetivo es obtener los permisos configurados de un agente y el registro completo de permisos disponibles. El verbo 'Obtiene' y el recurso 'permisos de un agente' definen la acción, y se diferencia de su hermano 'save_agent_permissions'. Sin embargo, no especifica exactamente qué significa 'registro completo de permisos disponibles' ni cómo se diferencia de otras herramientas 'get'.
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 se proporciona orientación sobre cuándo usar esta herramienta en lugar de otras, como 'save_agent_permissions'. Tampoco se mencionan contextos de uso ni exclusiones. Un agente no sabría si esta herramienta es la adecuada sin inferirlo del nombre.
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?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, nor does it mention rate limits, data freshness, or any side effects. The behavior is implied to be a query but not explicitly stated.
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 (one line) and front-loaded with the main purpose. However, it sacrifices completeness for brevity; it is concise but not fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling analytics tools, this description lacks sufficient context to distinguish itself. No output schema is provided, and the description does not specify return format or pagination. The '[query]' fragment is confusing.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 all parameters described. The description adds minimal value beyond the schema, only hinting at the returned distribution attributes. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides analytics on conversations, specifically distribution of satisfaction, urgency, and intentions. However, it fails to differentiate from sibling analytics tools like get_analytics or get_structured_analytics. The meaning of '[query]' is unclear and not reflected in the input schema.
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 such as get_analytics, get_sentiment_analysis, or get_structured_analytics. The description does not specify prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should fully disclose behavior. It mentions 'recent' and '[query]' but does not state whether the operation is read-only, what permissions are needed, or any side effects. The behavior is implied but not explicit.
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 a single sentence, which is concise, but it includes a placeholder '[query]' that reduces clarity. It could be restructured to be more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return format, how parameters interact, or how this tool relates to siblings. The '[query]' token suggests missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'plugin_type' and 'period' have descriptions). The description adds no parameter information; the '[query]' placeholder is unclear. Hours and limit lack context despite having defaults, and the description does not clarify their usage beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves recent plugin questions from Product Q&A, using a specific verb ('Muestra') and resource ('preguntas recientes de plugins'). However, it does not differentiate from sibling tools like 'get_unanswered_plugin_questions' or 'get_product_qa_questions', which handle similar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without any context on prerequisites, exclusions, or comparison to sibling tools.
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?
No annotations are present, so the description must carry the full burden. It states a read operation ('list all connected calendar providers') but does not disclose any behavioral traits such as authentication needs, rate limits, or potential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence plus a title prefix), but the prefix 'List Calendar Connections — ' is redundant with the tool name. It could be trimmed without loss of meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at what the response contains (e.g., provider names, statuses). It does not, leaving the agent without expected return 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 input schema is an empty object with no parameters, so schema coverage is 100%. The description adds no parameter-specific information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connected calendar providers (Google, Microsoft) for a shop, distinguishing it from siblings like list_calendars or list_calendar_agents. However, the phrase 'for this shop [query]' is somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_calendars or list_calendar_services. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states filtering by status but does not disclose pagination behavior, ordering, or what happens on empty results. This is a significant gap for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an unclear '[query]' placeholder. It front-loads the purpose but the structure is slightly confusing due to the dash and list format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good schema coverage, the description lacks return type information and behavioral context. Without annotations or output schema, the agent is left uninformed about pagination limits, error handling, or what the list contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists knowledge snippets filtered by status, matching the tool name. However, it does not differentiate from sibling tools like edit_knowledge_snippet or delete_knowledge_snippet, which handle the same resource.
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. Siblings like search_conversations or global_search exist but are not mentioned. The description lacks any when-to-use or when-not-to-use context.
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?
No annotations are provided, so the description should disclose behavioral traits. It only includes '[mutation]' indicating it modifies data, but it does not explain that it can add, remove, or replace tags, nor does it mention permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two segments separated by em dash) and includes the useful '[mutation]' marker. It is concise, but could be more informative without being lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three distinct modes (add, remove, replace) and no output schema or annotations, the description is incomplete. It does not summarize the different behaviors, leaving the agent to infer from parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters. The tool description adds no extra meaning beyond the schema. Baseline is 3; the description provides no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configura las etiquetas para clasificar clientes' indicates it configures customer tags, but it is vague. It does not specify that it supports add, remove, or replace operations, which are evident from the schema. The purpose is clear but not specific, lacking distinction from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings like add_customer_tag or remove_customer_tag. The description does not mention context or alternatives, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks annotations and fails to disclose behavioral traits such as required permissions, side effects, or the fact that the input schema includes parameters (e.g., date_from, date_to, agent_id, event_id) that appear unrelated to creation. This misalignment undermines 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 a single, efficient line that communicates the core action. However, its brevity sacrifices valuable context that could be provided without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain the return value, required permissions, or the function of seemingly extraneous input fields, leaving an agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema provides 82% description coverage, the description adds no additional meaning. Notably, parameters like 'date_from', 'date_to', 'agent_id', and 'event_id' are present but unexplained; they seem out of place for a creation operation, and the description does not clarify their purpose.
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 'Schedule a new event or appointment in the calendar', establishing the verb (create/schedule) and resource (calendar event). However, it does not differentiate from sibling tools like update_calendar_event or create_calendar_notification; the name alone carries that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., update_calendar_event, delete_calendar_event). The description does not mention prerequisites, necessary permissions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully convey behavioral traits. It only states 'shows tasks' without indicating that this is a read-only operation or disclosing any side effects. No mention of pagination, filtering behavior, or that results are limited to a specific agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence) but at the cost of necessary information. It lacks structure (e.g., no front-loaded key points) and omits crucial details about tool behavior and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, the description is notably incomplete. It fails to explain how parameters like 'status', 'priority', or pagination controls work together. An agent cannot sufficiently understand the tool's capabilities from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 11 parameters. The description adds no additional meaning beyond the schema, so baseline score applies. No insights into parameter relationships or required combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Muestra las tareas asignadas a un agente especifico' which clearly indicates the verb (shows) and resource (tasks). However, it could be more specific about the exact filtering scope. The brackets around [query] are ambiguous and don't differentiate from sibling tools like 'list_tasks'.
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., 'list_tasks', 'get_agent_assignments', 'get_overdue_tasks'). The description fails to provide context or exclusions, leaving the agent uncertain about optimal use cases.
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?
With no annotations, the description only states basic behavior (retrieving recent conversations sorted by last activity). It omits side effects, authentication needs, rate limits, pagination details, or what the response contains. The ambiguous '[query]' at the end adds confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one short sentence) but includes an unclear '[query]' fragment. It lacks structure and does not front-load the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the meaning of many parameters (e.g., agent_id, message, format), pagination behavior, or response format. The tool is complex but the description provides minimal 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% (all 13 parameters have descriptions). The description adds little beyond the schema, except possibly implying the sorting behavior. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent conversations ordered by last activity. The verb 'Obtiene' and resource 'conversaciones mas recientes' align with the name. However, it does not differentiate from sibling tools like search_conversations or get_conversations_by_agent.
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 lacks any guidance on when to use this tool versus alternatives. No mention of prerequisites, context, or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds minimal behavioral context beyond the tool's primary function. It does not disclose whether the operation is read-only, what the output looks like, if pagination is handled, or any rate limits. The description relies entirely on the input schema without enriching agent understanding.
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 a single sentence and relatively concise, but it contains an unnecessary placeholder '[query]' that undermines clarity. The purpose is front-loaded but the formatting is slightly awkward due to the mixed language and placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters and no output schema, the description provides the essential purpose. However, given the large number of sibling tools, more context about the output format (e.g., message structure) or read-only nature would improve completeness. Without output schema, the agent lacks guidance on what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with clear examples and constraints (phone format, limit range). The description introduces the ambiguous term '[query]' which does not align with the parameter named 'phone', potentially confusing the agent. It adds no additional semantic value and may actually mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Ver historial de conversacion WhatsApp' / 'Muestra el historial de mensajes de WhatsApp') and the resource (WhatsApp conversation history with a specific phone). It distinguishes the tool from generic conversation retrieval tools by specifying 'WhatsApp' and 'phone'. However, the inclusion of '[query]' in the description is slightly confusing as it does not correspond to any parameter in the input schema.
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 'get_conversation_detail', 'get_whatsapp_message_logs', or 'search_conversations'. It does not state prerequisites, when not to use, or any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only adds '[mutation]', which does not disclose behavioral traits like idempotency, overwrite behavior, error handling, or required permissions. This leaves the agent uninformed about important 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line) and lacks structure. While concise, it could benefit from a more structured format explaining behavior and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and minimal description. For a mutation tool that imports data, the description should include return value, error handling, prerequisites, and file size limits. This is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 3 parameters with descriptions, achieving 100% schema coverage. The description adds no additional meaning beyond the schema, such as file format expectations or the effect of defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'importar' and the resource 'contactos al CRM interno desde un archivo CSV', which is specific and distinguishes it from other import tools (e.g., import_contacts_csv, import_contacts_from_crm).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., import_contacts_csv, import_contacts_from_crm). The label '[mutation]' implies side effects, but there are no statements about prerequisites, file size limits, or error handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only includes a [mutation] tag but does not disclose side effects, permissions needed, or what happens if a calendar is already linked. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a mutation tag, front-loaded with key information. No unnecessary words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with 3 parameters and no output schema, the description lacks important context such as that an OAuth connection must already exist, and what 'linking' entails for the store. It is incomplete for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 basic descriptions. The description adds that external calendars are from Google/Microsoft, which provides slight context, but overall it does not enhance understanding 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 clearly states the verb 'Vincular' (link) and the resource: external calendar (Google/Microsoft) to the store. It distinguishes from siblings like 'list_oauth_calendars' and 'delete_calendar_connection', though it could be more specific about prerequisites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The [mutation] tag is present but doesn't qualify as usage guidance.
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?
With no annotations, the description bears full responsibility for behavioral transparency. It discloses that notes are visible only to agents, but does not explain what the optional parameters do (e.g., are they filters or outputs?), the return format, or any access restrictions. The trailing '[query]' is unexplained and may confuse.
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 brief but contains redundancy: 'Listar notas internas de un hilo de email' and 'Obtiene las notas internas de un hilo de email' say the same thing. The '[query]' suffix appears to be a leftover and adds no value. It could be more concise and remove clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of five parameters, the description lacks completeness. It doesn't explain what the tool returns (e.g., a list of note objects with which fields), how optional parameters affect the output, or any pagination. For a data retrieval tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds no additional meaning to the parameters—it merely states the tool lists notes. The schema descriptions are minimal, but the description does not compensate or clarify 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?
The description clearly states the tool lists internal notes of an email thread and distinguishes notes as visible only to agents. The verb 'listar' and resource 'notas internas de un hilo de email' are specific. While it doesn't explicitly differentiate from sibling list tools, the context of notes vs threads or other entities 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?
No guidance is provided on when to use this tool versus alternatives like add_email_note or delete_email_note. The description does not mention prerequisites, complementary tools, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose side effects (e.g., whether it sends test emails or only checks ports), return format, or failure behavior. No annotations exist to mitigate this gap, so the description carries full burden and falls short.
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 very short but includes an unexplained '[query]' suffix that detracts from clarity. It lacks structured formatting and uses a single sentence, which is not ideal for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 required parameters and no output schema, the description should explain return values or success criteria. It does not cover what 'funciona correctamente' entails (e.g., boolean, error messages), leaving agents underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 10 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds no additional meaning beyond the schema, such as constraints or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it tests email IMAP and SMTP connections. It distinguishes from sibling test tools (e.g., test_crm_endpoint, test_ecommerce_connection) by focusing on email. However, it could be more specific about the tool's exact scope (e.g., only validates connectivity, not sending).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_email_account or other test tools. There is no indication of prerequisites (e.g., account existence) 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?
No annotations are present, so the description must carry full behavioral burden. It only notes [mutation] indicating write operation, but fails to disclose idempotency, error handling, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short description (one sentence) for a tool with 8 parameters. It is under-specified relative to tool complexity, missing parameter context and usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description should provide more context. It lacks information on return values, required permissions, or typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3 applies. The description adds no additional meaning or examples beyond the schema parameter descriptions, which are already detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing availability rule using verb 'Actualizar' and resource 'regla de disponibilidad existente'. It distinguishes from create/delete siblings by specifying 'existente'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus create_availability or delete_availability. There are no prerequisites, context, or exclusions 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?
With no annotations, the description carries full burden. It only indicates [mutation] but fails to disclose side effects like whether tags are appended or replaced, or any other behavioral traits. The description lacks crucial details for an agent to understand impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but it mixes languages unnecessarily and lacks structure. It could be improved by front-loading the core action and adding concise details about behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, many of which (e.g., query, limit, agent_name) are not explained in the description. No output schema is provided. The description does not specify what the tool returns or how the extra parameters are used, making it incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema. While the schema itself is clear, the description does not explain the purpose of parameters like 'query' or 'limit', which seem unrelated to adding a tag.
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 (add a tag to a customer) and the purpose (classify). The verb and resource are specific. However, it does not distinguish this tool from siblings like auto_tag_customer or update_customer_tags, which could cause ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., customer must exist) or scenarios where this tool is inappropriate.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function (checking status) without revealing whether the tool is read-only, if it requires files to be already uploaded, or what the side effects or return format are. This is insufficient for an agent to fully understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one line) and front-loaded with the main purpose. However, it contains a stray placeholder '[query]' which is confusing and suggests incomplete editing. Additionally, the description is in Spanish while sibling tool names are in English, causing potential inconsistency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks important details such as what status values are possible, how to interpret the output, and any prerequisites. Given the simplicity of the tool (one parameter, no output schema), a more complete description should at least mention the nature of the status checks. The placeholder further undermines 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?
The input schema has one parameter with a description in the schema itself, resulting in 100% schema coverage. The description does not add any extra meaning beyond what the schema provides, but it also does not contradict or mislead. Thus, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool checks the processing status of Doc-QA files. The verb 'Verificar' (Check) and resource 'estado de archivos Doc-QA' are specific, making the purpose understandable. However, it does not differentiate from sibling tools like 'list_docqa_files' or 'get_docqa_detail', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, limitations, or contexts that would help an agent decide to use this tool over similar ones.
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?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. The tag '[mutation]' implies modification, but there is no information about side effects, required permissions, reversibility, or whether partial updates are allowed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line) and conveys the purpose quickly. However, it lacks structure (no headings, no separation of concerns) and does not provide any additional context beyond the bare minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about behavior, but it only offers a minimal purpose statement. For a mutation tool with 3 parameters, more details on usage constraints or outcomes are 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?
The input schema has 100% description coverage for its 3 parameters (id, content, category). The description restates that it edits content and category, adding no new meaning 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it edits content or category of a knowledge snippet ('Edita el contenido o categoria de un snippet de conocimiento'). The verb 'editar' and resource 'snippet de conocimiento' are specific. It distinguishes from sibling tools like delete_knowledge_snippet or create_knowledge_file, but does not explicitly mention that it modifies existing snippets.
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 usage guidance is provided. The description does not indicate when to use this tool versus other snippet-related tools (e.g., create_knowledge_snippet, delete_knowledge_snippet), nor does it 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states the basic action without mentioning whether it returns a file, stream, or JSON, nor any permissions, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but lacks structure or helpful front-loading. It does not waste words, but it could be more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and no output schema, the description is insufficient. It does not explain pagination, limit behavior, output format details, or how the query parameter works. More context is needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 well-documented there. The description mentions [query] but adds no meaningful semantics beyond the schema. Baseline score maintained.
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 exports conversations with all messages in structured format, which is a specific action. However, it does not differentiate from sibling tools like get_conversation_detail that also retrieve messages, but the export verb implies batch/download functionality.
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. With many sibling tools for retrieving or exporting conversation data, the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'export as CSV'. It does not state whether the export is non-destructive, how the file is returned (e.g., download link, direct data), or if there are limitations on data volume. This lack of transparency could lead to incorrect invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one line), but the inclusion of '[query]' at the end is unclear and may confuse the agent. It could be more structured by separating purpose from usage hints. It earns its place but lacks clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the output format and delivery method. It only says 'as CSV file' without specifying how the agent receives it (e.g., data URL, file path). Also, with many similar sibling tools, it lacks context to differentiate. The description feels incomplete for a data export operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions (100% coverage). The description does not add new meaning beyond the schema; it merely repeats the filtering intent. Baseline score 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'export', resource 'CRM contacts', and format 'CSV file'. It clearly indicates the tool's purpose. However, it does not differentiate from sibling export tools like 'gdpr_export_customer_data' or 'export_conversations', which could cause confusion. A slight deduction for lack of sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or which specific context this export is for. The agent must infer solely from the name and purpose, which is insufficient.
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?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, rate limits, or side effects. While a 'get' tool is likely safe, the description fails to confirm this, placing the full burden on the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not well-structured. It is a single sentence with a dash, and the trailing '[query]' appears misplaced, creating ambiguity. Every sentence should earn its place, and this one partially fails due to the unclear token.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should comprehensively explain the return value. It only lists a few metrics and does not clarify parameter interactions (e.g., how 'days' and 'period' relate). The tool likely returns a complex object, and the description is insufficient for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds some semantic value by naming specific metrics returned (assigned customers, tasks, completion rate), but also includes a confusing '[query]' token that does not correspond to any schema parameter, reducing clarity.
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 provides detailed agent performance metrics, listing examples like assigned customers, tasks, and completion rate. However, it does not differentiate from similar sibling tools like get_agent_stats or get_agent_activity, which may also provide performance data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name and description alone.
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?
With no annotations, the description should explicitly state that the tool is read-only and does not modify data. It only says 'list', which implies read but doesn't confirm. No disclosure of authentication needs, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) with a dash separator, but the '[query]' appears to be a placeholder or incomplete. While concise, the structure is slightly marred by this unclear token.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain ordering, pagination, and default behavior (e.g., what 'recent' means). It fails to fill these gaps. The presence of a sibling with a similar name further demands differentiation, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, so the bar is neutral. The tool description adds the context of 'recent sessions', but does not clarify parameter interactions or formats beyond what the schema already provides. Score at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists recent web chat sessions, specifying the resource (web chat widget sessions) and action (list). However, it does not differentiate from the sibling tool 'get_plugin_chat_sessions', which could cause confusion. The '[query]' placeholder is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_plugin_chat_sessions' or 'search_conversations'. It lacks context on prerequisites, scope (e.g., user or workspace filtering), or limitations.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the tool retrieves comments and tags, but says nothing about side effects, data sensitivity, rate limits, or whether it is read-only. This is insufficient for a tool with multiple parameters.
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 a single short sentence, which is concise but borderline under-specified. It lacks structure, such as separating purpose from usage details. For a tool with 9 parameters, more explanation would be warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema, no annotations), the description is incomplete. It does not cover return values, pagination behavior, or the role of the query parameter. The agent is left without key context for proper 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?
Input schema has 100% parameter description coverage, so the baseline is 3. The tool description adds no further meaning beyond the generic purpose, but does not contradict the schema. It provides no examples or explanation of parameter interactions, so it remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets comments and tags associated with a customer using a query. It specifies a verb (get) and resource (customer comments/tags), and distinguishes from sibling 'search_customer_comments' which implies searching rather than retrieving. However, it does not clarify if it retrieves all comments or supports filtering beyond the input schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_customer_comments or other get tools. The description does not mention prerequisites, context, or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the tool retrieves details and statistics, but does not mention permissions, side effects, error handling (e.g., invalid assistant_id), or data freshness. Read operation is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a redundant prefix 'Detalle de asistente Doc-QA' and a stray '[query]'. It could be more front-loaded and avoid the placeholder. Acceptable but not excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should explain what 'detalles completos' entails. It lacks information about response structure, required permissions, error cases, and whether it is a read-only operation. Incomplete for a simple get 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 parameter assistant_id described as 'ID del asistente Doc-QA'. The description adds 'detalles completos' and 'estadisticas' but does not enrich the parameter meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Obtiene' and resource 'asistente Doc-QA', indicating it retrieves full details including statistics. It distinguishes from sibling tools like get_docqa_stats and list_docqa_assistants. However, the stray '[query]' at the end creates minor confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_docqa_stats or list_docqa_assistants. The description implies usage for a single assistant's full details, but no when-not or alternative advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states what the tool returns (connection status and stats). It does not disclose behavioral traits such as whether it is a read-only operation, any destructive potential, authentication needs, or rate limits. With no annotations, the description bears full responsibility for transparency, and it falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line), but it front-loads the purpose. However, it lacks structure and detail. It could be considered under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 4 parameters, no output schema, and numerous sibling e-commerce tools, the description is incomplete. It does not explain the return format, the meaning of the stats, or how the parameters affect the output. The context of e-commerce integration is not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters are adequately documented in the schema itself. The tool description adds no extra meaning beyond what the schema provides (e.g., 'period' enum, 'days', 'date', 'phone'). The parenthetical '[query]' hints at a query parameter but is insufficient to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns e-commerce sync status, including connection status and CRM customer statistics. It uses specific verbs ('Estado de sincronizacion') and resource ('e-commerce'). However, it does not differentiate from sibling tools like 'test_ecommerce_connection' or 'get_shop_status', which may overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., requiring a connection to an e-commerce platform) or exclusions. The description lacks explicit usage context.
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?
No annotations provided, so the description must carry the burden of behavioral context. It only states what the tool returns but not how it behaves (e.g., data freshness, pagination, rate limits, or handling of missing data). Minimal disclosure.
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?
Very concise (one sentence), but includes a distracting '[query]' placeholder. Front-loaded with purpose, but lacks structure (e.g., no separation of input/output). Could be improved with clearer formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description is too brief. It does not explain the return format or how parameters affect results. For a stats tool with many siblings, more detail is needed for complete 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 coverage is 75% with descriptions for date, days, and phone. The description adds no extra meaning beyond schema. Period has an enum but no description in schema; description does not clarify its role. 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?
Description clearly states it provides 'Statistics by period' with 'daily evolution of conversations and messages'. This identifies the verb (get) and resource (period stats). However, it does not differentiate from sibling tools like get_conversation_analytics or get_analytics, which may overlap.
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., get_analytics, get_conversation_analytics). No mention of prerequisites or context for use. The description is purely declarative.
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?
With no annotations provided, the description bears full responsibility for disclosing behavior. It states it shows questions and supports filters but does not mention whether pagination applies, how the [query] placeholder works, what happens with missing parameters, or if it is read-only. Essential behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an unexplained '[query]' placeholder that may confuse agents. It is front-loaded with the core purpose but the bracket suggests incomplete content. Every sentence should be self-contained and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters (0 required) and no output schema. The description does not explain the return format, pagination behavior, or how to effectively combine filters (e.g., date_from and date_to vs period). For a list-retrieval tool, this level of detail is insufficient for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions 'filtros por periodo de tiempo' which aligns with the period, date_from, and date_to parameters, but adds no additional semantic value beyond what the schema already provides. The description does not clarify interactions between parameters or usage semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (product questions) and action (view/list). It includes the relevant scope of supporting time period filters. However, it does not differentiate from sibling tools like 'get_product_qa_faqs' or 'get_product_qa_stats' which also deal with product Q&A but with different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only implies its use for viewing product questions with filters, but lacks instructions on when not to use it or mentions of related tools. Agents may not know when to pick this over other product Q&A tools.
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?
No annotations provided; the description does not disclose read-only nature, data freshness, or other behavioral traits, relying solely on the basic function.
Agents need to know what a tool does to the world before 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 a single, well-structured sentence with no redundancy, conveying purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the description lacks details on return format, sorting, or pagination, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%; the description only adds a mention of '[query]' without enriching parameter meaning beyond the schema, failing to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists top asked products from the Q&A plugin, but does not distinguish it from potentially similar sibling tools like get_product_qa_questions or get_product_qa_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; the description only implies usage for querying top products without exclusions or context.
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?
No annotations provided, so description must disclose behavioral traits. It does not mention safety (read-only), rate limits, data freshness, or authentication. Only states it 'shows' messages, but no side-effect or access 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?
Single sentence, concise, but overly brief. Lacks any structured breakdown of behavior. Front-loads the tool's purpose effectively but omits important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 optional parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return format, pagination, default behavior for missing parameters, or any usage constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 high (86%), so baseline is 3. The description adds no additional meaning beyond the parameter names and brief schema descriptions. It does not explain parameter interactions or hierarchy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves recent WhatsApp message logs (sent and received). However, it does not differentiate itself from similar sibling tools like get_whatsapp_conversation_history, which likely overlaps.
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 such as get_whatsapp_conversation_history. No mention of prerequisites, limitations, or appropriate contexts.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'muestra el estado' (shows status) without explaining read-only nature, permission requirements, or any side effects. This is insufficient for agents.
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 one sentence, which is concise, but it ends with a suspicious '[query]' that may be a placeholder. It lacks structure and does not front-load key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and the description does not explain what the status includes or any important context (e.g., refresh rate, aggregation level). Given the tool has multiple optional parameters, more detail 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 coverage is 100%, so the description does not need to explain parameters in detail. It adds no additional meaning beyond the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the status of all connected WhatsApp sessions. However, it does not differentiate from sibling tools like get_whatsapp_connection_status or get_whatsapp_health, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description fails to mention specific use cases or conditions 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool retrieves statistics but does not confirm read-only behavior, required permissions, or potential side effects. The response format or limits are not described.
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 a single sentence with a dash separator, listing some metrics. It is concise but includes the ambiguous '[query]' placeholder, which undermines clarity. Front-loading is adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description should fully describe the return value. It lists a few metrics but is incomplete (e.g., does not mention all possible fields or the structure of the response). The '[query]' addition is confusing.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (session_id is documented in the schema). The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets workflow statistics for a specific WhatsApp session, listing specific metrics (today's messages, executions, 7-day volume). It distinguishes the tool from siblings by specifying 'session' and 'WhatsApp', but does not explicitly differentiate from similar tools like 'get_whatsapp_workflow_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or scenarios where this tool is appropriate, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states basic listing and filtering, without mentioning pagination, rate limits, permissions, or default behavior when no filters are applied.
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 a single sentence in Spanish but contains redundancy ('Listar eventos de calendario — Lista eventos del calendario'). It is short but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no required parameters, and no output schema, the description is insufficient. It does not explain how filters combine (AND/OR), the output format, or any constraints like maximum date range.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 each parameter already has a description in the schema. The tool description adds no additional meaning or examples beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists calendar events for a date range with filtering by agent or phone. However, it does not differentiate from the sibling tool 'list_calendar_events', missing an opportunity to clarify the unique aspect of this variant.
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 'list_calendar_events' or other filtering tools. The description lacks context on 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?
With no annotations, the description must disclose behavioral traits. It only mentions 'obtiene todas' (gets all), but fails to clarify if this is a read-only operation, whether pagination exists, or if there are any side effects. The agent is left to assume it is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes the unclear '[query]' artifact, which harms conciseness. It could be trimmed to the first sentence without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what the tool returns (e.g., list of campaign objects, their fields). It only says it 'gets' campaigns. Given the many sibling campaign tools, more detail is needed for the agent to understand 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 input schema has no parameters (empty object), so schema coverage is 100%. However, the description introduces the unclear '[query]' which does not match the schema, potentially confusing the agent. Otherwise, no parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists all marketing campaigns, distinguishing it from siblings like get_campaign (single campaign) and create/delete/update. However, the trailing '[query]' is ambiguous and 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_campaign for a specific campaign). The description implies it returns all campaigns, but no context about filtering or opting for other list tools.
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?
No annotations are provided, so the description must disclose all behavioral traits. It states it gets all lists but does not mention pagination, filtering capabilities, or any potential side effects. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence and a fragment) but contains an unclear '[query]' placeholder. It is concise but sacrifices clarity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description is insufficient. It omits information about pagination, result format, and how the 'search' parameter works. More context is needed for effective 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 schema already documents both parameters. The description adds no additional meaning beyond stating the resource; it does not explain 'page' or 'search' 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?
The description clearly states the verb 'Listar' and resource 'listas de contactos de marketing masivo', specifying the scope as 'de la tienda'. This differentiates it from other list tools like 'list_agents' or 'list_campaigns'. However, the trailing '[query]' is confusing and slightly detracts from clarity.
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. There is no mention of prerequisites, scenarios, or exclusion conditions. Siblings like 'get_contact_list_detail' exist but are not referenced.
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?
With no annotations, the description bears full burden. It indicates a read operation but does not disclose behavioral traits such as whether it returns all files or paginated results, what file types are included, or if it requires specific permissions. The pagination implied by limit/offset is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and uses a dash for structure, but it sacrifices completeness for brevity. While not verbose, it lacks important details like pagination and file scope, making it insufficient for an agent to use reliably.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description does not explain what 'archivos' means (e.g., file types, metadata), how to interpret the response, or how the query parameter works. For a list tool, more context is needed to avoid confusion with similar list tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (phone and offset have descriptions). The description adds minimal value by linking 'query' to the phone parameter, but it does not explain limit or offset beyond what the schema provides. Since limit lacks a description, the tool description should cover it but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists files shared in a conversation with a client, using the Spanish verb 'Lista' and specifying the resource 'archivos compartidos en una conversacion'. It also includes '[query]' hinting at filtering by phone. While it distinguishes from sibling tools like delete_conversation_file and download_conversation_file, it could explicitly state that it returns a list of file metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_storage_files, list_knowledge_files, etc. The description does not mention prerequisites, common use cases, or when not to use it. An agent would have to infer from the name and parameters.
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?
With no annotations, the description must convey behavioral traits. It only states it 'shows drafts pending sending' but omits permissions, response format, pagination behavior, or any other operational details. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line) but includes a distracting '[query]' placeholder. It could be more structured without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, the description should provide more context about parameter usage, response structure, or filtering behavior. It fails to fill gaps left by the schema, leaving the agent with insufficient 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?
Input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no extra meaning beyond the schema; it merely restates the purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists email drafts pending sending, providing a specific verb and resource. However, it does not differentiate from sibling tools like list_email_threads or list_email_accounts, and the '[query]' placeholder is confusing.
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. It only describes the action without context or exclusions, leaving the agent to infer usage without any decision support.
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?
With no annotations, the description should explicitly state behavioral traits like read-only, auth requirements, or side effects. It only says 'list', implying no mutation, but does not confirm other behaviors like data scope or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes redundant language (Spanish and English). While concise, the dash separation feels messy, and the structure is not fully optimized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters and no output schema, the description fails to clarify return format, field meanings (e.g., 'configuracion' and 'estado'), or how filters interact. It is incomplete for a data-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%, so parameters are well-documented there. The description does not add any extra meaning beyond what the schema provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists installed plugins with their configuration and status, using the verb 'list' and specifying the resource 'plugins'. It is distinguishable from other list tools like list_agents or list_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only mentions three filters (status, agent, phone) but the schema includes eight more (e.g., limit, offset, priority). It does not disclose reading behavior, pagination, or result ordering. The description oversimplifies the tool's capabilities.
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 a single line that is concise but omits critical details. The hyphen separation is clear, but the '[query]' suffix appears to be a placeholder and reduces clarity. It is not fully optimized for agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema (11 parameters) and no output schema, the description should cover essential aspects like pagination, default limit, and the purpose of less obvious parameters. It only highlights three filters, leaving agents uninformed about other options like due_date, priority, and include_completed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 91% schema description coverage, the schema already documents parameters well. The description only lists three filters, adding minimal new meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists tasks with optional filters by status, agent, or phone. The verb 'listar' is specific to listing, and the resource 'tasks' is distinct from many sibling tools. However, the appended '[query]' is ambiguous and may confuse agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_conversations or list_agents. No mention of when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only indicates the tool is a mutation via the '[mutation]' tag. No annotations are provided, and the description does not disclose behavioral traits such as idempotency, permission requirements, side effects, or whether existing configuration is overwritten. Without annotations, the description should provide more context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Guardar configuracion de marketing masivo' appears twice. The '[mutation]' tag is a useful structuring element. Overall, it is concise but could be tighter without repeating the resource name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks important context such as return values (e.g., success/error message) and whether the tool creates or updates the config. Given no output schema, the description should explain what the tool returns. The sibling 'get_mass_marketing_config' exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 well-documented in the schema. The tool description adds high-level categories (auto-response, translation, sending options) but does not provide additional meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves mass marketing configuration, listing specific categories (auto-response, translation, sending options). It uses the verb 'Guardar' and tags '[mutation]' to indicate a write operation. However, it does not explicitly distinguish from the sibling tool 'get_mass_marketing_config' or other save tools, though the resource is clearly different.
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 usage guidelines are provided. The description does not specify when to use this tool vs alternatives, prerequisites, or when not to use it. For example, it doesn't clarify whether this tool is for both creating and updating the config, or if it overwrites existing settings.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only tags the operation as [mutation], but does not disclose side effects, permission requirements, immediacy of updates, or whether partial updates are supported. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus a tag), which is efficient but lacks structure. It uses a dash to separate purpose and description, but no bullet points or formatting are used. It is adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description is too sparse. It does not explain the effect of each parameter, whether updates are partial or full, or how this tool fits into the lifecycle of calendar notifications (e.g., relationship to create and delete). The context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it only restates the action. It does not clarify parameter relationships, constraints, or usage tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Actualizar' (update) and the resource 'notificacion de calendario', and includes a [mutation] tag. It distinguishes from siblings like create_calendar_notification and delete_calendar_notification by the verb, but does not explicitly list what fields can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites, when not to use it, or any exclusions. It simply states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a '[mutation]' tag indicating it modifies state, but lacks details on side effects, idempotency, required permissions, or whether changes are reversible. Without annotations, this is insufficient for an agent to understand the tool's behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clear purpose, front-loaded with the main action. No extraneous information. Could benefit from slight expansion to cover usage context, but current length is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description omits crucial context: what happens upon success? Does it return a confirmation? Are there any side effects? For a mutation tool, this incomplete contextual information may lead to incorrect agent decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so baseline 3 applies. The description adds no parameter-level explanation beyond what the schema already provides (e.g., enum values, defaults). Agent behavior is adequately supported by the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it configures languages and URLs for the e-commerce platform, using a specific verb ('Configurar') and resource ('idiomas y URLs'). It distinguishes from sibling tools like 'connect_ecommerce' which focus on connection, not configuration. However, it could be more explicit about its unique scope among similar configuration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., requiring an active e-commerce connection) or scenarios to avoid. The description only implies its purpose, leaving agents to infer usage context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially conveys behavior via the [mutation] tag and rule type list, but it omits important details such as side effects, validation rules, or constraints (e.g., mutually exclusive parameters for different rule types).
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-loading the action and resource, and includes parenthetical rule types and a [mutation] tag. It could be more structured but avoids unnecessary clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is inadequate. It lacks details on return values, error handling, and how rule type affects required fields, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with brief descriptions. The tool description adds no further semantic value beyond the schema, failing to explain parameter relationships (e.g., day_of_week required for weekly, specific_date for date_exception). Baseline 3 is appropriate due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (availability rule in a calendar), listing rule types (weekly, date exception, blocked) to distinguish from sibling tools like create_calendar_event. However, it does not explicitly contrast with similar creation tools, preventing a perfect score.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives (e.g., update_calendar_availability, create_calendar_event), nor does it mention prerequisites like the need for an existing calendar.
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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It includes '[mutation]' to indicate state change, but lacks details on side effects, required permissions, error handling, or what happens on success. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with examples and mutation marker. Front-loaded with purpose and examples. Could be broken into separate points for clarity, but overall efficient and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and lack of annotations, the description is sparse. It does not explain the return value, creation behavior on duplicate names, or any additional context about calendar services vs events. The agent may be left wondering about the service lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds examples but no further meaning beyond the schema. It does not explain parameter relationships or constraints (e.g., buffer vs duration logic).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a calendar service/appointment type, with examples (e.g., consulta 30min). The verb 'Crear' and resource 'servicio de calendario' distinguish it from related tools like create_calendar_event or update_calendar_service, though the concept of 'service' could be further clarified.
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 create_calendar_event or update_calendar_service. Missing prerequisites (e.g., calendar must exist) or context about when creating a service is appropriate. The sibling list includes many calendar-related tools but the description offers no differentiation.
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?
No annotations are provided, and the description only marks the tool as [mutation]. It does not disclose side effects (e.g., duplicate handling, required permissions, or system impact). The description adds minimal behavioral insight beyond the mutation hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise, but could be more informative within the same space, e.g., by including the scope (individual vs bulk). Minor improvement possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling tools, the description lacks context about what this tool produces (e.g., does it just create a CRM entry? Is there any return value?). It does not explain 'CRM interno de WAzion' or confirm if it's a single contact addition. Incomplete for the environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the single parameter (whatsapp_number) with format details. The description adds no extra meaning or usage nuance beyond 'creates a new contact', so it meets the baseline but does not exceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new CRM contact in the internal WAzion CRM. It uses a specific verb ('Crear') and resource ('contacto CRM'). However, it does not differentiate from siblings like import_crm_contacts or add_contacts_to_list, preventing a top score.
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 import_crm_contacts or create_contact_list. No prerequisites, exclusions, or context are given, leaving the agent to guess the appropriate scenario.
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?
No annotations are provided, so the description carries full responsibility. It marks the tool as a mutation with '[mutation]', but does not disclose any behavioral traits such as required permissions, idempotency, side effects (e.g., duplicate names), or rate limits. The only behavior mentioned is that file uploads happen later, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single sentence and a mutation tag. The purpose is front-loaded ('Crear asistente Doc Q&A'). However, it could be more structured by separating the creation action from the follow-up note about uploading files.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters and no output schema. The description does not mention what the tool returns (e.g., the assistant ID or status). Given the complexity and the presence of many sibling tools, the description should provide more context about the creation process and expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no meaning beyond the schema; it does not explain why certain parameters are important or how they affect behavior. For example, it does not mention that 'display_name' is required or that 'prompt' is optional. No added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Crear') and the resource ('asistente Doc Q&A'). It distinguishes from siblings like update_docqa_assistant and delete_docqa_assistant by focusing on creation. However, it does not explicitly contrast with other create tools like create_agent or create_calendar_event, so sibling differentiation is lacking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only mentions the creation action and a post-creation step (uploading files), but does not explain prerequisites, use cases, or when to avoid it. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates mutation via the '[mutation]' tag but does not disclose side effects (e.g., whether contacts are removed or if the list is static/dynamic), required permissions, or data limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a mutation tag, which is concise and to the point. No unnecessary words, though a slightly more structured format could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain the outcome more thoroughly. It fails to specify what the resulting list contains (e.g., all inactive contacts or a snapshot), whether it's static or dynamic, and if any data is altered.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds minimal meaning beyond the schema. The description's reference to 'periodo determinado' loosely maps to the 'days' parameter, but no additional context or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new list from inactive clients based on a period of no conversation. The verb 'creates' and resource 'clientes inactivos' are specific. However, it does not explicitly differentiate from sibling tools like create_list_from_followup, which also creates specialized lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_contact_list or create_list_from_followup. The description implies usage for inactive clients but lacks explicit conditions, exclusions, or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. The '[mutation]' tag hints at a write operation, but there is no mention of consequences (e.g., irreversible deletion, required permissions) beyond the basic delete action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with key action and resource. It is concise but could be slightly improved by including one more sentence on usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature (single required parameter, no output schema), the description should at least mention that this action is permanent or requires specific permissions. It lacks such completeness, making it less helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'id' as 'ID of the correction to delete'. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete AI Correction' with verb 'Delete' and resource 'AI Correction', making the purpose unambiguous. However, it does not differentiate from the sibling 'delete_customer_ai_error' which also deletes a similar resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'update_ai_error' or 'delete_customer_ai_error'. The description does not mention prerequisites or context for deletion.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the tool returns a download URL but does not disclose potential side effects (e.g., URL expiration, permissions required, error handling) or what happens if the file does not exist. For a tool that likely triggers a network request, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but lacks structure such as bullet points or explicit sections. While it is front-loaded with the action, it may be too brief to convey all necessary information, especially since it is the only source of context beyond the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It tells the agent that the tool gets a download URL for a knowledge file. However, it does not clarify the response format, any constraints (e.g., file size, access restrictions), or how it compares to other download tools in the same server, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (id) with a description ('ID del archivo de conocimiento'), achieving 100% schema coverage. The tool description adds no additional meaning beyond confirming it's a knowledge file. Baseline score of 3 is appropriate as the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (descargar/download) and resource (archivo de conocimiento/knowledge file), and specifies that the tool obtains a download URL. However, it does not differentiate from similar sibling tools like download_conversation_file or download_email_attachment, limiting its distinctiveness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., list_knowledge_files, download_conversation_file). There is no mention of prerequisites, context, or situations where this tool is appropriate or inappropriate, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes '[mutation]' indicating state changes, but with no annotations, it fails to disclose side effects, prerequisites, or reversibility. Actions like 'delete' likely have destructive consequences, yet nothing is mentioned. The behavioral disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and lists the actions. Every word is informative, and there is no redundancy or extraneous content. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the multi-action nature and lack of annotations/output schema, the description is incomplete. It does not explain side effects (e.g., delete is irreversible), required permissions, or the meaning of the return value. The agent lacks sufficient context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 explicitly listing all possible action values, which is not captured in an enum. However, it does not clarify parameter constraints or relationships beyond what the schema provides, so the added value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes an action on an email thread and lists the supported actions (archive, delete, spam, etc.). However, it does not differentiate from sibling tools like snooze_email_thread or assign_email_thread, which perform the same specific actions, leading to potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this generic action tool versus more specific sibling tools (e.g., snooze_email_thread, assign_email_thread). The agent receives no context to choose between them, which is a significant gap.
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?
With no annotations, the description carries the full burden. It only states it shows activity and workload, lacking details on behavioral traits like response format, rate limits, or what 'actividad' entails.
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 (one sentence) and front-loaded with the core purpose. It is concise, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain what 'activity' includes, how period and days interact, or the scope of results, leaving ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (each parameter has a basic description), so baseline is 3. The tool description adds no extra meaning to parameters beyond the schema, which is acceptable but not improved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows activity and workload of a specific agent, matching the tool name. However, it does not differentiate from sibling tools like get_agent_performance or get_agent_stats, which could 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, 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?
No annotations provided, and the description does not disclose behavioral traits like side effects, permissions, or data mutability. It only lists metric categories, failing to inform the agent of important constraints.
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 a single line with a clear structure (dash separator) and includes both Spanish and English terms. It is concise but could be more structured with a list.
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 no output schema and 3 parameters, the description covers metric categories but is vague about output format and does not address the [query] suffix. Lacks completeness for a customizable stats 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 schema has 67% description coverage for 3 params. The description adds limited value beyond the schema by listing metric types, but does not elaborate on parameter meanings or usage beyond the existing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets agent statistics with performance metrics like messages sent/received and tasks completed. It distinguishes from siblings like get_agent_activity or get_agent_performance by focusing on stats.
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 such as get_agent_performance or get_agent_tasks. The description only states what it does without context.
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?
No annotations provided; the description does not disclose behavioral aspects like caching, rate limits, data aggregation scope, or whether the data is real-time. The mention of '[query]' in the description is ambiguous and not reflected in the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line) and front-loaded with the purpose. It avoids unnecessary detail and is efficiently structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and no output schema, the description is minimally complete but lacks details on output format, pagination, or how this tool differs from other analytics endpoints. It does not fully equip 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the 'period' parameter. The description adds no additional parameter meaning beyond the schema, but the schema itself is sufficient, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves analytics showing conversations, messages, and daily activity. It specifies the resource and verb, but does not clearly differentiate from similar sibling tools like get_conversation_analytics or get_period_stats.
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 such as get_conversation_analytics or get_structured_analytics. No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that it retrieves statistics, omitting details about potential side effects, authentication needs, rate limits, or what happens when no data is available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and lists example statistics. It avoids unnecessary words but could be better structured with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about return format, time range, or scope. It lists examples but is incomplete for an agent to fully understand what it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters, so the description does not need to explain them. However, the description includes '[query]' which suggests a query parameter that does not exist in the schema, potentially misleading. With zero parameters, baseline is 4, but this confusion reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed statistics about the auto-learning system, listing examples like active, pending, and rejected snippets. It distinguishes from siblings by focusing on 'auto-learning' but does not explicitly differentiate from the similar 'get_autolearning_metrics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_autolearning_metrics'. There is no mention of prerequisites, scope, 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?
With no annotations, the description must fully disclose behavior. It only says 'analiza' (analyzes) and doesn't state if read-only, side effects, or performance impact. Minimal behavioral 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?
Very concise, one sentence with clear title. Could benefit from structured format like bullets, but no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description doesn't explain return format (e.g., list of hours with counts). For an analytics tool, output details are important.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is described in the schema. The description adds no additional meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes peak hours for customer messages, with a specific verb and resource. While distinct from siblings like get_analytics, it lacks explicit differentiation from other analytics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives. Does not mention context, 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?
No annotations are present, so the description must fully disclose behavioral traits. It only states that the tool 'shows usage statistics' without mentioning read-only status, authentication needs, rate limits, or what happens when no data is available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the purpose, but it mixes Spanish text with an English tool name and includes an extraneous [query] marker. The structure could be improved for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description should fully explain the returned data format and scope. It lists some stats but omits whether results are totals, time-bound, or how to interpret them. The lack of output schema means the description should compensate, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 zero parameters and is 100% covered, so the baseline is 4. However, the description includes a stray [query] which falsely implies a parameter, reducing the score to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves usage statistics for the Chat Web plugin, listing specific metrics like conversations, messages, active sessions, referrers, and countries. However, it does not differentiate from siblings like get_plugin_stats or get_analytics, and the [query] suffix is confusing given no input parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_plugin_stats, get_analytics, or other plugin-specific stats tools. There is no mention of prerequisites or context for usage.
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?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the tool is read-only, required permissions, or any side effects. The mention of 'complete messages' and 'customer data' is vague, and pagination (via limit/offset) is not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with a dash, making it efficient and front-loaded with the verb and resource. However, the use of a dash and the unclear '[query]' slightly detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no output schema, and no annotations, the description is too brief. It does not explain the two alternative ways to identify a conversation (phone vs. conversation_id), the meaning of limit/offset for pagination, or the specific customer data fields returned. The tool requires more context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions 'customer data' but does not explain how parameters like phone and conversation_id serve as alternative identifiers, nor does it clarify the use of limit/offset for pagination.
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 'Show detail of conversation' and mentions showing complete messages and customer data. It identifies the tool's purpose, but the trailing '[query]' is ambiguous and the tool's scope relative to siblings like 'search_conversations' is not differentiated.
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 such as 'get_recent_conversations', 'get_conversation_analytics', or 'search_conversations'. The description merely implies use for fetching full conversation details but lacks any 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?
With no annotations, the description carries full burden. It only mentions showing conversations by agent, omitting details like pagination, ordering, or how the query parameter affects results. This lack of behavioral info is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly conveying its purpose. It is concise without unnecessary words, though the '[query]' placeholder is slightly unclear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters and no output schema, the description is too minimal. It does not explain how to use parameters like limit, offset, hours, or period, nor what the response contains. More context is needed for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 13 parameters, so the schema already documents each parameter. The description adds no meaningful extra info beyond the schema, keeping it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows conversations assigned to a specific agent, with the name reinforcing the purpose. However, it does not explicitly differentiate from sibling tools like search_conversations or get_recent_conversations, which may overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, such as search_conversations for text search or get_conversation_detail for a single conversation. The description lacks context on prerequisites or use cases.
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?
With no annotations provided, the description carries full transparency burden. It indicates a read operation but does not disclose whether the contact must exist, what happens if the number is not found, or if there are any side effects. Behavioral traits are minimally addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the core purpose. There is no extraneous content. However, it could be restructured to include brief usage notes without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single required parameter, no output schema), the description provides adequate context for a basic lookup. However, it omits what data is returned (e.g., which contact fields), which would help an agent understand the output. With no output schema, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the sole parameter 'whatsapp_number' is described). The description adds context that the number is WhatsApp and ties to internal CRM, but this largely echoes the schema's description. It does not provide additional details like format, validation, or expected input constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Obtiene los datos de un contacto del CRM interno' (gets data of a contact from internal CRM) and specifies the query method 'por su numero de WhatsApp'. This distinguishes it as a lookup tool for internal CRM contacts by WhatsApp number, though it does not explicitly differentiate from siblings like 'get_customer_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'search_customers' or 'get_customer_info'. The description does not mention prerequisites, limitations, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a 'complete summary' but does not disclose any behavioral traits such as whether it is a read-only operation, what data scope it covers (e.g., all users or workspace-wide), or if there are any side effects like affecting usage counters.
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-loads the main purpose. However, being a single line in Spanish with a trailing '[query]' (possibly stray), it could be more structured and professional. It is concise but at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the output contains and any limitations. It lists categories but does not explain how the parameters interact (e.g., what happens when both date and period are provided), nor does it mention pagination or data freshness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters adequately. The description adds no additional meaning beyond the schema, which is acceptable but does not enhance understanding. The description also mentions '[query]' which might refer to a query parameter not in schema, causing confusion.
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 provides a daily summary of activity including conversations, messages, plugins, workflows, follow-ups, and tasks. It identifies the specific resource and scope, but does not explicitly distinguish it from sibling summary tools like get_team_summary or get_conversations_summary, which could 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 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 versus alternative summary tools. There is no mention of prerequisites, typical use cases, or exclusions. The agent has no context to choose this over related get_* tools.
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?
No annotations provided. Description only states 'gets history' without disclosing pagination, data freshness, rate limits, or side effects. Agent cannot assess safety or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and to the point. No unnecessary words. However, it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description fails to explain return format, pagination behavior, or filtering interaction. Incomplete for agent to invoke correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 7 parameters have descriptions in the input schema (100% coverage). 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the question history for a Doc-QA assistant. Differentiates from siblings like get_docqa_detail and get_docqa_stats, but could explicitly mention the scope (e.g., paginated list).
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., get_docqa_stats). Does not mention prerequisites or scenarios for filtering.
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?
No annotations are provided, so the description must carry the burden. It only states the return value (retention period) but does not disclose any behavioral traits such as side effects, authentication requirements, or data freshness. The description is insufficient for an agent to fully understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an unexplained tag '[query]' that may not add value. It is generally concise, but the tag could be seen as noise. Every sentence should earn its place; the tag does not clearly contribute.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description is minimally sufficient but lacks details about the return format (e.g., units, structure). It does not explain what the 'retention period' looks like. Given the simplicity, a score of 3 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?
The input schema has 100% coverage with a clear description for the single parameter ('id'). The description adds no further meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: viewing the email retention period. It specifies the resource (store emails) and returns the configured period. It distinguishes from sibling tools by using a verb ('get') and specifying the subject ('email retention'), but does not explicitly differentiate from other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, contexts, or when not to use it, leaving the agent without clear direction.
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?
With no annotations, the description must disclose behavior. It lists output categories but omits critical details: read-only nature, rate limits, permission requirements, pagination, or query parameter usage. The '[query]' tag is unexplained.
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 a single line but effectively uses a dash-separated list. However, the '[query]' suffix is ambiguous and adds confusion. Could be restructured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (2 optional params, no output schema), the description covers the main statistics categories. However, it lacks behavioral context and does not address return format or potential limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters. The description adds no further meaning beyond the schema, so baseline score of 3 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 lists the types of statistics provided (campaign performance, failure breakdown, hourly distribution, list quality, credit balance), making the tool's purpose specific. However, it lacks a explicit verb like 'Retrieve' and does not contrast with siblings.
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_campaign_logs or get_marketing_sessions. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose key behaviors such as default exclusion of completed tasks, pagination limits, ordering, or permission requirements. The 'pending' keyword is present, but the include_completed parameter suggests completed tasks can be included, which is not clarified. With no annotations, the description fails to fully convey 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 very short (one sentence) and front-loaded with the core function. However, the '[query]' suffix detracts from clarity without adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high number of parameters (11), absence of output schema, and many sibling tools, the description is insufficient. It lacks guidance on parameter usage, default behavior, and response 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?
Schema coverage is 100%, so baseline is 3. The description adds minimal semantic value beyond the schema; the '[query]' tag is confusing as no 'query' parameter exists. It does not explain how parameters relate to the filtering logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves overdue tasks with the phrase 'Muestra todas las tareas pendientes cuya fecha limite ya paso'. This distinguishes it from sibling tools like list_tasks (which likely lists all tasks) and get_agent_tasks. However, the trailing '[query]' is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives among the many task-related siblings (e.g., list_tasks, get_agent_tasks). There is no mention of excluded contexts or conditions.
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?
No annotations provided, so description bears full burden. It mentions filtering by time period but does not disclose pagination, limits, ordering, or whether it's read-only. The summary is too brief for 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short at two sentences, which is efficient. However, it omits necessary details for completeness, making it slightly under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and many siblings, the description is too brief. It does not explain return structure, pagination behavior, or how it differs from similar list tools. The trailing '[query]' is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 5 parameters with descriptions, achieving 100% coverage. The description adds minimal value by summarizing 'supports time period filters', but does not elaborate on syntax or edge cases, meeting baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows plugin conversations from web chat with time period filters, but does not differentiate from siblings like get_plugin_chat_sessions or get_chat_sessions. The verb 'Ver' and resource 'conversaciones del plugin' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. The description only states what it does, with no when/when-not or sibling differentiation. Siblings like get_plugin_chat_sessions and get_conversation_detail also list conversations.
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?
No annotations are present, and the description does not disclose behavioral traits such as whether the tool is read-only, response format, pagination, rate limits, or any side effects. For a read-like operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose, and includes a specific example of metrics. It could be more concise by removing redundancy (e.g., 'Estadisticas de plugins' and 'Metricas del plugin...') but overall is brief and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 optional parameters, the description lists example metrics but does not specify return structure, aggregation level, or whether results are filtered by plugin_type. It is adequate for a simple stats tool but leaves ambiguity about 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 description does not elaborate on parameters beyond what is in the schema. The schema already covers 75% of parameters with descriptions. The description adds value by narrowing the tool's context to Product Q&A, but does not explain parameter usage or format.
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 specifies the tool retrieves statistics for the Product Q&A plugin, listing specific metrics (questions, visitors, most consulted products) and including a [query] hint. However, it does not explicitly differentiate from sibling stats tools like get_product_qa_stats or get_chat_plugin_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites, exclusions, or context about the data source. The description only states what it does, not usage conditions.
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?
No annotations are provided, and the description does not explicitly state that the tool is read-only or whether it has any side effects. While 'get' implies reading, the description should disclose behavioral traits more clearly, especially since annotations are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the key purpose. It could be slightly more structured by separating the requirement mention, but overall it is efficient and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no output schema, the description lists some return values but not in a structured way. It lacks details on how structured outputs are formatted or what exact fields are included, leaving some ambiguity for 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%, so parameters are already well-documented in the schema. The description adds context about what the parameters relate to (e.g., 'conversaciones recientes' for limit), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it obtains detailed analytics using structured outputs, listing specific components like KPIs, intention distribution, sentiment, etc. The name is self-explanatory, but it does not explicitly differentiate from siblings like get_analytics or get_conversation_analytics.
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 mentions that structured outputs must be activated, but gives no guidance on when to use this tool over other analytics tools. With many sibling tools offering similar functionality, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies it returns all agents ('todos los agentes'), but the schema includes an optional agent_id filter for a single agent, creating a mismatch. No disclosure of data freshness, pagination, or performance implications. Without annotations, the description carries the full burden and fails to clarify 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 a single line with a title-body structure (dash separated) and the query hint. No redundant words, but the inclusion of '[query]' is slightly unclear. Efficient for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 optional parameters, no output schema, and many sibling tools, the description is too sparse. It does not specify the structure of the summary, how filtering works, or what to expect in the response, leaving the agent with incomplete 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 descriptions cover 100% of parameters, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain how filtering by agent_id affects the summary or how period and days are used together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Resumen del equipo — Vista general de todos los agentes con su carga de trabajo actual', clearly indicating it provides a team summary with agent workload. This distinguishes it from individual agent tools like get_agent_stats, though it could be more precise about verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Siblings like get_agent_stats or get_agent_activity exist, but the description does not mention when to prefer this team overview over individual agent queries.
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?
No annotations are provided. The description merely restates the tool's output without disclosing behavioral traits such as read-only nature, data modification potential, or authorization requirements. The placeholder '[query]' adds confusion rather than 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 very concise, consisting of a single sentence. It is front-loaded and efficient, but the placeholder '[query]' is ambiguous and could be considered noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters and no output schema, the description is too brief. It does not explain return format, pagination, or what 'top' means. The inclusion of '[query]' without schema support leaves the agent uncertain about input requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The tool description adds minimal context by mentioning 'temas/intenciones' but does not elaborate on how parameters influence results. 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 Spanish description states it shows the most common topics/intents in conversations. Verb is clear and resource is specific. However, the inclusion of '[query]' is confusing and does not correspond to any parameter in the schema, slightly diminishing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions. It is a minimal phrase without any comparative information.
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?
With no annotations, the description carries full burden but only states the tool 'obtiene la lista'. It does not disclose behavioral traits such as read-only nature, pagination behavior, rate limits, or whether it clears filters. The schema's 'page' parameter implies pagination, but the description does not confirm this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose ('Ver contactos dados de baja'). It is efficient with no wasted words, though it could benefit from breaking into two sentences for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It does not mention pagination, date filtering, or result format. For a list tool with many siblings, more contextual guidance is needed to fully inform the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. Each parameter is already documented in the schema, so the description does not compensate or enrich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of contacts who have unsubscribed from mass mailings, using a specific verb ('Obtiene') and resource ('contactos dados de baja'). It distinguishes from sibling tools like 'list_whatsapp_optout' by specifying the context of mass mailings, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'list_whatsapp_optout' for WhatsApp opt-outs) or when not to use it. It implies usage for viewing unsubscribed contacts but lacks explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It omits details like how 'query' parameter works, pagination, or whether data is mutable. The brief description does not reveal important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. The use of Spanish may slightly hinder English-speaking agents, but it effectively conveys the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 5 parameters, the description is incomplete. It does not explain default behavior, the 'query' bracket, pagination, or how it compares to similar tools, leaving 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 coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; the action parameter's values ('summary', 'detail') are already documented in the schema.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows credits, tokens, and costs for recent days, matching the name. However, it does not explicitly differentiate from sibling tools like get_usage_stats_detail, which may offer more granular data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_usage_stats_detail or get_credit_history. There is no indication of 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool shows statistics but does not mention read-only nature, permission requirements, or potential side effects. The name implies a read operation, but explicit transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short clauses separated by an em dash. It quickly conveys the core function, though the placeholder '[query]' is confusing and could arguably reduce clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description should explain what statistics are returned, but it does not. It also fails to differentiate from numerous sibling workflow tools, leaving the agent with an incomplete picture of when and why to use this specific tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with descriptions for all four parameters. However, the tool description does not add extra meaning beyond what the schema already provides. The mention of 'periodo' loosely relates to the 'days' parameter, but no further enrichment is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool shows execution statistics of WhatsApp workflows within a time period ('Muestra estadísticas de ejecución de los workflows de WhatsApp en un periodo'). It uses specific verbs and identifies the resource, but it does not distinguish from similar sibling tools like get_whatsapp_workflow_logs or get_whatsapp_workflow_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites or typical scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Get' implying a read operation, but does not explicitly confirm it is read-only, describe any side effects, or mention authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a bullet list of metrics, making it concise and front-loaded. The inclusion of '[query]' is a minor distraction but does not significantly detract from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return format or structure. It does not. It also fails to clarify how period interacts with from/to parameters. A metrics tool like this typically needs output details for effective 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 coverage is 100% with clear descriptions for each parameter (e.g., period with allowed values and default). The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'WhatsApp message volume, workflow execution stats, peak hours, and performance metrics', which distinguishes it from siblings like get_whatsapp_workflow_activity that likely track individual actions. However, the terms are somewhat generic and the '[query]' at the end is confusing as no query parameter exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_whatsapp_workflow_activity or get_whatsapp_workflow_logs. The description does not mention prerequisites, typical use cases, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation ('Listar', 'Muestra todos') but lacks details on pagination, sorting, or returned fields. No mention of 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 a single sentence, efficiently conveying purpose. However, the unbracketed '[query]' is distracting and unnecessary, slightly diminishing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks important context such as the structure of the returned list, whether pagination is used, or any implicit constraints. It is too minimal for a complete 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?
No parameters exist, so schema coverage is 100%. The description adds no parameter meaning, but the extraneous '[query]' suggests a non-existent parameter, which is misleading. Baseline for 0 parameters is 4, but clarity is reduced.
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 ('Listar') and resource ('asistentes Doc Q&A'), and distinguishes from create/update/delete sibling tools. However, the inclusion of '[query]' implies a parameter that does not exist in the schema, causing slight ambiguity.
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 such as 'get_docqa_detail' or 'create_docqa_assistant'. The description does not mention context, 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?
No annotations provided, and the description only hints at a read operation ('Muestra la lista'). It does not disclose any behavioral traits such as side effects, rate limits, or authentication requirements.
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 at one sentence, but the inclusion of '[query]' is unclear and may be a placeholder, slightly reducing structure quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description adequately explains the purpose and output fields (size, date), but the ambiguous '[query]' and lack of pagination details make it somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the one parameter (limit) with coverage. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists storage files uploaded to the knowledge base, showing size and date. However, it does not differentiate from sibling tools like list_knowledge_files, leading to potential ambiguity.
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 list_knowledge_files or list_docqa_files. The description lacks any usage context 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?
No annotations are provided, so the description must disclose behavioral traits. It states the tool 'shows' templates, implying a read-only operation, but gives no details about pagination, permissions, or side effects. For a list tool, the lack of information about returned data structure or limits is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded with the main action. However, the inclusion of '[query]' is unclear and seems like a placeholder. The description could be more informative without adding length, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional filter, no output schema), the description is minimally adequate. It conveys the basic operation but does not specify return format or whether results are paginated. For a list tool, agents would benefit from knowing what fields are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (one parameter 'category' described as 'Filtrar por categoria de plantilla'). The description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate since the schema adequately documents the parameter.
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 'Listar plantillas de WhatsApp' (list WhatsApp templates) and adds 'Muestra las plantillas de mensajes guardadas' (shows saved message templates). The verb 'listar' and resource 'plantillas de WhatsApp' are specific. However, the trailing '[query]' is ambiguous and slightly detracts from clarity. It distinguishes from sibling tools like get_whatsapp_template (single) and delete_whatsapp_template.
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_whatsapp_template or list_whatsapp_workflows. No exclusions or context provided. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as a '[mutation]' but does not elaborate on side effects, error handling, or reversibility. Since no annotations are provided, the description carries the full burden but fails to disclose key behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose. It wastes no words, but the brevity sacrifices necessary details, especially about parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description lacks information on return values, success/error signals, and the role of extraneous parameters. It is incomplete for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 100% description coverage, the tool description does not explain why parameters like 'limit', 'offset', 'filter', and 'type' are present. These appear irrelevant to marking a single notification as read, and the description offers no clarification, potentially confusing the 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?
The description clearly states the action 'mark as read' and specifies it applies to a specific notification, distinguishing it from the sibling 'mark_all_notifications_read' which operates on all notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'mark_all_notifications_read' or 'mark_email_read'. There is no mention of prerequisites or exclusive usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only notes '[mutation]' to indicate state change, but no annotations are provided. It does not disclose side effects, required permissions, or what happens to associated 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 very concise (one line) and includes both the purpose and a mutation hint. It is front-loaded but could benefit from slightly more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 9 parameters and no output schema or annotations, the description lacks essential context about return values, error handling, and prerequisites, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so the description adds no extra meaning beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'remove tag from customer' and includes the Spanish equivalent. It specifies the verb and resource, and distinguishes from siblings like add_customer_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_customer_tags or add_customer_tag. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes the label '[mutation]' indicating data modification, but lacks details on side effects, required permissions, or potential errors. No annotations are provided to supplement this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence) and front-loads the core purpose. No unnecessary details, but could include more structured guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fails to mention return values, uniqueness constraints on template names, or whether the template is saved to a specific account. The tool is a creation operation but lacks completeness for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all three parameters, so baseline is 3. The description does not add extra semantic context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a message as a reusable WhatsApp template. However, it does not differentiate from the sibling tool 'create_whatsapp_template_from_workflow' which likely performs a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination behavior, rate limits, data scope, or output format. It only mentions search criteria, which is already implied by the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus an example) and front-loaded with the title and core action. No extraneous content, but could be more structured with explicit sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and no output schema, the description lacks completeness. It does not explain parameter interactions, default behaviors, or response structure, leaving significant gaps for an AI 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 all parameters described in the schema. The description adds an example but does not enrich parameter 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 clearly states the tool searches conversations by text, phone, or date range, with an example. It specifies the resource (conversations) and criteria, but does not explicitly differentiate from similar sibling tools like search_customer_comments or global_search.
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. The description provides only a usage example, lacking context for when to choose search_conversations over other search tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It labels the tool as '[mutation]' and says 'Activar/desactivar', but does not disclose side effects, required permissions, reversibility, or impact on existing messages. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short: two sentences, no fluff. Front-loads the action and object. However, it could be slightly more structured (e.g., separate purpose from scope). Remains appropriately sized for the tool's simplicity.
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 simple tool with one boolean param and no output schema, description covers basic functionality. But it lacks context: what setting is toggled (account-wide?), language of description (Spanish) may hinder non-Spanish agents, and no mention of return value or confirmation. Adequate but not 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% (one boolean parameter fully described). The tool description does not add new meaning beyond what the schema already provides; the parameter description in schema is identical in substance. Baseline 3 applies as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses clear verb 'Activar/desactivar' and resource 'traduccion automatica de mensajes'. It specifies the action (toggle) and object (automatic translation of messages), distinguishing it from sibling toggle tools like 'toggle_analytics' or 'toggle_auto_describe_images'. However, it could be more precise about the scope (e.g., global or per conversation).
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., specific toggles for other features). No mention of prerequisites, constraints, or when not to use it. The description lacks any usage context to aid decision-making.
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?
No annotations are provided, so the description must disclose behavioral traits. It notes '[mutation]' implying a write operation, but fails to specify side effects, reversibility, or required permissions. The description is too brief to inform an agent about the behavioral impact.
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 action. However, the '[mutation]' tag is somewhat informal and reduces clarity. Every sentence earns its place, but the structure could be improved by integrating the tag naturally.
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 simplicity of the tool (one parameter, no output schema), the description is nearly adequate. It explains the core action and effect, but lacks context about the snippet's state, prerequisites, or reversibility. Compared to sibling tools with more detailed descriptions, it is complete enough to use but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter 'id', so the schema already documents its meaning. The description adds no additional context beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('toggle permanent'), the resource ('snippet'), and the effect (protects from age expiration). However, it does not differentiate from sibling tools like toggle_knowledge_file, which also toggle a boolean state on knowledge resources.
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. It does not mention any prerequisites, limitations, or scenarios where this tool is appropriate. The description only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It notes [mutation] but does not detail side effects (e.g., what happens to running workflows), required permissions, or error conditions. The description is overly minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two clear phrases and no redundant words. However, it could include more information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only two parameters, the description is insufficient. It fails to explain what happens upon success/failure, whether the change is immediate, or if there are constraints (e.g., cannot pause a paused 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?
The input schema already provides descriptions for both parameters (id and enabled) with 100% coverage. The description adds no additional semantic meaning beyond what the schema conveys, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (activate/pause) and the resource (WhatsApp workflow). The [mutation] tag reinforces that it modifies state. It is sufficiently distinct from siblings like create_whatsapp_workflow or update_whatsapp_workflow.
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., update_whatsapp_workflow). It does not mention prerequisites, such as the workflow must exist, nor does it indicate that this is the right tool for toggling enabled state.
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?
With no annotations, the description only labels the tool as '[mutation]' but does not disclose behavioral details such as whether the action is reversible, permission requirements, or side effects. This is insufficient for safe usage.
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 brief and to the point, with a clear title-like prefix. However, it could include a bit more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description fails to explain what 'unpublish' entails (e.g., visibility change, reversibility). This lack of completeness may lead to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 faq_ids is fully described in the schema (100% coverage). The tool description does not add extra meaning beyond the schema, so a moderate score 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 (unpublish), resource (FAQs of Product Q&A plugin), and scope (one or multiple). However, it does not differentiate from sibling tools like delete_faq or republish_faq, which could lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or exclusions. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It tags '[mutation]' to indicate a write operation but does not describe side effects, auth requirements, partial vs. full update semantics, or error conditions. It lacks detail on behavioral traits beyond being a mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a tag, which is efficient. It is front-loaded with the purpose and lists changable fields. No extraneous information. However, it could be slightly more structured (e.g., bullet points) but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 4 parameters (3 optional), the description lacks important context such as return values, success/failure responses, or constraints. It does not explain what happens on update (e.g., confirmation, error codes), making it incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description lists the same fields as the schema (content, category, status). It adds marginal value by summarizing the purpose of each field, but the schema already provides detailed descriptions (e.g., enum values). Baseline 3 as schema does the heavy lifting.
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 'Update an existing AI correction' with verb 'Update' and resource 'AI correction'. It lists the fields that can be changed (content, category, status). However, it does not explicitly differentiate from sibling tools like 'set_ai_error' (which likely creates) or 'delete_ai_error', though 'existing' implies update vs. create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'set_ai_error' or 'delete_ai_error'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only a [mutation] tag is provided; no details on side effects, permissions, or behavior beyond basic update. Without annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, no wasted words. Could be more structured but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description should cover return values, optionality implications, and field relationships. It does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 no extra meaning beyond what the schema already provides. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates billing info for invoices, with a verb and resource. However, it does not differentiate from sibling tools like update_business_info.
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, no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the [mutation] tag. It does not specify whether updates are partial or full, what happens to omitted fields, or any side effects. With no annotations, the burden is higher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, but lacks structured breakdown. Could be improved with bullet points or clearer sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, error handling, or expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. Schema description coverage is 45%, but the description does not clarify the role or format of parameters like title, start_datetime, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 modifies an existing calendar event ('Modifica un evento existente del calendario'). It uses a specific verb and resource, distinguishing it from sibling tools like update_calendar_event_status or update_calendar_availability.
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 such as update_calendar_event_status or update_calendar. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'update' and 'mutation', lacking details on authorization, reversibility, or side effects. The email limitation is in schema, not description.
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 (one sentence + tag), front-loaded with the action, and contains no extraneous words. Could be expanded slightly to cover email limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description is too sparse. It omits the billing update capability and does not reference the email_change_code parameter or email OTP constraint.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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. Baseline 3 is appropriate as the description does not compensate with additional parameter insights.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates contact data (name, email, phone) of the account, with a [mutation] tag. However, the input schema includes many billing fields not mentioned, creating a slight mismatch.
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 siblings like update_billing_info or update_business_info. The email field schema warns against use, but the description itself provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as '[mutation]' indicating a write operation, but with no annotations, it fails to disclose side effects like scope (global vs per-session), reversibility, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear label, making it concise and front-loaded. No unnecessary words, but lacks structural elements like separate sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is minimally complete. However, it omits behavioral scope and when to use it, which is relevant given similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter is fully described in the schema (100% coverage) with enum values. The description merely echoes the parameter's purpose ('Formato de fecha') without adding extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes the date display format, using the verb 'Cambiar' and specifying the resource 'formato de fecha'. It distinguishes from siblings like update_timezone by focusing on date format rather than timezone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as update_timezone or other update tools. There is no mention of 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?
With no annotations, the description carries the full burden. It states 'modifica' and includes '[mutation]' indicating a state change, but it does not disclose any behavioral traits such as idempotency, error handling, permissions required, or whether the update is partial or full. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words. It efficiently communicates the core purpose and key modifiable fields. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema), the description is incomplete. It only covers a subset of parameters, omitting important context about several parameters (e.g., agent_id, phone, pagination fields). The presence of list-like parameters in an update tool schema is not addressed, and no return value or side effects are described.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 high (91%), so the baseline is 3. The description lists the primary updatable fields in natural language, which adds minimal meaning beyond the schema. It does not explain the purpose of extra parameters like limit, offset, or include_completed, which seem unrelated to an update operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (update task) and lists the modifiable fields (status, text, priority, deadline, assignment). It distinguishes the tool from create_task and delete_task by specifying it modifies existing tasks. However, it does not explicitly differentiate from sibling update tools like update_agent, but the resource name serves as differentiation.
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. There is no mention of prerequisites, when not to use it, or comparisons to similar tools like create_task. The usage context is only implied.
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?
No annotations provided, so the description carries full burden. It only notes '[mutation]' but does not disclose side effects, required permissions, rate limits, or behavior with invalid workflow_ids. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first line and second line convey the same information. It could be condensed to a single sentence without loss of meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should clarify return values or confirmation. It lacks details on error handling, idempotency (e.g., toggling already-correct state), or what happens to related resources. Given many sibling tools, more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear descriptions. The description adds no additional 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 'Activar/desactivar workflows en lote' (activate/deactivate workflows in batch), with a specific verb and resource. It distinguishes from siblings like toggle_whatsapp_workflow (single toggle) and bulk_delete_workflows (delete instead of toggle).
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. With many workflow-related siblings such as toggle_whatsapp_workflow, bulk_delete_workflows, and toggle_analytics, the description lacks context on when bulk toggle is appropriate or when to use single toggle instead.
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?
With no annotations provided, the description must fully disclose behavior. It only notes it's a mutation but lacks details on side effects, permissions, or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but functional. It could be more structured, but it's not verbose. Adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description fails to mention return values or confirmation. Lacks completeness for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds no extra meaning, meeting baseline but not exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 (eliminar/delete) and the resource (nota interna de email), distinguishing it from sibling add_email_note. The verb and object are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context about prerequisites or conditions for deletion.
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?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It does not mention whether the operation is read-only, requires authentication, has rate limits, or any side effects. The description merely lists what is shown, without 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it includes a trailing "[query]" that is unclear and may confuse the agent. The purpose is front-loaded, but the extra bracket adds noise. It could be more structured without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description provides adequate detail about the content of the metrics. However, it does not explain the return format or any potential filtering, and it does not clarify the difference from sibling tool get_autolearning_stats. This leaves some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty object). The description adds value by specifying the types of metrics included (KPIs, distribution, evolution), which goes beyond the empty schema. Baseline for 0 parameters is 4, and the description meets that baseline.
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 displays autolearning metrics including KPIs, distribution by category, and similarity evolution. It uses a specific verb ("Ver" / "Muestra") and resource, making the purpose clear. However, it does not differentiate from sibling tool get_autolearning_stats, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks explicit context such as when the tool is appropriate, prerequisites, or exclusions. This leaves the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral information beyond what the name implies. With no annotations provided, it should disclose side effects, permissions, or rate limits, but it only states it 'gets 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?
The description is very short but includes an unclear '[query]' placeholder. It lacks structure and could be clearer about what 'complete details' entails.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only a vague promise of 'complete details', the description does not sufficiently inform about the return structure. More details about the response fields would be necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 is fully described with campaign_id's description. The tool description adds no extra meaning 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 complete details of a mass marketing campaign. It distinguishes from siblings like list_campaigns or update_campaign by specifying it gets details of a single campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_campaigns or get_campaign_logs. The description only states what it does without context.
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?
With no annotations, the description bears full responsibility for behavioral disclosure. It only says 'counts conversations' without describing whether it is read-only, what the output format is, how parameters like limit/offset or the 'message' parameter affect behavior, or any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but lacks structure. It uses a dash as a separator, which is acceptable, but the brevity sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 13 parameters, no output schema, and no annotations, the description is inadequate. It does not explain the output (likely a count), how parameters interact, or the purpose of outliers like 'message' and 'conversation_id'. The tool is not fully specified 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?
The input schema has 100% coverage with descriptions for all 13 parameters. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts conversations matching search criteria, date, or period. It uses the specific verb 'count' and resource 'conversations', distinguishing it from sibling tools like search_conversations or get_conversation_detail.
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. It does not mention when to prefer counting over searching or other conversation-related tools, nor 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states that it shows data, without disclosing any behavioral traits like read-only nature, required permissions, or response format. The vague '[query]' suffix adds ambiguity.
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 a single sentence, which is concise, but the inclusion of '[query]' is unclear and somewhat cryptic. It is front-loaded but loses clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and four optional parameters, the description should explain how parameters affect output or hint at return format. It does not, making it incomplete for an agent to effectively 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 coverage is 100%, with each parameter having a description. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows OpenAI credit consumption per day and per endpoint, which is a specific verb+resource. Among siblings like get_credits_info, this distinguishes by specifying breakdown by day and endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_credits_info or get_api_usage_stats. The description only states what it does without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose if the operation is read-only, any performance implications, pagination, or limits. The description mentions 'timeline' but lacks behavioral details like whether it returns all data or only recent items.
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 a single sentence in Spanish, which is concise but includes an unexplained '[query]' placeholder. It could be more structured, but it front-loads the purpose. Not a model of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the output structure. It lists item types but not their order, format, or if it's a paginated list. The tool is complex with 4 parameters, yet the description is insufficient for an agent to fully understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 phone, date, period, and days. The tool description adds little beyond the schema, except the ambiguous '[query]' which is not a parameter. Baseline 3 is appropriate since the schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Historial completo del cliente' (complete customer history) including messages, comments, files, tasks, orders, and follow-ups. This distinguishes it from sibling tools like get_customer_info or get_purchase_history which are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings include many getter tools, but the description does not specify the scenarios where this aggregated timeline is preferred over individual lookups.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it shows statistics, but does not mention any side effects, authentication needs, rate limits, or whether the operation is read-only. Without annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line), which is good, but it uses a dash and contains a slight redundancy ('Ver estadisticas de Product Q&A — Muestra estadisticas...'). It could be more streamlined, but it is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should provide more context about what statistics are returned (e.g., counts, top questions, time periods). It fails to do so, leaving the agent with minimal understanding of the tool's output or scope.
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 is empty (no parameters), so the description does not need to explain parameter meanings. With 100% schema coverage, baseline is 3; the 0-parameter case justifies a 4 because there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves statistics for the Product Q&A plugin. It uses specific verbs and resources ('Ver estadisticas', 'Muestra estadisticas del plugin de preguntas sobre productos'). However, it does not differentiate from similar siblings like get_plugin_stats or get_product_qa_faqs, which could also return statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. There are many related tools (e.g., get_plugin_stats, get_product_qa_faqs, get_product_qa_questions) that might serve similar purposes, but the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that it gets the current configuration, but does not explicitly indicate that it is read-only, safe, or free of side effects. No authentication or rate limit info is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the second sentence nearly repeats the first. The '[query]' suffix is unclear and adds no value. It could be more concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with an output schema absent, the description should at least hint at the structure of the returned configuration. It only says 'current configuration' without details. The optional parameters are documented in the schema, but the description does not explain their effect on the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 three parameters. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Obtener') and resource ('configuracion de seguimiento inteligente'), clearly indicating it retrieves the current smart follow-up configuration. This distinguishes it from sibling tools like 'save_smart_followup_config' and 'trigger_smart_followup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., save_smart_followup_config, trigger_smart_followup). The description only states what it does, not the context or prerequisites.
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?
No annotations are provided, so the description must fully convey behavioral traits. It fails to disclose that the tool is read-only, does not modify data, or any rate limits or authorization needs. The description only states it generates suggestions, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Spanish, front-loaded with a pseudo-title. It is not verbose, but it lacks structure like bullet points or examples. Still, it efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema or annotations, the description is too brief. It does not explain parameter interactions (e.g., days vs hours), output format, or that it is read-only. The schema descriptions cover parameter meanings, but the description omits important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with each parameter described in the schema. The description adds the explicit number '3 suggestions' and implies the tool uses the conversation context, which is not in the schema. This adds value beyond the schema, warranting a 4.
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 generates 3 reply suggestions based on the current conversation, with a specific verb ('genera') and resource ('sugerencias de respuesta'). It distinguishes from other AI tools like get_ai_summary or get_sentiment_analysis. However, the phrase 'conversacion actual [query]' is ambiguous about how the conversation context is obtained, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other AI generation tools (e.g., generate_email_draft, get_ai_summary). There is no mention of prerequisites, when not to use it, or comparisons to siblings.
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?
Input schema includes limit/offset parameters typically associated with list endpoints, but description only mentions count. No clarification on whether the tool returns a count object or a list with count. No output schema provided. Lack of annotations makes this ambiguous.
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?
Single sentence with dash, but includes stray '[query]' which is confusing. Adequate length, but clarity suffers from the unnecessary bracket.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 6 parameters and no output schema; description does not explain how parameters affect the count (e.g., filter, type). Missing details on whether count is global or per user. Incomplete for effective 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 descriptions cover all 6 parameters with basic meanings (limit, offset, filter, type, notification_id, agent_id). Description does not add further semantic value beyond the schema. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool counts unread notifications using specific verbs 'Contar' and 'obtiene el numero'. It distinguishes from siblings like list_notifications and mark_notification_read.
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. Does not mention that it returns a count only, nor specify prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds only '[mutation]' which is redundant given the tool name implies deletion. With no annotations, it fails to disclose behavioral traits such as irreversibility, required permissions, or impact on related 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 extremely short (two lines), which is concise but lacks structure and front-loading of critical information. It omits important details like the operation's destructive nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of bulk deletion (6 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain return values, confirmation steps, or scope boundaries beyond what's in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the description adds no additional meaning. The parameters are well-documented in the schema, meeting the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Eliminar' (delete) and resource 'bajas' (unsubscribes) with 'en bloque' (in bulk), making the tool's purpose specific and distinguishable from siblings like 'remove_contacts_bulk' which targets contacts.
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 'remove_from_blacklist' or 'remove_whatsapp_optout'. It does not specify context such as prerequisites or when not to use bulk deletion.
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?
With no annotations, the description must disclose behavioral traits. It only includes '[mutation]' hinting at write operation, but lacks details on side effects, permissions, atomicity, or error behavior. For a global configuration change, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first sentence nearly repeats the title, and the second adds only 'global' and '[mutation]'. It could be more concise by merging.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies global settings with a nested parameter and no output schema, the description should provide more context about expected behavior, return values, and potential impacts. It currently lacks essential completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. However, the description adds no extra meaning beyond the schema, especially for the complex nested 'settings' object, whose internal structure remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 saves global calendar settings, using a specific verb ('guardar') and resource ('configuración global del módulo de calendario'). It distinguishes from sibling tools like 'get_calendar_settings' and 'update_calendar' by emphasizing 'global' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or related tools. The description is purely declarative.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the search scope ('all customers'), but omits details like pagination, result format, performance implications, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-informative. It earns its place but fails to provide necessary context beyond the bare function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return values, filtering behavior, or how to use non-required parameters effectively, leaving many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 89%, with 8 of 9 parameters already described in the schema. The tool description does not add any additional parameter meaning beyond the bare mention of '[query]', so it does not significantly improve clarity 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 uses a specific verb ('Buscar'/'Search') and resource ('comentarios de todos los clientes'/'comments of all customers'), clearly distinguishing it from sibling search tools like search_conversations, search_customers, and global_search, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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., search_customers, global_search), nor any conditions or exclusions. It only states the basic function.
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?
With no annotations, the description carries full burden but only states basic functionality. It does not disclose whether the tool is read-only or performs writes, nor any side effects, authorization needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, efficiently conveying the core purpose. However, it could benefit from a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no annotations, no output schema), the description lacks details about return values, process, and side effects. It is insufficient for fully understanding 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 coverage is 100% with parameter descriptions. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool categorizes recent conversations by topic, intent, and priority using AI. It uses a specific verb and resource, and distinguishes from sibling tools like auto_tag_customer or search_conversations which focus on different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention contexts, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a '[mutation]' tag indicating side effects, but with no annotations, it fails to disclose behavioral details like immediate impact on existing widgets, reversibility, or required permissions. The effects of the 'is_enabled' toggle are not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the purpose. The '[mutation]' tag is helpful. However, it could be slightly more structured by separating the activation and configuration aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lacks any mention of return values or confirmation. It does not explain if changes take effect immediately, require page refresh, or if the plugin must be installed first. This leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add additional context beyond the schema. The baseline of 3 applies as the description adds no extra meaning, such as examples or constraints, to the 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 tool configures the Product Q&A plugin, activating and configuring the product questions widget. The verb 'configurar' and resource 'plugin Product Q&A' are specific, and it distinguishes from sibling tools like 'configure_plugin_chat' or 'get_product_qa_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other plugin configuration tools or product Q&A management tools. There is no mention of prerequisites or scenarios where this tool should or should not be used.
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?
No annotations provided. The description includes '[mutation]' tag indicating state change, but lacks details on side effects, required permissions, or the post-scan flow. It does not explain the impact of the 'force_new' parameter or what happens to existing sessions.
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 concise with one sentence plus a tag. However, it could be structured to highlight key behaviors. Still, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain the connection flow, what the QR code represents, or any post-action steps. Context is insufficient for an agent to fully 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?
Input schema has 100% description coverage for both parameters. The description adds no additional meaning beyond what is already in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'connect' and the resource 'WhatsApp number', and specifies that it initiates the connection process and returns a QR code. This distinguishes it from sibling tools like 'get_whatsapp_qr' which only retrieves a QR code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'reconnect_whatsapp' or prerequisites. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels it as a mutation with '[mutation]' and warns about plan limits, but does not disclose what happens on success (e.g., return value), required permissions, or side effects. No annotations exist to supplement this, leaving significant gaps.
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 only two sentences, front-loaded with the main action, and includes a critical failure condition. It is concise and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation with 8 parameters and no output schema, the description lacks details about return values, required permissions, or how to handle the described failure. The plan limit note is helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the input schema, achieving 100% coverage. The tool description adds no extra meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new customer service agent ('Crea un nuevo agente de atencion'), distinguishing it from sibling tools like update_agent and delete_agent. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a potential failure due to plan limits, but does not provide explicit guidance on when to use this tool versus alternatives like update_agent or save_agent_permissions. Usage context is implied rather than stated.
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?
No annotations are provided, so the description carries full burden. It includes the tag '[mutation]' but fails to disclose side effects (e.g., whether existing settings are overwritten), required permissions, or any rate limits. It only states the basic creation action without deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a dash-separated list of types, front-loaded with the main action. It is concise and avoids unnecessary words, though the mutation tag slightly clutters the structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values—since there is no output schema, it should state what the tool returns (e.g., the created notification object). It also does not mention prerequisites like the existence of the calendar or required access permissions, which are important for a creation 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 all parameters described. The description adds no additional meaning beyond the schema; it merely repeats the types. According to the rubric, high schema coverage 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?
The description clearly states that the tool creates an automatic notification for a calendar and lists the notification types (confirmation, reminder, cancellation, follow-up, no-show). It uses a specific verb 'creates' and resource 'calendar notification', distinguishing it from other calendar-related tools like create_calendar_event.
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 its siblings (e.g., update_calendar_notification, delete_calendar_notification). There is no mention of prerequisites or scenarios where this tool should not be used.
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?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions '[mutation]' to indicate state change, but does not describe side effects, permission requirements, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is efficient but could be improved by adding structure (e.g., bullet points) to increase readability without increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of output schema, the description is insufficient. It does not explain what happens upon success/failure, how template existence is handled, or what the return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds no extra meaning beyond the schema's parameter descriptions, which already define each 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: creating a new WhatsApp workflow from an existing template. It uses a specific verb ('Crear') and resource, distinguishing it from tools like 'create_whatsapp_workflow' which may not involve a template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_whatsapp_workflow'. The description lacks any 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Devuelve' (returns), implying a read-only operation, but does not specify if the tool has side effects, requires authorization, or has rate limits. Critical behavioral context is missing.
Agents need to know what a tool does to the world before 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 clear clauses, no wasted words, and front-loaded purpose. It achieves maximum information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and input but lacks information about the output structure, what happens if phones are invalid, or if multiple agents can be assigned per phone. Without an output schema, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 already describes the parameter 'phones' as 'Lista de numeros de telefono para consultar sus agentes asignados' with 100% coverage. The description adds 'de clientes' (customers), which is redundant with the schema description. No additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('obtener asignaciones de agentes') and the input ('lista de telefonos de clientes'), distinguishing it from sibling tools like list_agents (which lists all agents) or get_agent_activity (which focuses on agent performance). However, it could be more explicit about the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_agents or get_agent_activity. There is no mention of prerequisites, limitations, or context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses credit consumption, which is a behavioral trait. However, with no annotations, it fails to state whether the operation is read-only or destructive, or describe side effects. It partially fulfills the burden for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the title. It includes essential information in a compact form. The trailing '[query]' is slightly distracting but does not harm comprehensibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema or annotations, the description is insufficient. It does not explain the output format, error conditions, or how parameters like 'days' and 'hours' interact. The agent lacks context for proper 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%, so the description adds no new parameter meaning beyond the schema. It repeats the enum translations already in the schema but does not explain parameter relationships or constraints. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an AI summary of a conversation and lists three summary types. However, it does not differentiate from sibling summary tools like get_conversations_summary or get_daily_summary, which weakens its specificity.
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 mentions credit consumption but provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It lacks explicit context for choosing among summary types or when to use this over other summary 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?
No annotations are provided, so the description carries full burden. It implies a read-only operation but does not disclose details like data freshness, scope, or any side effects. It is adequate for a simple stats retrieval, but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. It is appropriately sized with no waste, though it could benefit from additional structure or detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 4 parameters and numerous sibling tools, the description is insufficiently complete. It does not explain output, pagination, or provide enough context to distinguish from similar tools, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond what the schema already provides. The schema descriptions for each parameter are sufficient.
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 provides API usage statistics, specifically token consumption and costs per AI model. It is specific and uses a verb+resource structure. However, it does not differentiate itself from sibling tools like get_usage_stats or get_usage_stats_detail, which could cause ambiguity.
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 over alternatives, nor does it mention any exclusions or conditions. With many similar sibling tools, the lack of usage context makes it harder for an agent to choose correctly.
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?
No annotations are provided, and the description does not mention behavioral traits such as read-only nature, rate limits, authorization requirements, or side effects. For a read operation, stating that it does not modify data would be helpful.
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, fitting in one sentence, and covers the main points. However, it could be slightly more structured by separating the list more clearly or adding formatting, but it remains 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 three parameters and no output schema, the description provides a reasonable summary of the returned data (volumes, response times, agent breakdown, AI classification). It is fairly complete for a statistics retrieval tool, though it could mention the response format or any limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, and the tool description does not add any additional meaning to the parameters beyond what the schema already provides. The schema descriptions are sufficient, so no extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves email statistics including volumes, response times, agent breakdown, and AI classification. It is specific but does not explicitly differentiate from similar sibling tools like get_agent_stats or get_period_stats, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative tools for statistics. The description lacks context about preferred use cases, prerequisites, or scenarios where other tools might be more appropriate.
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?
No annotations provided, and description only states 'list' operation without confirming read-only nature, response format, or any behavioral constraints beyond plugin requirement.
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, but trailing '[query]' appears to be a placeholder and may confuse agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description fails to explain return structure, pagination behavior, or grouping details, leaving agents to infer important 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 has 100% coverage with descriptions for all 4 params; description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists published FAQs grouped by product, but does not explicitly differentiate from sibling tools like get_product_qa_questions or manage_faq.
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?
Mentions prerequisite (plugin must be configured/active) but lacks guidance on when to use vs 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states the tool shows the current prompt, but it does not disclose whether it is read-only, whether it requires any authentication, or any other behavioral traits. The minimal information does not add value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line), but it is front-loaded with the purpose. The inclusion of '[query]' in parentheses seems like a placeholder and could be confusing. Overall, it is efficient but slightly unclear due to the Spanish language and the stray bracket.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters), the description is somewhat complete in stating the action. However, there is no output schema, and the description does not explain what the agent will receive (e.g., the prompt text). This leaves a gap for an AI agent to know what the invocation yields.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 zero parameters, so schema description coverage is 100%. The baseline score is 3, and the description does not need to explain parameters. It adds no additional semantics, but no deficiency either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Ver prompt actual — Muestra el prompt actual de la IA'. The verb 'mostrar' (show) and resource 'prompt actual' (current prompt) are specific, and it distinguishes from sibling tools like save_prompt, improve_prompt, and get_prompt_history.
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 get_prompt_history or improve_prompt. There is no explanation of context, 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?
No annotations are provided, so the description carries full burden. It states it shows previous versions but does not disclose whether it is read-only, how versions are ordered, any access constraints, or the impact of usage. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loading the purpose. It is concise and to the point, though it could benefit from slightly more structure, such as separating the title from the description.
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 no output schema and no annotations, the description provides minimal context. It conveys the basic functionality but lacks details on output format, pagination, or typical use cases. Adequate for a simple history tool but not fully 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?
There are zero parameters, so baseline is 4 per instructions. The description adds no parameter info, but this is acceptable as schema coverage is 100% (trivially). No loss of meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows previous versions of a prompt, specifying the verb 'shows' and resource 'prompt history'. However, it does not differentiate from sibling tools like 'get_prompt' or 'rollback_prompt', leaving ambiguity about the specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for viewing history, but lacks context about prerequisites, when not to use it, or which sibling tools handle related tasks like retrieving the current prompt or rolling back.
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 consumes AI credits, which is a cost implication. However, with no annotations, it does not mention whether the operation is read-only, authorization needs, or other side effects. It also does not clarify the relationship between 'phone' and 'conversation analysis'.
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, front-loading the purpose and output. The unclear '[query]' is a minor flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema, the description is insufficient. It does not explain parameter interactions, output format (JSON?), or how the tool processes conversations given the required phone parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 its 8 parameters, so the description adds little beyond the schema. It lists output fields but does not explain how parameters like 'summary_type' or 'tone' affect the analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes sentiment and intent of a customer conversation using AI, and lists the return fields. However, the mention of '[query]' at the end is ambiguous and the required parameter is 'phone', not a query, causing slight confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like 'get_sentiment_trend' or 'get_ai_summary'. The description does not specify prerequisites or alternatives.
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?
No annotations are provided, so the description carries the full burden. It only states what the tool shows, with no mention of side effects, read-only nature, sorting, pagination, or other behavioral traits. The agent gets no insight into how the tool behaves beyond its 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 a single sentence that front-loads the core purpose. It is efficient with no wasted words. However, it could be slightly more structured (e.g., separating the query tag) but remains concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters and no output schema or annotations, the description is minimal. It does not explain the return format, pagination behavior, how 'query' interacts with other filters, or what the default sorting is. Significant gaps remain for an agent to use it 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?
The input schema has 100% coverage with descriptions for all 13 parameters, so the baseline is 3. The description adds no extra meaning beyond the schema; it only echoes the tool's purpose. No additional context is provided for parameters like 'query' or 'hours'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 shows conversations where the last message is from the client (unanswered), using a specific verb ('Muestra') and resource ('conversaciones sin responder'). It effectively distinguishes itself from sibling tools like 'get_recent_conversations' or 'search_conversations' by focusing on the unanswered criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It includes a '[query]' hint but does not explain the context or when to prefer this over other conversation retrieval tools. No explicit exclusions or alternative names are given.
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?
No annotations are provided, so the description must disclose behavioral traits. It only states what the tool returns (combined state) but fails to mention that it is read-only, any side effects, authentication requirements, or default behavior when parameters are omitted. For a tool with no annotations, this is insufficient 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 a single sentence that front-loads the purpose and lists key components efficiently. It wastes no words, but could benefit from a slightly more structured format (e.g., bullet list) for readability. Overall, it is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three optional parameters, no output schema, and many sibling tools, the description lacks completeness. It does not specify the output format (e.g., JSON structure) or explain what 'query' in brackets means. Agents need additional context to decide how to use parameters effectively and interpret results. This is a gap for a health check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only lists the components in the health check. The parameter descriptions in the schema are basic, and the description does not clarify filtering semantics (e.g., whether direction values are IN/OUT or something else). Thus, it adds marginal 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 specifies the tool's purpose: a comprehensive health check of WhatsApp that combines session status, 24-hour message activity, and active workflows. The use of 'completo' and enumeration of components gives a specific and complete understanding, distinguishing it from sibling tools like get_whatsapp_connection_status or get_whatsapp_workflow_activity.
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 versus the many sibling tools. It does not state prerequisites, when not to use it, or suggest alternatives for more specific queries (e.g., get_whatsapp_status for a simpler check). The implication is limited to needing a combined health overview, but without exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description only labels it as [mutation]. It does not disclose side effects, authorization needs, rate limits, or what happens to existing data. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clarifying dash and mutation tag. It is concise and efficient, though could be slightly more structured with separate usage hints.
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 simplicity of the tool (1 parameter, no output schema), the description provides basic context. However, it omits details like required permissions, success/failure responses, and how it differs from similar import tools.
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 for the single parameter 'list_id'. The description adds context that the list is for 'marketing masivo' (mass marketing), enhancing schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it imports contacts from WAzion's internal CRM to a mass marketing list. However, a sibling tool 'import_crm_contacts' exists without differentiation, slightly reducing clarity.
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 the many other import contacts tools (e.g., import_contacts_csv, import_crm_contacts). The description lacks explicit usage context.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the mutation action and the input format, omitting behaviors like validation of phone numbers, handling of duplicates, or success/failure responses.
Agents need to know what a tool does to the world before 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, consisting of two short sentences that front-load the core information. No unnecessary words or redundant details, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with two parameters and no output schema, the description covers the basic purpose and input format. However, it lacks completeness by not mentioning prerequisites (e.g., list existence) or side effects, which would be helpful for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 already describes both parameters with 100% coverage. The description adds no new semantic information beyond the schema's parameter descriptions, such as the phone format, but this is adequate.
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 specifies the action ('import contacts'), the target resource ('marketing list'), and the method ('manually typing phone numbers'). It distinguishes from sibling import tools by emphasizing manual entry, but could be more explicit about when to use this over CSV or TXT imports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like import_contacts_csv or import_contacts_from_conversations. The description only implies manual entry, leaving the agent to infer appropriate scenarios.
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?
No annotations are provided, so the description carries the full burden. It states the tool retrieves data, but does not disclose whether it is read-only, any side effects, authentication needs, rate limits, or pagination 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 a single, concise sentence that front-loads the main purpose. The trailing '[query]' is slightly ambiguous but does not detract significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what is returned. It fails to mention the structure of the response, pagination details, or any additional context needed for effective 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?
The input schema already provides descriptions for both parameters (search and page) with 100% coverage. The description does not add significant meaning beyond the schema, meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ver lista negra de marketing' and specifies it retrieves manually blocked numbers that won't receive mass campaigns. It distinguishes from voluntary unsubscribes, but doesn't explicitly differentiate from sibling tools like list_unsubscribed_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint about when to use this tool (for manually blocked numbers) versus voluntary unsubscribes, but lacks explicit guidance on when to use it over other blacklist-related tools or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description implies this is a read-only operation (list), which is typical and safe, but it does not explicitly state non-destructiveness. It also does not mention rate limits, pagination behavior (though schema has page/limit), or any side effects. For a listing tool, basic safety is assumed, and the description adds little beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single line in Spanish and English. It is front-loaded with the action and resource. However, it could be better structured by separating the core purpose from additional context. The brevity is acceptable for a simple list tool but leaves out important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the list returns (e.g., thread subjects, senders, dates), how pagination works, or any constraints (e.g., maximum results). The schema describes parameters but the description should provide usage context, which is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 mentions filters by status and account (which correspond to 'filter' and 'account_id' parameters), but it does not describe the other 9 parameters like search, from_filter, has_attachments, etc. The description adds minimal value over the schema descriptions, which already explain each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists email threads of the store and mentions filters by status and account. It uses specific verb 'list' and resource 'email threads', which distinguishes it from sibling tools like get_email_thread_detail (detail of a single thread) or list_email_accounts (accounts). However, it does not explicitly differentiate from other list tools like list_email_drafts, but the resource name provides clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not indicate that list_email_threads is suitable for browsing/filtering threads, while get_email_thread_detail should be used for retrieving details of a specific thread. No exclusion criteria or best practices 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?
No annotations are provided, so the description must disclose behavioral traits. It only says 'get system notifications with optional filters', implying a read operation but doesn't explicitly state it's non-destructive, requires no special permissions, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 17 words, extremely concise. It front-loads the purpose and is efficient with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema or annotations, the description is sparse. It doesn't explain response format, pagination behavior, or default values beyond schema hints. Adequate for a simple list operation but leaves gaps 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?
Input schema has 100% coverage with descriptions for all 6 parameters. The description adds minimal value by stating 'with optional filters', but the schema already defines each parameter's purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists system notifications with optional filters. It uses a specific verb 'list' and resource 'notifications'. While it distinguishes from siblings by implying filtering capability, it doesn't explicitly contrast with other notification tools like mark_notification_read or get_unread_notification_count.
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 mentions optional filters but provides no guidance on when to use this tool versus alternatives. It doesn't state prerequisites or scenarios where it's preferred over other notification-related tools.
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?
No annotations are provided, so the description must disclose behavior. It only states that the tool shows opt-out contacts, without mentioning pagination, search, or any other operational traits. The page parameter is in schema but not described in the description.
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 at two sentences, but the trailing [query] appears to be a placeholder or markdown remnant, which slightly reduces clarity. However, it is otherwise focused and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should provide more context about the list's size, pagination behavior, and how the search filter works. The current description is too minimal for a tool that returns a list of contacts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the input schema with 100% coverage. The description adds no additional meaning beyond the schema definitions, 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 tool lists WhatsApp opt-out contacts, which are contacts that have requested not to receive automatic messages. This verb+resource structure clearly distinguishes from sibling tools like add, remove, and check opt-out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like check_whatsapp_optout or add_whatsapp_optout. The description does not mention any prerequisites or use cases.
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?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or rate limits. It only states the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. The bracketed '[query]' is odd but does not detract from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is adequate but lacks details about return fields or pagination, leaving some 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?
There are no parameters in the input schema, so baseline score of 4 applies. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists WhatsApp sessions available for sending scheduled messages. The resource is distinct from sibling tools like list_scheduled_messages, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or prerequisites. The description only states what it returns, not when it should be invoked.
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?
No annotations provide safety info, and the description only labels the tool as '[mutation]'. There is no detail about side effects, permission requirements, or impact on unread counts.
Agents need to know what a tool does to the world before 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: two lines with key info front-loaded. No superfluous text.
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 basic action and constraint but lacks behavioral context (e.g., what exactly happens, success indicators). Adequate for a simple mutation tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with descriptions. The description adds the constraint that at least one is required, which is useful but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (mark email as read) and the resource (thread or message). It distinguishes itself from other email operations but does not explicitly differentiate from siblings like snooze_email_thread.
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?
Only a prerequisite is given ('requires at least thread_id or message_id'). No guidance on when to use this tool versus alternatives, nor 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?
With no annotations, the description must convey behavioral traits. It only states what it searches but omits side effects, pagination, return format, or how additional parameters (like comment, agent_name) affect the search. The mention of '[query]' is unclear and does not explain behavior beyond the basic search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the purpose. However, the inclusion of '[query]' is confusing and could be misinterpreted. Slightly hindered by unclear reference to the query parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema, no annotations), the description is incomplete. It fails to cover the many additional parameters (e.g., phone, comment, agent_name, tag_name, etc.) and does not describe the return value or any constraints. An agent cannot fully understand tool usage from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 high (89%), so the schema itself describes parameters. The description adds minimal extra meaning: it implies searching by name/phone/email but does not explain the purpose of other parameters like limit, comment, agent_name, etc. It adds the context of searching in CRM and contacts, which is not in the schema, but overall value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Buscar' (search) and resource 'clientes' (customers), specifies search fields (nombre, telefono, email) and sources (CRM y contactos). It distinguishes from siblings like search_conversations or search_customer_comments by focusing on customers and their contact info.
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. The description does not mention exclusion cases or suggest sibling tools for other search purposes (e.g., search_customer_comments for comments, search_conversations for conversations). An agent lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description only labels it as a mutation but lacks details on side effects, permissions, reversibility, or any behavioral traits beyond the mutation hint.
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?
Two sentences, but they are somewhat redundant. Could be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with two parameters and no output schema, the description is adequate but lacks broader context about effects on email sorting or notification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional 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 verb ('Establecer'/'Cambia') and the resource ('prioridad de hilo de email') with a mutation hint. It is specific and distinguishes from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 assign_email_thread or get_email_thread_detail. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It mentions mutation and effect but does not disclose side effects, permissions, or potential impacts. The presence of an unexplained parameter (auto_describe_images) further reduces 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 relatively concise with two sentences and a tag, front-loading the purpose. Some redundancy exists (Activar/desactivar and Activa o desactiva), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core toggle but fails to clarify the role of the auto_describe_images parameter, leaving a gap. For a simple mutation, more completeness is expected regarding scope and side 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 both parameters having descriptions. However, the tool description adds no additional semantic value beyond the schema. The optional parameter's purpose is unclear from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool toggles automatic sentiment analysis for WhatsApp conversations, specifying the effect (IA analyzes sentiment and shows indicators). It distinguishes from sibling toggles like toggle_auto_describe_images by focusing on sentiment.
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. The description only explains what it does, not context or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states it modifies data and includes a [mutation] tag, but with no annotations it does not disclose side effects, authorization needs, or what happens on missing fields. Behavioral details are insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. It is concise and front-loaded with the core purpose, but could include more structure or additional context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description should explain return behavior, partial update semantics, or optional parameter effects. It is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions are fully covered in the schema (100% coverage). The tool description adds no extra semantics beyond the schema, so it meets the baseline but does not exceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 modifies an existing agent ('Modifica los datos de un agente existente'). This distinguishes it from siblings like create_agent and delete_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like save_agent_permissions or other update tools. The description lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It indicates a mutation but fails to explain potential side effects, permission requirements, or consequences of updating default status. The description is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear front-loaded verb and resource. It is concise and includes the mutation hint. However, it could be slightly more structured for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should provide more context about required parameters (calendar_id), return values, and error conditions. It is too minimal to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, providing clear descriptions for each parameter. The description merely lists the updatable fields, adding minimal semantic value beyond the schema. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Actualizar' (update) and the resource 'calendario', listing specific properties (nombre, descripcion, color, estado por defecto). The '[mutation]' hint further clarifies the action. It effectively distinguishes from siblings like 'create_calendar' or 'delete_calendar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'update_calendar_availability' or 'update_calendar_event'. The description does not 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only adds a [mutation] tag. It does not disclose authorization needs, side effects, or concurrency considerations for a write 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?
The description is a single concise sentence in Spanish with no unnecessary words. However, it could include more information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with many optional parameters and no output schema, the description is too brief. It does not mention return values, the effect of updating specific fields, or any required context like needing an existing service.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions for all 12 parameters. The description adds no additional meaning beyond 'updates properties', 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 updates properties of an existing calendar service/appointment type, using a specific verb and resource. It distinguishes itself from siblings like create_calendar_service and delete_calendar_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or comparison to related update tools like update_calendar or update_calendar_availability.
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?
With no annotations, the description must disclose behavioral traits. It only labels the tool as '[mutation]' but does not explain side effects, error handling, idempotency, or permission requirements. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one clear sentence and a mutation tag. It is front-loaded and contains no filler, though it could be slightly more structured to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (4 params, no output schema), the description still feels incomplete. It omits usage guidance, behavior details, and differentiation from siblings, leaving the agent with unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 tool description adds no further meaning beyond the schema, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update'/'Edit' and the resource 'Customer AI Correction for customer-facing WhatsApp AI'. It distinguishes from the sibling tool 'update_ai_error' by specifying the customer-facing context, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'update_ai_error' or 'set_customer_ai_error'. The description lacks any context about prerequisites, typical use cases, 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?
With no annotations, the description must disclose all behavioral traits. It only states the tool updates an existing rule and hints at mutation with '[mutation]', but does not explain that conditions and actions arrays replace existing ones, auth requirements, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a tag, no wasted words, but it could expand slightly on behavioral details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a mutation tool with 6 parameters and no output schema or annotations. It does not explain that arrays replace existing content, nor describe return values or side 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 coverage is 100% and the description adds a summary of modifiable fields (name, priority, status, conditions, actions), but it omits the required 'id' parameter. The value added is marginal over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing email rule and lists the modifiable attributes (name, priority, status, conditions, actions), distinguishing it from sibling tools like create_email_rule and delete_email_rule.
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 create_email_rule or list_email_rules, nor does it 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 are absent, so description must fully disclose behavior. Only [mutation] is provided, but no details on side effects, permissions, or limitations like file size constraints.
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 very short (one sentence) and front-loaded with purpose. However, it lacks structure or additional details that could aid understanding without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return values or results. It does not mention what happens after upload (e.g., attachment ID). Also missing context like file size limits or supported MIME types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with basic descriptions. The description adds no extra meaning beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upload), the resource (email attachment), and includes [mutation] indicating a state change. It distinguishes from sibling tools like download_email_attachment.
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. No mention of prerequisites (e.g., needing an email thread ID) 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?
No annotations provided; the description only includes '[mutation]' to indicate state change. It does not disclose behavioral traits like whether it replaces existing assignments, permissions required, 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 a single sentence with minimal waste. It conveys the core action and includes a '[mutation]' tag for behavioral hint. Could be slightly more structured but 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?
For a mutation tool with 3 parameters and no output schema, the description is minimal. It lacks details on return values, error conditions, or prerequisites, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with clear parameter descriptions. The description adds no new meaning beyond what the schema already provides, meeting the baseline for full 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 verb 'asignar' (assign) and the resources 'agente a calendario' with a specific role. It distinguishes from sibling tool 'unassign_calendar_agent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'unassign_calendar_agent' or other assignment tools. The context does not indicate 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?
With no annotations, the description must disclose behavioral traits. It tags the action as a mutation and explains enable/disable, but it does not disclose side effects (e.g., impact on ongoing campaigns), required permissions, or reversibility. The agent lacks critical safety context for a write 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?
The description is concise (one line) and front-loaded with the action. The [mutation] tag adds context. However, the dash separation is acceptable, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool, the description covers the basic action. But it omits error conditions, response format, and behavior on failure. Given no output schema and the sensitivity of mutating marketing settings, completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it merely restates the boolean parameter's purpose. No additional parameter context 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 verb ('assign'), the resource ('marketing session'), and the action ('enable or disable a WhatsApp session for sending marketing campaigns'). It distinguishes this tool from siblings that update sessions generally (update_whatsapp_session) or configure marketing globally (save_mass_marketing_config).
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 guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It lacks context on prerequisites (e.g., session must exist) or exclusions. The agent is left to infer usage from the purpose alone.
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?
No annotations are provided, so the description bears the full burden. It discloses that the tool is a mutation requiring confirmation, but fails to describe other critical behaviors like overwriting existing connections, authentication requirements, rate limits, or post-connection effects (e.g., syncing data). This is insufficient for a mutation with sensitive credentials.
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 at two sentences, front-loading the purpose and adding a key usage note. It avoids redundancy but could be more structured (e.g., separate sections for purpose, usage, and confirmation). Efficient overall.
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 core purpose and confirmation requirement for a complex tool with 19 well-documented parameters. However, it lacks details on what happens after a successful connection, how to handle errors, or the disconnection process (covered by a sibling). More context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it merely summarizes the action. It provides no extra constraints or formatting guidance beyond what the schema already includes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool connects e-commerce platforms (Shopify, WooCommerce, PrestaShop, VTEX) to search products, orders, and customers. It specifies the core function and supported platforms. However, it does not explicitly differentiate from siblings like 'test_ecommerce_connection', though the purpose is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises asking the user which platform to use and notes that a mutation requires confirmation (confirm=true). This provides basic usage context but lacks guidance on when not to use this tool or alternatives, such as testing a connection first.
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?
No annotations provided. Description does not disclose behavioral traits such as read-only nature, performance implications, or whether it returns a count. It adds minimal context beyond 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?
Description is a single sentence that front-loads the purpose and includes a dash for separation. It is concise and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value (likely a count integer) and does not clarify output format. Given no output schema, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The tool description does not add extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it counts contacts filtered by segment, with specific filter types (tags, recent activity, WhatsApp history). The verb 'contar' and resource 'contacts' are explicit, and it distinguishes from sibling tools like add/remove contacts.
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. The description does not specify when it is appropriate to count filtered contacts versus other operations like listing contacts or importing.
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?
With no annotations, the description carries the full burden. It adds value by mentioning draft/scheduled states and template variables, but does not disclose side effects, return value, or required permissions. The [mutation] tag hints at write behavior but is not part of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a tag, concise and front-loaded with purpose. No wasted words, though more detail could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, no output schema, and complex behavior (draft/scheduled, variables), the description covers key points but lacks details on post-creation actions, how to start later, or permission requirements. Adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 only repeats information already in parameter descriptions (e.g., template variables). It adds no new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new marketing campaign (verb 'Crear' and resource 'campana de marketing'), supports draft or scheduled creation, and mentions template variables. It distinguishes from siblings like start_campaign, but does not explicitly contrast with other create tools like create_contact_list.
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., duplicate_campaign, create_scheduled_message). No prerequisites or exclusions mentioned. The description implies the tool is for creating campaigns but does not help an agent decide between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as a mutation and requires confirmation to execute, disclosing its destructive nature. However, annotations are absent, so the description carries the full burden. It lacks details on permissions, side effects, or what happens after deletion.
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 clauses) and front-loaded with the action and resource. It is concise but slightly incomplete due to missing usage guidance.
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?
No output schema exists, and the description does not explain return values or confirm success. It warns about confirmation but omits other behavioral details. For a simple tool with 3 params, the description is minimally acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage). The 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (eliminar) and resource (archivo de conversacion). It distinguishes from siblings by specifying 'conversacion', though it doesn't explicitly contrast with similar deletion tools. The [mutation] tag further clarifies the nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'delete_conversation_message' or 'delete_docqa_file'. The confirmation requirement is mentioned but not framed as a usage condition.
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?
No annotations are provided, so the description carries the full burden. It discloses the permanent deletion nature and the mutation aspect, plus the confirm requirement. However, it lacks details on effects, reversibility, or permissions beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the action and includes necessary execution constraint. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 7 parameters, the description is insufficient. It fails to explain why pagination/filtering parameters exist in a delete-by-id tool, leaving the agent confused about proper usage. The mutation tag and confirm note are helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, setting baseline at 3. The description adds the confirm parameter's role, but does not clarify the purpose of limit, offset, filter, type, agent_id, which seem unrelated to deleting a single notification. This creates ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a notification permanently, with the verb 'Elimina' and resource 'notificacion'. It distinguishes the action as a mutation. However, it does not differentiate from sibling delete tools for 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the need for a confirm parameter to execute, but provides no guidance on when to use this tool versus alternatives like 'mark_notification_read' or other delete tools. No context on 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?
The description states it returns a download URL, but does not disclose behavioral details such as side effects, authentication requirements, rate limits, or whether the file is actually downloaded. With no annotations, this is insufficient for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single line in Spanish. It front-loads the purpose effectively. However, it could be slightly more structured (e.g., separate sentences for purpose and return value).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description should explain the return value and any necessary context. It does mention 'URL de descarga', but lacks details on format, error handling, or prerequisites. The tool is simple, so completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 (file_uuid), so baseline is 3. The description does not add meaning beyond the schema; it merely repeats the idea of downloading a file. No additional clarity on how to obtain the UUID or any constraints 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's purpose: 'Descargar archivo de conversacion — Obtiene la URL de descarga de un archivo compartido en una conversacion'. It specifies the action (download/get URL) and the resource (conversation file), which is distinct from sibling tools like delete_conversation_file or list_conversation_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when or when not to use this tool, nor any prerequisites (e.g., needing the file UUID from list_conversation_files). Without such context, an AI agent may misuse the tool or waste time guessing.
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?
No annotations are provided, so the description carries the full burden. It reveals two modes: redirect vs JSON URL response via the 'json' parameter. However, it does not mention error handling, permissions, or what happens when an attachment is not found.
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 (one sentence) and to the point. It avoids unnecessary detail, though the '[query]' placeholder seems out of place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, no nested objects), the description is adequate but lacks details on return value format (beyond URL), error conditions, and behavior without the 'json' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value: it paraphrases the action but does not explain the 'query' mention or provide additional context for the 'attachment_id' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Descargar adjunto de email' (download email attachment) and 'Obtiene la URL de descarga' (obtains download URL). It distinguishes from sibling tools like 'upload_email_attachment' and 'download_conversation_file'. However, the inclusion of '[query]' is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools like 'download_conversation_file' or 'get_email_thread_detail' might also involve attachments, but no usage context 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?
No annotations provided, but description implies read operation (get logs). Does not explicitly state read-only or any side effects, but adequate given the 'get' nature.
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, but includes a stray '[query]' placeholder. Efficient but not perfectly 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?
Sufficient for a logging tool with pagination implied by parameters. Lacks mention of return format or log details, but acceptable without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are documented in schema (100% coverage). Description adds minimal value beyond mentioning campaign specificity. Page and limit are not elaborated.
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?
Describes retrieving progress and sending logs for a specific campaign, differentiating from get_campaign. However, language mix (Spanish/English) and lack of explicit differentiation from other log tools slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_campaign, other log tools). The description only states what it does.
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?
No annotations are provided, so the description carries full burden. It only states it gets configuration without mentioning side effects, permissions, or output format. The '[query]' suffix is ambiguous and does not clarify behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but includes an unnecessary '[query]' tag that may confuse the agent. It is concise but could be cleaner without the tag.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return structure. It lists fields but not their format (e.g., JSON object). For a tool with no parameters and no annotations, more detail on output is needed for complete agent 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?
There are no parameters (0 params, 100% schema coverage). The description does not need to add parameter details, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves mass marketing configuration and lists specific fields (auto-response, unsubscribe text, approval). It distinguishes itself from the sibling tool 'save_mass_marketing_config' which is the write counterpart.
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 others. Usage is implied (to get current config), but no when-not or alternatives are provided. The presence of a save sibling suggests a read context, but not stated.
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?
No annotations are provided, and the description only says it 'shows the progress'. It does not disclose behavioral traits such as authentication needs, error conditions, or whether it's a simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) with no redundancy. It gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description is adequate but lacks details about the output format or how to interpret the returned data. It could be more 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?
The tool has no parameters, so the schema covers everything. The description adds no extra parameter info, but baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool shows the user's initial configuration progress (onboarding status). It specifies the verb 'View' and the resource, but does not distinguish it from many sibling 'get_' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits. It does not state that the tool is read-only, whether it requires specific permissions, or if pagination is implicit. The term 'stats' implies read-only, but this is not explicit.
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, listing key statistics in a single sentence. However, the trailing '[query]' appears to be a placeholder and may confuse users slightly. It is otherwise well-structured and front-loaded with the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stats tool with 8 parameters and no output schema, the description covers what metrics are returned but lacks details on output format, pagination behavior, or prerequisites. It is 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?
The input schema has 100% coverage with descriptions for each parameter. The description adds no extra parameter meaning beyond listing the output metrics. Baseline of 3 is appropriate since the schema already documents the parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 Smart Follow-up statistics, specifically sales recovery metrics like conversion funnel, response rate, etc. This distinguishes it from siblings like get_smart_followup_config (configuration) and get_smart_followup_logs (logs).
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. For example, it does not mention that get_smart_followup_config should be used for viewing settings, or that get_smart_followup_logs is for detailed logs. The description only explains what the tool does, not when to choose 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?
With no annotations, the description must disclose behavioral traits. It briefly explains the purpose but fails to state that it is a read-only operation, any required permissions, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively front-loads the key information without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description lacks completeness. It does not explain what the response contains, how results are sorted, or how to apply parameters 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?
The schema provides descriptions for 3 of 4 parameters (75% coverage). The description adds no additional explanation for parameters; 'limit' lacks both schema and description context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool identifies unanswered plugin questions where the bot failed to provide a satisfactory answer. This distinguishes it from sibling tools like get_recent_plugin_questions or get_plugin_conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when it is appropriate, nor does it reference related tools.
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?
With no annotations, the description must convey behavioral traits. It only marks the tool as a mutation via [mutation] tag, but does not disclose how duplicates are handled, whether existing list contacts are overwritten, permissions needed, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short phrases covering purpose and mutation. No unnecessary words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no output schema), the description could be more complete. It omits details like the scope of 'all conversations', behavior on duplicates, and whether a result is returned. This leaves ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter with a description (ID de la lista destino). The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (import all contacts from WhatsApp conversations into a marketing list) and distinguishes it from sibling import tools by specifying 'all conversations' rather than selected ones. The bilingual text and [mutation] tag further clarify the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as `import_contacts_from_conversations` or `import_contacts_csv`. The name hints at scope, but the description lacks when/when-not/alternative directives.
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?
With no annotations, the description should fully disclose behavior. It marks [mutation] but does not explain side effects like whether contacts are added or replaced, what happens if list_id is invalid, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one line) and includes a helpful [mutation] marker. It is appropriately front-loaded, though could be slightly more structured without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core purpose but lacks details on the source (how conversations are selected) and the behavior (e.g., duplicate handling). It is minimally 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?
The schema has 100% coverage for the single parameter list_id, and the description repeats the same info ('ID de la lista destino') without adding extra meaning, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (import), resource (contacts from conversations), and target (marketing list), distinguishing it from sibling tools like import_contacts_csv or import_contacts_from_all_conversations by mentioning 'selected contacts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like import_contacts_csv or import_contacts_from_all_conversations. There is no mention of prerequisites or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should explicitly disclose read-only nature. While 'Lista' implies a read operation, it does not state that it has no side effects or requires specific permissions. It adds minimal behavioral context beyond the action.
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 segments separated by an em dash. It is front-loaded and to the point. The inclusion of '[query]' is slightly unclear 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?
Given no output schema or annotations, the description outlines the return value (list of agents with roles) adequately. However, it lacks details on pagination, filtering, or scope (e.g., active/inactive agents), which are typical for a listing 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 a clear 'calendar_id' description. The description adds no extra meaning for the parameter; it only describes the output (agents with roles). Baseline score applies since schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists calendar agents assigned to a specific calendar, including their roles. This differentiates it from generic agent listing tools like 'list_agents', though it doesn't explicitly contrast with siblings like 'assign_calendar_agent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or compare to related tools like 'assign_calendar_agent' or 'list_agents'.
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 indicates a read-only operation (listing events) but does not disclose details like pagination, ordering, or whether historical events are included if the 'to' date is in the past. Despite the absence of annotations, the basic behavior is adequately implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single line. It is front-loaded with the tool's name and purpose, but could be slightly more structured by separating the title from the explanation.
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 lack of output schema, the description covers the basic scenario but omits details like pagination, event ordering, or whether the 'upcoming' qualifier restricts results to future dates. It is adequate for a simple list tool 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?
The input schema already provides clear descriptions for all three parameters (date format, status values). The description adds minimal extra meaning beyond stating the overall purpose of listing events in a date range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Calendar Events', and specifies the date range scope. However, it does not differentiate from the sibling tool 'list_calendar_events_ops', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only states what it does, not the context for use.
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?
No annotations are provided, so the description is the sole source. It states the tool shows scheduled emails, but does not disclose read-only nature, authentication needs, rate limits, or pagination behavior. Minimal behavioral context beyond the basic functionality.
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 one sentence conveying the core purpose. It is concise, though the appended '[query]' is cryptic and could be integrated better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 7 parameters and no output schema, the description is adequate but not complete. It does not explain the return format, default behavior, or edge cases. However, the functionality is straightforward, so a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters. The description does not add any additional meaning beyond what the schema already provides, achieving the baseline score 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 the tool lists scheduled emails that are set to be sent in the future. It is a specific action on a resource and distinguishes it from sibling tools like cancel_scheduled_email or list_scheduled_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when not to use it or compare with other listing tools like list_scheduled_messages or list_campaigns.
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?
No annotations are provided. The description only adds a [mutation] tag, indicating it's a write operation, but lacks details on side effects, reversibility, required permissions, or what happens to the snippet after rejection.
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 (one sentence with a prefix), front-loading the purpose. It is concise but could benefit from a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation and single parameter, the description is minimally adequate. However, it does not explain what constitutes a 'pending snippet', the consequences of rejection, or if there are any constraints, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'id', and the description repeats the schema description exactly. No additional meaning is added beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it rejects a pending knowledge snippet, using a specific verb and resource, and is distinguishable from siblings like approve_knowledge_snippet, edit_knowledge_snippet, and delete_knowledge_snippet.
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., approve, edit, delete). The description implies it's for pending snippets but does not specify prerequisites or scenarios.
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?
No annotations provided, and the description only marks it as a 'mutation' but does not disclose destructive nature, reversibility, permissions needed, or side effects (e.g., what happens if list_id is invalid).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear action and resource. No unnecessary words; includes [mutation] hint. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing details on return behavior (e.g., success/failure counting), idempotency, and edge cases (e.g., non-existent contact IDs). With no output schema, description should compensate but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so description adds no extra meaning. Baseline 3 is appropriate as the schema already documents each 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 tool removes multiple contacts from a marketing list, with the explicit verb 'Eliminar' (delete) and resource 'contactos en bloque' (bulk contacts). It distinguishes from the sibling 'remove_contact_from_list' by implying bulk operation.
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 'remove_contact_from_list' for single contacts. The description lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool 'searches for the email' using CRM and e-commerce, implying a read-only operation, but it does not explicitly disclose whether the tool modifies data, what happens if no email is found, or any other behavioral traits. The description lacks sufficient detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Spanish. It includes the core purpose. It is front-loaded but could benefit from being slightly more structured (e.g., listing CRM and e-commerce as data sources). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema or annotations, the description is minimally adequate. It explains what the tool does but does not cover return format, error handling, or usage context. It is complete enough for a simple lookup but lacks richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage (one parameter with description). The tool description adds no extra meaning beyond the schema's description of 'phone_hash'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: resolving an email contact by searching for the email associated with a WhatsApp contact using CRM and e-commerce platforms. The verb 'resolve' is specific, and the resource (email contact) is distinct from siblings like 'search_email_contacts' or 'get_crm_customer'.
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 versus alternatives. It does not mention prerequisites, exclusions, or when not to use it. With many sibling tools, such guidance is essential.
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?
No annotations provided, so description carries full burden. It only adds the mutation hint and status list, but fails to disclose permissions, reversibility, side effects, or notifications.
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 a single sentence with a mutation tag. It is front-loaded and concise, though language (Spanish) may not be ideal for some agents. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the basic purpose and status values. However, it lacks usage context and behavioral details, making it minimally 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 clear parameter descriptions. The description adds no new semantic meaning beyond the schema, merely restating the status options in a different 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 action ('Cambiar estado de evento'), the resource ('evento de calendario'), and lists all possible statuses. It distinguishes from sibling tools like 'update_calendar_event' which updates other fields, and 'create_calendar_event' which creates events.
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 guidelines on when to use this tool versus siblings (e.g., update_calendar_event for non-status changes). No prerequisites or when-not-to-use 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only notes '[mutation]' but fails to disclose side effects, authorization requirements, or outcome upon success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. No unnecessary words or repetition, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite full schema coverage, the tool has 13 parameters and no annotations or output schema. The description lacks information about returned data, required permissions, error conditions, or typical usage flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds no extra meaning beyond the schema; it merely states 'modifica la configuracion', which is already inferred from the tool name and 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 'Actualizar asistente Doc Q&A' indicating update of a specific resource, and includes '[mutation]' to hint at the operation type. It distinguishes from create and list tools for the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only states the action without usage context.
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?
With no annotations provided, the description carries the full burden of disclosure. It briefly mentions the modes (draft/automatic) but does not explain side effects (e.g., overriding existing settings, authorization requirements, rate limits). The [mutation] tag is present 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, consisting of two sentences and a [mutation] tag. No redundant information. It front-loads the purpose and action. However, it could benefit from a slightly more structured breakdown of features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation) and lack of output schema, the description is somewhat lacking. It covers the core functionality but omits details about scheduling limits and thread limits (though the schema covers them). No mention of return values or confirmation. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 7 parameters with 100% coverage, including the mode and schedule fields. The description adds marginal value by explaining that the tool can generate drafts or send automatic replies, which maps to the mode parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Configurar' (configure) and the resource 'auto-responder de email', and explains the two modes (draft or automatic). It distinguishes the tool from siblings like generate_email_draft and update_email_account by focusing on the autoresponder configuration.
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., generate_email_draft for one-off drafts, or update_email_account for other account settings). It does not mention prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description tags the tool as a mutation but provides no details on side effects, authorization, or scope (e.g., affects all users). Without annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus tag), leaving no wasted words. Could be slightly more informative, but it is 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?
For a simple tool with one parameter and no output schema, the description is adequate but lacks behavioral context like reversibility or user impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 enum descriptions. The description adds no parameter meaning beyond the schema, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes the language of the dashboard and AI responses, using a specific verb ('Cambiar') and identifying the resource. It is distinct from siblings as no other tool is about language.
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 or avoid this tool. The description does not mention alternatives or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only notes [mutation] but lacks details on reversibility, permissions, or side effects. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before 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: one line front-loads the purpose, with no wasted words. Despite being in Spanish, it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description is too sparse. It does not explain behavior like append vs replace, or what the tool returns after mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, so baseline is 3. The description adds high-level grouping but 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 it configures order prefixes and phones/emails to ignore, with a [mutation] tag indicating modification. This distinguishes it from siblings like update_agent or update_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It only implies context for order settings, but does not provide 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description tags the tool with '[mutation]' indicating state change, but there are no annotations to supplement. It does not disclose potential side effects, permission requirements, or what happens after the timezone is updated. For a mutation tool with no annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point. It includes a useful [mutation] tag. However, it is sparse and could be expanded briefly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, no output schema), the description is minimally adequate. It explains the purpose and parameter format. However, it lacks details on scope or confirmation of the change.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter with format guidance (IANA). The description adds no extra meaning beyond restating the purpose. With 100% schema coverage, baseline is 3, but the description fails to add value, hence a lower score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Cambiar zona horaria' (change timezone) and explains the purpose: to display dates and times correctly. It is a specific verb with a specific resource, and no sibling tool directly overlaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when timezone display is incorrect), but provides no explicit guidance on when not to use it or mention of alternatives (e.g., update_date_format is a sibling). No usage context is given.
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?
With no annotations present, the description carries full responsibility for behavioral disclosure. It marks the tool as a '[mutation]', which is helpful, but fails to explain side effects (e.g., what happens if list_id is invalid, duplicate contacts behavior, permission requirements). The example 'update_drive' with similar minimal transparency received a 2, which is consistent here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences. It front-loads the purpose and includes the mutation marker without any fluff. Every word earns its place, adhering to the principle of minimal necessary 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?
For a simple tool with two parameters and no output schema, the description covers the basic purpose. However, it lacks contextual details such as error handling, prerequisites (e.g., existence of list), and potential side effects. Given the lack of annotations, it could be more comprehensive to guide an agent 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?
Schema coverage is 100%, and the schema already describes both parameters ('list_id' and 'contacts') with clear details. The description adds only that contacts are 'one or more' and that it's a marketing list, which does not significantly enhance understanding 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 contacts to list' and elaborates with 'Añade uno o más contactos a una lista de marketing', specifying the resource (marketing list) and the operation (adding contacts). This distinguishes it from sibling tools like 'remove_contact_from_list' or 'create_contact_list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'import_contacts_csv', 'bulk_add_to_blacklist'), nor are prerequisites or exclusion conditions mentioned. The agent is left to infer usage solely from the tool's name and short description.
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?
With no annotations, the description must fully disclose behavior. It only marks the tool as a mutation. No details about side effects (e.g., behavior if number already opted out), required permissions, reversibility, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but is written entirely in Spanish (Spanish can be inferred from context). The single sentence is efficient, though it could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It does not explain return values, validation, or behavior. For a mutation tool, more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear descriptions for both parameters (phone with international prefix, reason as optional). The description adds no additional 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 verb (add), the resource (contact to WhatsApp opt-out), and the purpose (prevent automatic messages). It is distinct from sibling tools like remove_whatsapp_optout and list_whatsapp_optout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to opt out a number) but does not explicitly state when not to use, prerequisites (e.g., connected WhatsApp), or alternatives among siblings. Some guidance is implied but not explicit.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It includes "[mutation]" to indicate a write operation, but does not describe side effects (e.g., whether existing lists are modified, permissions needed, rate limits, or return details). This is minimal 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 a single sentence, concise and front-loaded with the main purpose. However, it lacks structure (e.g., separate parameter descriptions or usage notes) and could be considered slightly under-specified. Still, it is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is incomplete. It does not mention the return value (likely the created list's ID), prerequisites (e.g., Smart Follow-up must be enabled), or potential errors. A more complete description would clarify what the tool returns and when it fails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already described (name and period with enum). The description does not add any additional meaning or context beyond what the schema provides, 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 tool's purpose: creating a contact list from conversations detected by Smart Follow-up. The verb "Crear" and resource "lista de contactos desde conversaciones" are specific, and the sibling tools like create_contact_list and create_list_from_inactive are differentiated by the source (Smart Follow-up).
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 context (when you want to create a list from Smart Follow-up conversations) but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it or provide prerequisites. The guidance is implicit rather than explicit.
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?
No annotations are provided, so the description must carry the full burden. It includes a [mutation] tag indicating data modification, but lacks details on side effects, permissions, or return value. Minimal behavioral context beyond the mutation flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a mutation tag. It is efficient but could be more structured with key information front-loaded. However, it is not verbose and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters (many optional) and no output schema, the description is too minimal. It does not explain what happens upon creation, prerequisites, or what the return value is. More context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (91%), so the schema already documents parameters. The description adds only that the task is optionally associated with a client and agent, which is reflected in parameters like 'phone' and 'assigned_agent_id'. No additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new task, optionally associated with a client and agent, using the verb 'crear' (create) and specific resource 'tarea'. Among siblings like 'update_task', it distinctly identifies creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating tasks but provides no explicit when-to-use, when-not-to-use, or alternatives like 'update_task' for modifications. Usage context is only inferred.
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?
With no annotations, the description carries the full burden. It includes a '[mutation]' tag indicating state change, but does not disclose if the action is irreversible, what triggers it, or any side effects. More details are needed for confident invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and well-structured. It front-loads the Spanish action and provides an English clarification. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema or annotations, the description is minimally adequate. It lacks details on consequences (e.g., whether the suggestion is permanently removed) but covers the basic 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 coverage is 100%, so the description cannot add much. It restates 'reason' as optional, which matches the schema. No additional 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: 'Descartar sugerencia de entrenamiento' (dismiss a training suggestion) with an optional reason. It effectively distinguishes from siblings like 'apply_training_suggestion' and 'get_training_suggestions' by specifying the dismiss action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like applying or keeping the suggestion. There is no mention of context or prerequisites for dismissing a suggestion.
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?
With no annotations, the description carries full burden. It mentions the output is a statistical summary, but does not disclose if it is read-only, any side effects, rate limits, or response structure. The agent cannot infer safety or cost of invocation.
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 phrases) with no fluff. It is efficiently structured but slightly fragmented. Every word earns its place, though it could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema, many siblings), the description is insufficient. It does not explain how the summary is computed, the meaning of urgency, or how period interacts with date_from/date_to. The agent lacks information 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?
Schema description coverage is 100% but parameter descriptions are basic (e.g., 'Texto de busqueda' for query). The tool description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema already documents parameters, despite lack of enriched 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 it provides a statistical summary of conversations for a period, listing example metrics (total, average satisfaction, urgency). It distinguishes itself from sibling tools like search_conversations or get_conversation_detail by focusing on aggregate statistics.
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 the tool is for obtaining period-based summaries, but it does not explicitly state when to use it versus alternatives (e.g., search_conversations for searching, get_conversation_analytics for detailed analytics). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions what metrics are calculated but does not disclose read-only nature, side effects, auth requirements, or data scope beyond saying '[query]' which is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose effectively. The inclusion of '[query]' is slightly unclear, but overall it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify return values. It lists metrics but does not specify output structure, data format, or scope, leaving gaps for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'phone' described as 'Telefono del cliente'. The description adds no additional meaning beyond the schema, achieving the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Calcula' and the specific resource 'metricas de valor del cliente', listing concrete metrics like pedidos, gasto, antiguedad, interacciones. This distinguishes it from sibling tools like get_customer_info or get_purchase_history.
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 retrieving customer lifetime value metrics but does not explicitly state when to use it over alternatives like get_purchase_history or get_customer_info, nor does it provide 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?
No annotations are provided, so the description must disclose behavioral traits. It only states what the tool does (returns data) without explaining if it's read-only, requires permissions, or any side effects. It adds no behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but includes a confusing '[query]' at the end which may reduce clarity. It is concise but could be more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ID-based retrieval with no output schema, the description gives sufficient high-level context (full data and included agents). However, it could detail return structure or constraints for better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description does not add meaning beyond the schema's 'ID de la cuenta de email', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves full details of a specific email account, using the verb 'Ver detalle' and specifying the resource 'cuenta de email'. It distinguishes from sibling 'get_email_accounts' by focusing on 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?
Usage is implied by the singular vs plural sibling context, but no explicit when-to-use or alternatives are mentioned. The description lacks guidance on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It correctly implies a read-only operation by stating 'list' and 'accessible', but it does not explicitly state safety, authentication needs, or potential side effects. The lack of annotations reduces transparency, but the description is not misleading.
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 (one sentence) and front-loaded with the primary action. However, it includes a redundant '[query]' suffix that adds no value and clutters the text. Slightly detracts from 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 tool is simple with no parameters, but the description could be more complete by noting if all accounts are returned or if there is pagination. The sibling ambiguity is not addressed. Given the simplicity, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema coverage is 100%. The description adds semantic context by stating the returned fields (status and basic configuration), which is helpful but not strictly necessary given no parameters exist. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists email accounts and includes what information is returned (status and basic configuration). However, it does not differentiate from the sibling tool 'list_email_accounts', which has a nearly identical name and likely similar function, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_email_accounts' or other retrieval tools. The description lacks any context such as prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies read-only behavior but does not mention side effects, authentication needs, rate limits, or error handling. The meaning of '[query]' is unclear.
Agents need to know what a tool does to the world before 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—one line with a clear structure. Every part is useful, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (2 parameters, no output schema), the description sufficiently explains the core action but lacks behavioral context like pagination behavior or what happens on error. For a read 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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the parameter descriptions in the schema. No clarification on pagination or thread_id 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 it retrieves all messages of a specific email thread using the verb 'Obtiene' and resource 'detalle de hilo de email'. It distinguishes itself from siblings like list_email_threads or get_email_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_email_threads or get_email_account. There is no mention of prerequisites, context, 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?
With no annotations provided, the description must fully disclose behavior. It only states it shows sentiment evolution over time, but does not describe return format, data freshness, authentication needs, or any side effects. This is insufficient for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus a tag) and front-loaded with the purpose. Every word is justified, but it could be slightly expanded without losing conciseness. Still, it is efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema or annotations, the description is too minimal. It does not explain what the output contains, how to use parameters like days, summary_type, etc., and lacks guidance on expected results. Incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions in the schema. The description adds minimal extra meaning beyond the schema (e.g., the phone parameter usage is already clarified 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 it shows sentiment evolution over time, distinguishing between global and per-phone trends. The verb 'Muestra' and resource 'evolucion del sentimiento' make the purpose explicit, and it is distinct from sibling tool get_sentiment_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint: without phone it shows global trend, but it does not explicitly state when to use or not use this tool vs alternatives like get_sentiment_analysis. No exclusions or alternative tools 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?
No annotations are provided, so the description carries full burden. It indicates a read operation but fails to disclose behavioral traits such as side effects, permission requirements, data freshness, or response format. The trailing '[query]' is unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. Every word adds value, and it is appropriately sized for the tool's simplicity.
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 no parameters, no output schema, and a simple read operation, the description adequately lists the key data fields. However, it could be improved by explicitly noting that no parameters are required and by clarifying the 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 has no parameters (type object, empty), so schema coverage is 100%. The description does not add parameter semantics, but according to guidelines, 0 parameters yields a baseline of 4. The '[query]' suffix is ambiguous but does not affect scoring.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Obtiene' (gets) and resource 'estado actual de la tienda' (current store status), listing specific fields: language, credits, basic configuration. This distinguishes it from similar sibling tools like get_credits_info or get_storage_status, though some overlap may exist with 'basic configuration'.
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 versus alternatives. It lacks context for prerequisites, exclusions, or situation-specific selection, which is problematic given the large number of sibling tools.
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?
No annotations provided, and the description does not disclose any behavioral traits such as pagination, authorization needs, or side effects. It only states what is shown.
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 a single sentence, efficient and front-loaded, but could benefit from slightly more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a detail retrieval tool with 4 parameters and no output schema or annotations, the description lacks information on return format, pagination, and filtering behavior, making it somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows individual detail of each AI query with tokens and costs, distinguishing it from aggregated usage stats.
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 it is for per-query details but does not explicitly state when to use it versus alternatives like get_usage_stats.
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?
With no annotations, the description must carry the behavioral burden. It describes the read operation and expected output contents but does not disclose potential errors, permission requirements, or side effects. The mention of 'sesion conectada' implies a prerequisite, which adds some transparency.
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 a single long sentence that packs many details, which affects readability. It could be broken into bullet points for clarity, but it is not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the main return contents. However, it omits error handling, format details, and does not differentiate from similar tools like 'get_whatsapp_connection_status' adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter 'session_id', which already explains its purpose. The tool description adds no new semantic information beyond reinforcing that the session must be connected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Obtiene' (gets) and the resource 'perfil de WhatsApp', and lists specific sub-elements (name, photo, status, business info), distinguishing it from sibling tools like 'update_whatsapp_profile' or 'get_whatsapp_connection_status'.
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 explicit guidance on when to use this tool versus alternatives. It only implies usage when a connected session exists, but no when-not or alternative tool comparisons are given.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates the tool is read-only ('Obtiene'), but does not explicitly state that no modifications occur, nor does it mention any auth requirements, rate limits, or side effects. The description is minimal in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one line) and front-loaded with purpose. However, the inclusion of '[query]' at the end is unclear and may be a placeholder artifact, slightly reducing clarity. Overall, it's efficient but could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema, no annotations), the description does not fully cover what the tool returns. It fails to hint at the output structure (e.g., template details like name, body, status) and does not explicitly state this is a read operation. The description is adequate for basic understanding but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter 'id' described as 'ID de la plantilla'. The description adds context that it is a WhatsApp message template ('plantilla de WhatsApp', 'mensaje especifica'), which clarifies the type of template, but the schema already conveys the ID concept. 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's purpose: 'Obtiene el detalle de una plantilla de mensaje especifica' (gets the detail of a specific message template). The verb 'Obtiene' and resource 'plantilla de WhatsApp' are specific, and it distinguishes from siblings like list_whatsapp_templates (which lists all templates) and delete_whatsapp_template (which deletes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving details of a single template, but it does not explicitly state when to use this tool versus alternatives like list_whatsapp_templates for listing all templates or update_whatsapp_template for modifications. No exclusion or context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While [mutation] indicates state change, it fails to specify what happens during import (e.g., duplicate handling, overwrite vs. append, validation). Crucial behavioral traits like authorization needs or rollback behavior are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence with a useful tag. Every word earns its place, and there is no redundancy. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is minimally viable. However, it omits important context like return value (success indicator) and file constraints (e.g., max size, character encoding). With many sibling tools, additional differentiation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so parameters are already well-documented. The description adds no additional semantic value beyond the schema, such as clarifying the file's required structure or format. 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 'importar' (import), the resource 'contactos desde CSV' (contacts from CSV), and the destination 'a una lista de marketing' (to a marketing list). The [mutation] tag further clarifies the action type, distinguishing it from read-only tools. This specificity effectively differentiates it from siblings like import_contacts_txt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, file format requirements (e.g., encoding), or edge cases. With many sibling import tools (e.g., import_contacts_manual, import_contacts_from_conversations), the lack of usage direction is a significant gap.
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?
No annotations are provided, so the description carries the full burden. It only notes that this is a mutation via '[mutation]', but does not disclose any behavioral traits such as whether it appends or overwrites contacts, required permissions, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured line with a dash separator. It is front-loaded with the action and resource, contains no redundant words, and is easy to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description provides the core purpose and a minor file format detail. However, it lacks completeness on expected behavior (e.g., duplicate handling, validation, or success/error output). For a simple tool, it is somewhat adequate but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions. The description adds minimal extra meaning by specifying 'one phone per line', clarifying the file format beyond the schema's 'Archivo TXT a importar'. However, this is a minor addition; the schema already covers the essence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 (import contacts), the resource (from a text file to a marketing list), and the format (one phone per line). It distinguishes itself from the sibling tool import_contacts_csv by specifying 'text file' rather than CSV.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like import_contacts_csv or import_contacts_manual. There is no mention of prerequisites, limitations, or context such as 'use for plain text files only'.
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?
No annotations are provided, so the description must carry the burden. It only includes the tag '[mutation]' indicating a write operation, but does not disclose side effects, whether it overrides existing links, or any other behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a tag, making it concise and front-loaded. However, it could be slightly more structured for clarity, especially in a non-English context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple link operation with no output schema, the description lacks context such as prerequisites (e.g., contact must exist), success criteria, or what happens on duplicate links, making it incomplete 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%, so the baseline is 3. The description does not add any additional meaning or constraints beyond the schema's descriptions of 'thread_id' and 'phone'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'vincular' (link) and the resources: WhatsApp contact and email thread, with the purpose of associating conversations. It distinguishes itself from the sibling tool 'unlink_email_contact'.
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 linking a WhatsApp contact to an email thread, but provides no explicit guidance on when to use this tool versus alternatives, nor 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description only states the action without disclosing behavioral traits like pagination, error handling, or response format. It lacks detail beyond the basic function.
Agents need to know what a tool does to the world before 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—one sentence with a title-like prefix. No wasted words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one param, no output schema), the description is minimally adequate but lacks details about response format or pagination. It could be more helpful for agents without additional 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 no extra meaning beyond the parameter name 'calendar_id'. The baseline of 3 is appropriate as the schema already describes it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'appointment types/services configured for a calendar', distinguishing it from sibling tools like list_calendar_events or list_calendar_availability.
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 vs alternatives. Among many list_* tools, the description does not help select this tool over others that list calendar-related entities.
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?
No annotations provided, so description carries full burden. It does not disclose what the tool returns (e.g., file metadata, pagination, permissions). The description only states 'list files', missing essential 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, single line with two languages. Lacks front-loading of key info, but no wasted words. Could be cleaner by separating languages.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. The description fails to explain what the tool returns or any behavioral details. For a list tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter assistant_id described in schema. The description adds no additional meaning beyond 'asistente Doc-QA', which is already in the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists files uploaded to a Doc-QA assistant, using verbs 'Listar' and 'Lista' with specific resource 'archivos de Doc-QA'. Distinguishes from siblings like upload_docqa_file, delete_docqa_file, and list_docqa_assistants.
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 context (list files for a specific assistant) but lacks explicit when-to-use or when-not-to-use guidance. No mention of alternatives or prerequisites.
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?
With no annotations, the description must disclose behavioral traits. It includes '[mutation]' indicating a write operation, but it does not clarify what happens to the rejected snippet (e.g., deleted, archived) or any side effects. The description lacks details on permissions, reversibility, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly communicates the tool's purpose. It is front-loaded with the key action and resource, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (2 required inputs, no output schema), the description provides the core purpose but lacks details on the outcome (what happens to the rejected snippet) and how it integrates with the conflict resolution flow. It is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters fully (ID of conflicting snippet and ID of snippet to keep). The description adds no additional meaning beyond the schema, so it meets the baseline for 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a conflict between knowledge snippets by choosing which one to keep. The verb 'resolves' and resource 'snippet conflict' are specific, and the description distinguishes it from siblings like 'keep_both_knowledge_snippets' or 'reject_knowledge_snippet'.
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 versus alternatives. It does not mention prerequisites, when not to use it, or how to choose between conflicting snippets. The context is implied by the name but not stated.
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?
With no annotations, the description must disclose behavioral traits, but it only mentions the search scope. No information about read-only nature, return format, pagination, or side effects is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a front-loaded action, containing no unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters and no output schema, the description is adequate but incomplete. It omits details like default limit, ordering, and result structure, which would help the agent use it effectively among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description adds no extra meaning beyond the schema. The schema already explains 'query' and 'days', but 'limit' lacks description and the tool's description does not clarify it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Busca productos') and the resource ('productos en tu tienda online o en el CRM'), making it distinct from sibling tools like search_conversations or search_customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative search tools (e.g., search_customers). The description only states the function without 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?
No annotations are provided, so the description must cover behavioral aspects. It includes '[mutation]' indicating state change, but does not clarify whether tags are overwritten or appended. The empty array use case is mentioned, but other behaviors (e.g., idempotency, authorization requirements) are absent. Insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence followed by a brief note. It front-loads the action and includes essential context about free strings and mutation. No wordiness or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with full schema descriptions, the description covers the core action and the empty-array special case. However, it lacks details on return values (no output schema), whether existing tags are replaced or merged, and potential side effects. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds the note that tags are free strings, reinforcing schema info. The schema description for tags includes the empty-array removal case. The description adds marginal extra value, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Establecer etiquetas de hilo de email' (set email thread tags). It specifies the resource (email thread tags) and the verb (set), distinguishing it from sibling tools like update_customer_tags which operate on different entities. 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or situations where another tool might be more appropriate. Given the large number of sibling tools, this omission reduces usability.
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?
Without annotations, the description carries the burden of behavioral disclosure. It only states that it updates agents and includes a custom '[mutation]' tag, but does not explain side effects (e.g., overwriting existing assignments), required permissions, or idempotency.
Agents need to know what a tool does to the world before 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: one sentence plus a mutation tag, front-loading the key action. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no output schema), the description is minimally adequate but lacks context on behavior, permissions, and prerequisites. Schema covers param details, but the tool's purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (id and agent_hashes). The description adds minimal value by using 'Reasignar' (reassign), implying replacement, but the schema already indicates that agent_hashes is the list to assign and an empty array removes all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reasignar agentes de cuenta de email' (reassign agents of email account), specifying both the action (update/reassign) and the resource (email account agents). This distinguishes it from siblings like 'update_email_account' which handles other settings.
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 usage guidelines provided. The description does not mention when to use this tool versus alternatives (e.g., 'update_email_account'), nor does it specify prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a '[mutation]' tag, but annotations are absent, so the description must fully disclose behavioral traits. It fails to mention prerequisites (e.g., account must exist), side effects, or consequences of incorrect folder names, leaving significant gaps for a write 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?
The description is concise with a label, a clear sentence, and a mutation tag. It is front-loaded and efficient, though the structure could be more organized. No unnecessary information, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the complexity of IMAP folder configuration, the description is insufficient. It omits return values, idempotency, and error handling, and does not integrate with related email tools like 'discover_email_folders'. The tool requires more behavioral context for safe 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 coverage is 100% with all parameters described. The description lists the folder types in parentheses, adding minimal context beyond the schema. Baseline 3 is appropriate as the description does not enhance parameter 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?
The description clearly states the tool configures IMAP folder mapping for an email account, specifying the folders (sent, trash, archive, spam). The verb 'Configurar' and resource 'carpetas IMAP de una cuenta de email' are specific and unique among siblings, making 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 mentions it is necessary for bidirectional sync, giving a clear use case. However, it does not provide exclusions (e.g., when not to use) or mention alternatives like 'discover_email_folders' or 'update_email_sync', leaving guidance incomplete.
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?
Discloses that it is a mutation requiring confirmation, but lacks details on side effects, reversibility, or error handling. With no annotations, the description partially covers 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an important note about confirmation. Front-loaded and efficient, though could be better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks context about outcomes of different actions, especially destructive ones like delete. No output schema, so description should compensate but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 meaning beyond the schema. It mentions using filter=pending on another tool but does not elaborate on the parameters here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages knowledge snippets with actions like approve, reject, edit, delete. It uses a specific verb and resource but fails to differentiate from sibling tools that target individual actions.
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?
Gives a usage hint for finding pending snippets and notes confirmation needed, but does not explain when to use this combined tool versus the specific sibling tools.
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?
No annotations are provided, so the description must convey behavioral traits. It only labels the tool as a mutation but does not disclose side effects (e.g., whether old URL becomes invalid, if there's a propagation delay, or if specific permissions are required). This leaves the agent uninformed about consequences of invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise, one sentence plus a mutation tag. Every word is necessary, no fluff. It front-loads the purpose and keeps the message direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is adequate for basic understanding but lacks behavioral and usage context. A minimal viable description, but missing details for the agent to fully assess impact and conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description for 'url_tienda'. The description adds no extra meaning beyond stating it updates the store URL, which is already implied. Baseline score of 3 applies as the schema does the work, and the description does not enhance understanding of 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?
Description clearly states the tool updates the store URL with specific verb 'Actualiza' (updates) and resource 'URL de la tienda'. The mutation tag further clarifies it's a write operation. This distinguishes it from other update tools like update_agent or update_business_info, as it uniquely targets the store URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., for other store-related updates like update_order_settings or update_business_info). There is no mention of prerequisites, exclusions, or scenarios where this tool should not be used.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only labels the tool as a '[mutation]' but fails to describe any side effects, permissions required, or constraints (e.g., comment length limit, impact on existing comments). This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single, front-loaded sentence with a '[mutation]' tag. Every word contributes to the purpose. There is no fluff, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters (many optional), the description does not explain why unrelated fields like query, limit, or tag data appear. It lacks any output schema or behavioral details. Given the complexity and numerous sibling tools, the description is insufficient for an agent to use the tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 full (100%) description coverage for all 9 parameters, so the baseline is 3. The description itself adds no additional meaning or context beyond the schema; it only states the tool's purpose. The presence of seemingly unrelated parameters (query, limit, tag_name, etc.) is not addressed, but schema descriptions already cover them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Anadir comentario') and the resource ('a cliente'), specifying it's an internal comment added to a customer's file. The tag '[mutation]' further clarifies the operation type. This clearly distinguishes it from sibling tools like add_customer_tag or add_email_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?
The description implies the tool should be used to add internal comments to customer profiles, but it does not provide explicit guidance on when to use it versus alternatives (e.g., add_email_note, get_customer_comments), nor does it specify any prerequisites or context for usage.
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?
No annotations are provided, so the description must fully disclose behavior. It only includes '[mutation]' indicating a state change, but omits details like permissions, error handling, 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 very brief with two short sentences and a tag, conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description covers the basic purpose and visibility. However, it lacks details on return values, prerequisites, or behavior on failure, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds no additional meaning beyond the schema, meeting the baseline for a covered 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 function: adding an internal note to an email thread, visible only to agents. It distinguishes itself from sibling tools like 'add_customer_comment' or 'delete_email_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?
The description mentions 'Solo visible para agentes', giving context on visibility. However, it does not provide guidance on when to use versus 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It includes a '[mutation]' tag indicating a write operation but lacks details on authorization, rate limits, or consequences of blocking an already-blocked number.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences that front-load the purpose. Every word contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a clear purpose and full schema coverage, the description adequately explains the core function. However, it omits details about side effects or global scope, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description adds minimal value. It does not provide additional nuance beyond the schema's parameter 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 verb 'add' and resource 'phone to blacklist', and explains the purpose of blocking a phone from receiving marketing campaigns. It distinguishes itself from siblings like 'remove_from_blacklist' and 'bulk_add_to_blacklist'.
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 explicitly state when to use this tool versus alternatives like 'bulk_add_to_blacklist' or 'remove_from_blacklist'. No guidance on context or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It labels itself as a mutation and states it activates the snippet, but does not disclose side effects, permissions, or whether the operation is reversible. Minimal behavioral information.
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 purpose. However, the bilingual structure (Spanish then English-like) is slightly redundant. Still, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the basic action. However, it lacks context about the approval workflow or how it fits with sibling tools, which could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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. The description does not add any additional meaning beyond what the schema already provides, so it meets 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 the action 'approve' and the resource 'knowledge snippet', indicating it activates a pending snippet. The sibling tools include reject, edit, and delete, which are distinct, so the purpose is well-defined.
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 by mentioning 'pending snippet', but does not explicitly state when to use this tool versus alternatives like reject_knowledge_snippet or edit_knowledge_snippet. No guidance on prerequisites or workflow context.
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?
With no annotations provided, the description carries the full burden. It indicates a read-only check ('check', 'query'), but does not explicitly state it is non-destructive, nor does it disclose any other behavioral traits like rate limits or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with a title-like phrase. However, there is slight redundancy between the first phrase and the second sentence. Generally 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?
For a simple 1-parameter tool with no output schema, the description covers the purpose and parameter adequately. However, it does not hint at the return type (e.g., boolean or list), leaving a gap in 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% (one parameter fully described in schema). The description adds a minor clarification ('con prefijo internacional') but does not provide significant 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 tool's purpose: checking if a phone number is in the WhatsApp opt-out list. It uses a specific verb ('verificar' / 'comprueba') and resource ('opt-out list'), and it distinguishes itself from sibling tools like 'add_whatsapp_optout' and 'remove_whatsapp_optout'.
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 the tool should be used to verify opt-out status, but does not explicitly state when to use it versus alternatives, nor does it provide any context about prerequisites or limitations.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It includes '[mutation]' indicating state change, but omits crucial details: side effects (e.g., rule activated immediately?), permission requirements, validation of conditions/actions, success/failure behavior, or limits on number of rules. The description is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a tag. It front-loads the purpose and immediately explains capabilities with examples. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having 4 parameters and no output schema, the description does not address return values, error states, or post-creation behavior. It is incomplete for a creation tool, leaving the agent uncertain about what happens after successful execution or how to reference the new rule.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for each of the 4 parameters. The description does not add new semantic meaning beyond what the schema already provides; it merely gives examples of conditions and actions. Baseline score of 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new email rule, with specific verb 'Crear' (create) and resource 'regla de email'. It describes the rule's function: filtering incoming emails by sender, subject, etc., and executing actions like archive, label, or assign agent. This differentiates it from sibling tools like update_email_rule or list_email_rules.
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 the tool is used when one needs to create a new email rule, but it does not provide explicit guidance on when to use it versus alternatives (e.g., when to update instead). It lacks context about prerequisites or exclusions, such as requiring existing email accounts or permission checks.
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?
No annotations provided. Description mentions connection to IMAP but does not state whether the operation is read-only or if it modifies anything. For a discovery tool, read-only behavior is likely but not confirmed, 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?
Two sentences conveying the core function efficiently. The inclusion of [query] is slightly unclear but does not detract significantly. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one param, no output schema, no annotations), the description covers the tool's purpose but fails to describe the return value format or any prerequisites. The [query] placeholder adds confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 aligns with schema (ID of email account) but does not add new information beyond what the schema's description 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 discovers IMAP folders by connecting to an email account's IMAP server. It specifically mentions standard folders (Sent, Trash, Archive, Spam) and automatic detection, distinguishing it from tools like update_email_folders.
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 after an email account is set up, but lacks explicit guidance on when to use vs. alternatives like update_email_folders or get_email_accounts. No prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions pagination and search but does not disclose behavior such as default page size, sorting order, handling of invalid list_id, or whether the response includes total counts. This is minimal disclosure beyond what the input schema already provides.
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: a title-like first part and a brief explanation. It is concise and front-loaded with the core action. Every word serves a purpose, though the Spanish language may slightly reduce clarity for English-speaking agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description is adequate but incomplete. It covers the main functionality (get contacts with pagination and search) but does not mention error handling, default behavior, or the structure of the response. It is sufficient for basic usage but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 three parameters have descriptions). The description adds 'paginación y búsqueda' which restates the schema's page and search parameters without additional meaning. Since coverage is high, baseline 3 is appropriate; the description does not compensate for missing schema 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 tool retrieves contacts from a specific list with pagination and search. The verb 'obtiene' (gets) and resource 'lista de contactos' (contact list) are specific, and the inclusion of pagination and search distinguishes it from sibling tools like list_contact_lists or add_contacts_to_list.
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 instructions are provided. The context is implied by the tool name and description, but there is no guidance on alternatives or prerequisites. The agent must infer from sibling names that this is for viewing details versus other operations like adding or removing contacts.
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?
No annotations provided, so the description should fully disclose behavior. It only states it shows complete messages, lacking details about whether it requires authentication, if it's read-only, or if there are limits. Does not contradict annotations (none exist), but fails to compensate for missing annotation 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?
Very concise, one-sentence description that front-loads the tool's purpose. No wasted words. Could possibly benefit from structured formatting, but efficiency is achieved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool without an output schema, the description is minimally adequate. It does not specify return format or completeness guarantees, but given the tool's straightforward nature, it covers the basics.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (one parameter with description). The parameter 'session_id' is clearly described as the chat session ID. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete messages of a plugin conversation, distinguishing it from sibling tools like get_plugin_conversations (likely lists) or get_conversation_detail (non-plugin). The verb 'Muestra' (shows) and specific resource 'detalle de conversacion de plugin' 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?
No explicit guidance on when to use this tool versus related tools like get_plugin_conversations or get_conversation_detail. The context is implied but not stated. With many sibling tools, the agent may need more direction.
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?
With no annotations, the description carries full burden but only lists output fields (customers, intent, product, outcome, message). It does not disclose that the tool is read-only, that results are paginated (20 per page), or any other behavioral traits like 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key purpose. It is appropriately sized with no unnecessary words, though it could be slightly restructured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description provides a reasonable overview of the log content but lacks details on pagination, filtering behavior, and default ordering. It is adequate but not fully comprehensive 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.
Parameters3/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 all 8 parameters. The tool description adds no additional meaning beyond what the schema provides; it only mentions output fields. Therefore, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists Smart Follow-up activity logs, detailing which customers were contacted, intention level, product mentioned, outcome, and sent message. This verb+resource combination is specific and distinguishes it from sibling tools like get_smart_followup_stats (statistics) or preview_smart_followup (preview).
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. Despite numerous sibling tools related to Smart Follow-up (e.g., get_smart_followup_config, preview_smart_followup), it does not explain when logs are appropriate instead of stats or config.
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?
No annotations provided, so description carries full burden. It mentions date filters but does not explicitly state it is read-only or non-destructive. Does not describe pagination behavior or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence in Spanish is concise and front-loaded. However, it lacks structure (e.g., separate usage note) and could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is minimal. It does not explain the return format, ordering, or default pagination beyond schema defaults. Adequate but has 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?
Input schema covers all 5 parameters with descriptions (100% coverage). Description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the execution history of WhatsApp Auto workflows with date filters, using the verb 'obtiene' and specific resource 'historial de ejecuciones de workflows WhatsApp Auto'. It distinguishes from sibling tools like get_workflow_logs or get_whatsapp_message_logs.
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. Sibling tools like get_workflow_logs could be confused, but no explanation of when to prefer this one.
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?
No annotations are provided, so the description must disclose behavioral traits. It only marks the tool as [mutation] but does not describe what happens to existing contacts, error handling, or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose. No redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation that integrates with external platforms, the description lacks context on prerequisites (e.g., connected ecommerce account), async behavior, or potential impacts. This makes it harder for an agent to gauge completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with list_id described as 'ID de la lista destino'. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it imports contacts from an ecommerce platform and lists examples (Shopify, WooCommerce). This specific verb and resource distinguish it from sibling tools like import_contacts_csv or import_contacts_from_conversations.
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 with connected ecommerce platforms but does not explicitly state when to use this tool versus alternatives (e.g., CSV import). No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description includes '[mutation]' and 'importa' indicating a write operation, but lacks details on duplicate handling, limits, or side effects. With no annotations, the description should offer more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a title-like phrase and a single sentence. It wastes no words, though structured formatting could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic process and parameters but omits return value, error handling, and prerequisites (e.g., needing a previewed file). For a mutation tool with no output schema and no annotations, more detail is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description merely echoes the schema's purpose (specifying phone and name columns) without adding new meaning or constraints beyond the field 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 imports contacts with column mapping from a previewed CSV file, specifying phone and name columns. This distinguishes it from sibling import tools like import_contacts_csv (simpler import) and import_contacts_manual (manual entry).
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 the file must be previewed first and that the user specifies column indices, but it does not explicitly state when to use this tool over alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It includes '[mutation]' and says 'activando los dos', indicating a state change, but lacks details on side effects, permissions, or what happens to the conflict record.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of two short sentences. It is efficient but the first part repeats the second. Front-loads the purpose clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose but lacks contextual details such as post-action state or conflict resolution behavior. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'ID del snippet en conflicto'. The description adds no further 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's action: keeping both conflicting knowledge snippets by activating them. The verb and resource are specific, and it distinguishes from siblings like reject_knowledge_snippet or resolve_knowledge_conflict.
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 the tool is for conflict resolution but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The usage context is inferred from the phrase 'en conflicto'.
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?
No annotations are provided, so the description carries full burden. It implies a read-only operation by stating 'list' and includes a '[query]' tag, but does not explicitly disclose behavioral traits such as side effects, authorization needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short phrases. It is front-loaded with the Spanish title and English explanation, which is slightly non-standard but still efficient. 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?
For a tool with no parameters and no output schema, the description adequately summarizes the returned content (profile details, permissions). It does not mention pagination or format, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter information to add. Baseline score of 4 is appropriate as the description does not need to compensate for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all agents with profile details and permissions. It is specific about the resource and output content. However, it does not explicitly differentiate from the sibling 'list_agents_json', which may indicate different output formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_agents_json' or other list tools. The description lacks context about appropriate use cases or prerequisites.
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?
With no annotations, the description carries the full burden. It mentions listing rules (schedules, exceptions, blocks) but does not specify if the operation is read-only, side effects, permissions, or pagination. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a dash for additional detail. No extraneous information; 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?
For a simple list operation with one parameter and no output schema, the description adequately explains what is returned (availability rules with schedules, exceptions, blocks). It could mention pagination or ordering, but for a straightforward list it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter calendar_id, which has a clear description. The description adds 'de un calendario' but that is redundant. The list of rule types adds context about the output, not the parameter. 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 uses a specific verb 'Listar' and resource 'reglas de disponibilidad de un calendario', clearly distinguishing it from sibling CRUD tools like create_calendar_availability or list_calendar_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives (e.g., list_calendar_events), nor any prerequisites or conditions. The description only states what it does, not when it should be used.
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?
No annotations are provided, so the description carries the burden. It describes the basic behavior (listing calendars from a connection) but does not disclose additional traits like pagination, rate limits, or read-only nature. Score 3 for minimal 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 two sentences (one Spanish, one English) and is concise. However, the bilingual nature is slightly redundant; a single language would suffice. Score 4 for efficiency with minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not mention return format or structure. For a simple list tool, it is somewhat complete, but lacks details on what the output contains. Score 3 for being minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description restates 'ID de la conexion OAuth' for the parameter, adding no new meaning 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available calendars from an OAuth connection (Google/Microsoft) for linking. It distinguishes from sibling 'list_calendars' by specifying OAuth context. A score of 4 is given because while clear, it could explicitly contrast with 'list_calendars'.
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 when linking calendars ('para vincular'), but does not explicitly state when to use versus alternatives or when not to use. No exclusions or alternative tools are mentioned. Score 3 reflects implied but lacking explicit 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?
With no annotations provided, the description bears the full burden of behavioral disclosure. It states it is a mutation and marks notifications as read, but does not mention any side effects, permissions required, or whether the action is reversible. The description is adequate but minimal, missing details like if it only affects current user's notifications or all in the system.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single short sentence followed by a bracketed mutation indicator. It is front-loaded with the key action. However, it could be slightly improved by using a more structured format or including a brief note about filter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description should explain how parameters interact with the 'mark all' behavior. It fails to do so, leaving ambiguity about whether it truly marks all or respects filters. The tool's complexity is not adequately addressed, making it incomplete for effective agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 100% description coverage, so baseline is 3. However, the description does not clarify how parameters like 'limit', 'offset', 'filter', and 'type' apply to a 'mark all' operation, which is confusing. The presence of these parameters suggests selective marking, contradicting the 'all' claim. This reduces the value added by the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it marks all unread notifications as read, with the verb 'mark' and resource 'all notifications'. It explicitly includes '[mutation]' to indicate it is a state-changing operation. The tool name and description distinguish it from the sibling 'mark_notification_read' which suggests a single notification.
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 indicates a bulk operation but does not provide explicit guidance on when to use it versus alternatives like 'mark_notification_read'. Given the sibling list includes both, it would be helpful to mention that for marking individual notifications, the other tool should be used. The lack of this guidance reduces clarity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It correctly signals mutation via '[mutation]' and states 'temporalmente' implying reversibility, but does not disclose permissions, error states, or side effects (e.g., effect on schedule).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line) and includes a helpful mutation tag. It is front-loaded but lacks structure like separate usage or behavior sections. Still, it efficiently conveys core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool (1 param, no output schema), the description is adequate: it explains the action and effect. However, it lacks usage guidance and error context, and does not address relationships with sibling tools like resume_campaign.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 clear description of campaign_id. The tool description adds no extra meaning beyond what the schema already provides, warranting 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 action ('Pausar campana'), the resource ('campana de marketing masivo'), and the temporal nature ('temporalmente', 'en curso'). It distinguishes from siblings like cancel_campaign and resume_campaign by emphasizing temporary pause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., cancel_campaign, archive_campaign) is provided. The description lacks conditionality or differentiation from related operations.
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 tags the tool as '[mutation]' indicating state modification, but lacks annotations and does not disclose side effects, error conditions, or whether the contact must exist in the list. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a dash and a mutation tag, conveying essential information without excess. It is front-loaded with the action, though could benefit from minor structuring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is mostly adequate but lacks clarity about which list the contact is removed from. It states 'de una lista de marketing' but does not specify if the list is implicit or how it is determined, leaving 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?
Schema coverage is 100%, so baseline is 3. The description repeats the schema's parameter description ('ID del contacto a eliminar') without adding context beyond the schema. No extra semantics are 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 verb ('eliminar' / remove) and the resource ('contacto de una lista de marketing'), specifying that it removes an individual contact from a marketing list. This distinguishes it from siblings like 'remove_contacts_bulk' which operates on multiple contacts.
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 'remove_contacts_bulk' or 'remove_unsubscribed_bulk'. It does not specify prerequisites or contexts where individual removal is preferred over bulk operations.
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 are absent, so description must disclose behavioral traits. Only indicates mutation via '[mutation]' but lacks details on side effects, permissions, reversibility, or impact on related 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?
Single sentence that is concise and front-loaded with the action. No redundant or 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 one-parameter mutation tool, the description is sufficient. However, it lacks context about the blacklist's scope (e.g., mass marketing vs. other lists) and confirmation of success/failure 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 coverage is 100% (param has description). Description rephrases the param's purpose ('unlocks a phone number') but adds no additional semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (remove/unblock) and resource (phone from blacklist) using a specific verb. It distinguishes from siblings like 'add_to_blacklist' and 'list_blacklist' by specifying 'remove' and 'unlocks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., bulk removal tools). No prerequisites or exclusions provided, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only indicates mutation via the '[mutation]' tag and states the action, but gives no details about effects (e.g., whether the campaign starts immediately), idempotency, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a tag. It front-loads the action and precondition, with no unnecessary words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what the tool returns (e.g., success confirmation or campaign state). It also lacks details on prerequisites (campaign must be paused) beyond implication, and no error conditions are mentioned. For a simple tool, more completeness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already explains the single parameter (campaign_id). The tool description adds no additional meaning beyond the schema, so baseline score 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 'reanudar' (resume) and the resource 'campaña de marketing masivo' (mass marketing campaign), and includes the precondition 'que fue pausada' (that was paused), which distinguishes it from tools like start_campaign or archive_campaign.
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 the tool should only be used on paused campaigns by stating 'fue pausada,' but it does not provide explicit guidance on when to use this tool versus alternatives like pause_campaign, start_campaign, or cancel_campaign.
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?
No annotations are available, so the description must disclose behavioral traits. It mentions using saved credentials if none provided, but does not clarify whether the test mutates state, requires permissions, or is idempotent. This lack of safety context is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the trailing '[query]' appears out of place and may confuse. Overall, it effectively communicates the core purpose without excess.
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 zero parameters and no output schema, the description provides sufficient context for a simple test tool. However, it lacks details on expected return values or error handling, which would help the agent interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% by default. The description does not add parameter details but is not required to. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tests an e-commerce connection, listing supported platforms (Shopify, WooCommerce, PrestaShop, VTEX). This distinguishes it from sibling test tools like test_shopify_connection, which is platform-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like test_shopify_connection or test_crm_endpoint. The description only states what it does, leaving the agent to infer appropriate scenarios.
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?
No annotations are provided, and the description only adds '[mutation]' to indicate a write operation. It does not disclose potential side effects, whether the toggle is reversible, or if any state changes are immediate or require propagation. The description carries the full burden but provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a brief title. It is front-loaded and efficient, though it could benefit from slightly more structure (e.g., breaking into separate lines for clarity).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean toggle, the description is minimally complete. It explains the action and parameter but lacks details on behavior when already in the desired state, any prerequisites, or confirmation of effect. Given the simplicity, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the only parameter. The description adds 'con structured outputs' which reinforces the parameter's meaning but does not provide additional semantic depth beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 toggles analytics with structured outputs, using specific verbs (activar/desactivar) and identifies the resource (analytics registration for this store). It distinguishes itself from read-only analytics tools like get_analytics or get_structured_analytics.
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 enabling or disabling structured output analytics but lacks explicit guidance on when to use versus siblings, such as when to choose this over get_structured_analytics or other configuration tools. No when-not-to-use or alternative mentions.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it's a mutation but does not explain side effects (e.g., reversibility, permission requirements) or what happens to the-linked 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 a single clear sentence that front-loads the verb and resource. It is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unlink operation with one parameter and a sibling tool, the description covers the basic action. However, it lacks details on return values or behavior when the contact is not linked, which would be helpful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, thread_id, has a schema description that matches the tool description. The description adds no additional meaning beyond what the schema already provides, so 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 action (unlink) and the resource (contact from email thread), and it distinguishes itself from the sibling tool 'link_email_contact' by using the opposite verb. The tag '[mutation]' also clarifies the type of operation.
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 undoing a link, but it does not explicitly state when to use this tool versus alternatives like 'link_email_contact' or other contact management tools. No conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the name change appears in marketing and unsubscription pages, and the [mutation] tag indicates a write operation. However, it lacks details on permissions, reversibility, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences and a mutation tag. All information is front-loaded and no unnecessary text is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation tool without an output schema, the description covers the purpose and effect adequately. However, it lacks usage guidelines and behavioral depth, making it minimally 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?
The sole parameter 'business_name' is fully described in the schema. The description adds value by explaining the effect of the change (where the name is displayed), which goes beyond the schema's type and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates the public business name and provides context about where it appears (marketing messages and WhatsApp unsubscription page). This distinguishes it from general update tools like update_business_info, but does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like update_business_info. It implies usage for changing the business name but does not state 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?
No annotations provided; description only indicates mutation via tag. Lacks details on idempotency, permissions, error handling, or partial updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus tag, front-loaded, no redundant information. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 14 parameters (all optional except one) and no output schema, description provides minimal context. Lacks explanation of update semantics, side effects, or field interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 applies. Description adds no meaning beyond schema; does not explain parameter relationships or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Actualizar') and resource ('contacto existente en el CRM interno'). It includes a [mutation] tag and clearly distinguishes from sibling tool 'create_crm_customer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not to use. The description implies usage for updating existing contacts but offers no guidance on prerequisites or alternatives.
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?
No annotations provided, so description must fully disclose behavior. It labels the tool as [mutation] and mentions confirmation requirement, but does not explain what happens when executed (e.g., whether it overwrites existing endpoints, side effects, or required permissions). The parameters clarify add/remove behavior, but the description itself is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose and a key requirement (confirmation). It is front-loaded with the tool's action. However, it could be structured more clearly with separate notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description provides minimal context. It covers the purpose and confirmation requirement but lacks details on return value, effect on existing endpoints, and prerequisites. The schema descriptions fill some gaps, but overall completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions already present. The description adds the confirmation requirement context, which is linked to the confirm parameter. However, no additional semantic meaning beyond the schema 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 configures CRM endpoints for data synchronization, using specific verb 'Configurar' (configure) and resource 'endpoints CRM'. It distinguishes itself from siblings by focusing specifically on CRM endpoint configuration, even though sibling list includes many update tools, this is unique.
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 that confirmation is required (confirm=true) but does not provide explicit guidance on when to use this tool versus alternatives like test_crm_endpoint or reset_crm_errors. It implies usage for syncing data but lacks exclusions or alternatives.
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?
With no annotations, the description carries full burden. It only declares mutation and partial update. It fails to disclose important behaviors such as password encryption (implied by schema), replacement semantics for agent_hashes, and potential side effects like account validation or reconnection.
Agents need to know what a tool does to the world before 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: one sentence plus a marker. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 19 parameters and no output schema, the description lacks information on return value, prerequisites (e.g., account must exist), and handling of array parameters like agent_hashes which replace current assignments. It is insufficient for a complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds the partial update clarification, but this is largely implied. No additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing email account by modifying its fields, and explicitly mentions partial update semantics ('Solo se actualizan los campos enviados'). It is easily distinguished from sibling tools like create_email_account and delete_email_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 implies usage for modifications via '[mutation]' and partial update note, but does not explicitly state when to use this tool versus alternatives like update_email_autoresponder or update_email_retention. No when-not or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only marks the operation as a mutation but does not address idempotency, error handling, authorization requirements, or effects on existing blacklist entries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that conveys the purpose without unnecessary words. It could benefit from bullet points but remains appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description does not explain return values, success indicators, or error cases. This leaves the agent without enough information to correctly handle the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds no additional meaning beyond the schema's field names and types. No examples or constraints are given for 'phones' or 'reason'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 adds multiple phone numbers to a blacklist specifically for mass marketing. The verb 'Añadir' is specific, and the '[mutation]' tag confirms the operation. It distinguishes from the sibling 'add_to_blacklist' which implies single addition.
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 bulk usage by including 'múltiples' and 'varios', and the sibling 'add_to_blacklist' exists for single additions. However, it lacks explicit guidance on when not to use it or alternatives beyond the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description includes '[mutation]' hint but provides no additional behavioral context such as authorization needs, side effects, or rate limits. With no annotations, the description should carry more 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear structure, front-loading the tool purpose. No unnecessary words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description provides basic purpose and context. However, it lacks information about return values or prerequisites, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters. The description does not add any meaning beyond what the schema already provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (creates a contact list) and the specific resource (contact list for mass marketing campaigns). It distinguishes from siblings like add_contacts_to_list or delete_contact_list.
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 context (for mass marketing campaigns) but does not explicitly state when to use this tool over alternatives, nor does it provide any exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses it is a mutation operation requiring confirmation, which is positive. However, no annotations are provided to supplement behavioral traits, and the description lacks details on irreversibility, side effects, or permissions required, leaving gaps in 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 concise with key information front-loaded: purpose, requirement, mutation tag, and confirmation needed. It could be slightly more structured but efficiently conveys the essential points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values or outcome of success/failure. With no output schema, the agent is left uninformed about what happens after deletion, making it incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 14 parameters have descriptions in the input schema (100% coverage), so the schema does the heavy lifting. The description re-emphasizes the exact message requirement but adds 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?
The description clearly states the tool deletes a specific message from a conversation, using specific verbs and resource. It distinguishes itself from sibling delete tools by specifying 'conversation message' and mentions the requirement of exact text match.
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 basic guidelines: requires exact message text and confirmation via confirm=true. However, it does not explicitly state when to use this tool versus alternatives like delete_conversation_file, nor does it mention prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as a mutation and requires confirmation for execution, hinting at destructiveness. But it does not disclose side effects like loss of integration or data repercussions. With no annotations, more behavioral detail is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a bracketed note, efficient and front-loaded. It wastes no words, but could be slightly more structured (e.g., separate sentence for confirmation).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no output schema, the description lacks essential context: prerequisites (must have active connection), effects post-disconnect, and error scenarios. This gap leaves the agent underinformed.
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% (baseline 3). The description adds value by instructing how to form the platform_type value ('Usa disconnect_ seguido del nombre de la plataforma activa'), aiding parameter selection beyond the schema enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 disconnects e-commerce integration with specific verb 'Desconectar' and resource 'plataforma e-commerce', listing typical platforms. It distinguishes from sibling tools like 'connect_ecommerce' and 'test_ecommerce_connection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (to disconnect) and includes a critical usage note about passing 'confirm=true' to execute the dangerous action. However, it lacks guidance on prerequisites (e.g., active connection) or alternatives.
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?
No annotations are provided, so the description must convey behavioral details. It states 'exporta todos los datos almacenados' but does not explain the return format (e.g., file, link), whether the operation is asynchronous, or any side effects. This lack of behavioral disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys purpose effectively. However, the trailing '[query]' appears to be a formatting artifact and could cause confusion. Otherwise, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (GDPR data export) and the absence of an output schema, the description should indicate what the output is (e.g., a downloadable file, a link). It fails to describe the outcome, leaving the agent uncertain about how to retrieve the exported data.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 one required parameter 'phone' with a description. Since schema coverage is 100% and the description adds no additional meaning beyond what the schema provides, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Exporta' (exports) and resource 'datos del cliente' (customer data), and specifies it is for GDPR compliance (Art. 15 right of access). This distinguishes it from the sibling tool 'gdpr_delete_customer_data' which performs deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for GDPR access requests by citing Article 15. However, it does not explicitly state when not to use it or mention alternative tools like 'gdpr_delete_customer_data'. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fails to disclose behavioral traits beyond the basic read operation. It doesn't mention response format, performance, or error conditions, but for a simple count tool, minimal disclosure is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence in Spanish, front-loaded with purpose. No wasted words, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, description is fairly complete: indicates it counts unread emails across all accounts. Slight omission of return format but acceptable given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline is 4. Description adds value by specifying scope ('across all accounts'), which is not evident from the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns total unread emails across all accounts, matching the tool name. Purpose is specific and distinguishable from siblings like 'get_email_stats' or 'get_email_accounts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only explains what it does, not the context or conditions that warrant its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states it retrieves 'closed conversations', which is a behavioral trait beyond the schema. However, it does not disclose other aspects like rate limits, destructive potential, or pagination behavior beyond the schema parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action. It conveys the core purpose efficiently without redundancy. Slightly more structure could improve clarity, but it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only two parameters, the description covers the essential context: the resource (closed plugin conversations), the key identifier (phone), and a use case. It is reasonably complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, so parameters are already documented. The description adds context ('para un teléfono específico') but no additional 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves closed conversations from the web chat plugin for a specific phone, with a verb ('Ver') and resource. However, it does not explicitly differentiate from siblings like 'get_chat_sessions' or 'get_plugin_conversations', though specifying 'plugin' and 'closed' provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('Útil cuando un agente quiere ver qué ha preguntado un cliente por el chat de la web') but does not include explicit guidance on when not to use it, prerequisites, or alternatives.
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?
No annotations are provided, so the description must fully cover behavioral traits. It only states what is shown (usage and plan) but does not disclose if it makes network requests, caching behavior, or any side effects. This is insufficient for a mutation-free read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, stating the purpose immediately. However, the inclusion of '[query]' is unclear and may be a leftover tag, slightly reducing 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?
For a simple no-parameter status tool, the description adequately covers its function. It explains what it shows (usage and active plan), but lacks details on output format or potential variations. Given the simplicity, it is mostly 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?
The tool has zero parameters (schema is empty object), so schema coverage is 100%. The description does not need to add parameter information. Baseline 4 applies as no additional meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: viewing storage status showing current usage and active plan. The verb 'Muestra' specifies the action, and the resource 'almacenamiento' is distinct from sibling tools which focus on other areas like credits, API usage, or general usage stats.
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_usage_stats or get_credits_info. The description does not provide context for exclusion or comparison with siblings.
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?
No annotations are provided, so the description should disclose behavioral traits. It does not state whether the tool is read-only, requires permissions, or what response format to expect. The mention of '[query]' is ambiguous.
Agents need to know what a tool does to the world before 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 well-structured phrases. No filler words; every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple input schema and no output schema, the description covers the basic purpose and parameter. However, it lacks details on response format, pagination, or error conditions, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (calendar_id) is described in the input schema with 'ID del calendario'. Schema coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists calendar notifications (confirmations, reminders) with a specific verb 'Listar' and resource. It distinguishes from sibling tools like list_calendar_events, list_calendar_availability by explicitly targeting notifications.
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 notifications but provides no guidance on when to use this tool over alternatives, no exclusions, and no prerequisites. It lacks explicit when/when-not instructions.
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?
Description includes '[mutation]' hinting at state change, but no annotations exist. It fails to disclose critical behaviors like whether it replaces the entire order, validates IDs, handles conflicts, or returns a result. The tool's mutation nature and lack of detail lower transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, concise sentence with no filler. It efficiently conveys the tool's purpose and mutation hint without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation tool, the description covers the basic purpose but omits return values, error handling, and prerequisites. Without annotations, more completeness would be beneficial, but it's minimally 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 a description for the 'order' parameter. The tool description does not add any meaning beyond what the schema already provides (array of {id, priority}). Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Reorder workflows' with the specific action of changing execution order of WhatsApp workflows. It uses a specific verb ('Reordenar'/'Reorder') and resource ('workflows'), and distinguishes from siblings like create, delete, update, toggle, or bulk actions.
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 reordering workflows but provides no explicit 'when to use' or 'when not to use' guidance. Given the many sibling tools for workflow management (create, delete, toggle, etc.), the lack of usage context is a gap.
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?
No annotations exist, so the description must fully disclose behavior. It mentions the mutation via '[mutation]' and states the effect (AI can search internet), but omits critical details like persistence, scope (per-conversation or global), or permissions required. This leaves ambiguity about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and a tag—every sentence adds value. The action is front-loaded, and the description is efficient with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle with two parameters and no output schema, the description covers the main behavior and use case. However, it fails to mention the 'prompt' parameter (why it's needed and that it is preserved), which is a notable gap in 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?
Input schema has 100% coverage, so parameters are documented structurally. The description adds no additional meaning to the 'prompt' parameter and does not explain its role beyond what the schema provides. With full schema coverage, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool toggles web search for the AI, with a specific verb ('activate/deactivate') and resource ('web search'). It distinguishes from sibling toggle tools (e.g., toggle_analytics) by naming the exact feature.
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 context—when the AI needs up-to-date internet info (trends, prices, news). However, it does not explicitly state when to avoid using it or provide alternatives, missing guidance on when not to enable or disable.
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?
No annotations are provided, so the description carries full burden. It indicates this is a mutation ([mutation]), requires confirmation, and has an error condition for concurrent runs. But it does not disclose what state changes occur, what side effects happen (e.g., updates to follow-up logs), or the result of a successful execution.
Agents need to know what a tool does to the world before 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 a tag. It is front-loaded with the core purpose, followed by a key constraint, and the mutation and requirement are noted efficiently. No superfluous 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?
For a simple trigger tool, the description covers the essential behavior: what it does, conflict condition, and confirmation need. However, it omits information about the return value (no output schema) and what happens after a successful execution, which may be needed for subsequent tool choices.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 already provides 100% coverage with descriptions for both parameters. The description adds no extra meaning beyond the schema; it merely restates the confirmation requirement. 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 tool triggers Smart Follow-up analysis manually ('Ejecutar Smart Follow-up ahora'). It specifies the action and scope ('para esta tienda') and distinguishes from automatic execution, but doesn't explicitly differentiate from sibling tools like preview_smart_followup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear when-not-to-use condition: if execution is already in progress, it returns an error. However, it does not guide when to use this tool versus alternatives (e.g., preview_smart_followup for dry-run) or mention prerequisites beyond the confirm parameter.
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?
With no annotations, the description carries full burden. It only labels the tool as '[mutation]', but does not disclose potential side effects, required permissions, or error conditions (e.g., if agent not assigned). This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the purpose. There is no unnecessary 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?
For a simple mutation with two parameters, the description is minimal but adequate. However, it lacks context about post-unassignment behavior or preconditions, which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for both parameters ('calendar_id' and 'agent_id'), which are straightforward. The description adds no additional meaning beyond what the schema already conveys, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Desasignar agente de calendario' (Unassign calendar agent) and includes '[mutation]' to indicate a state change. It directly distinguishes from its sibling 'assign_calendar_agent' and 'list_calendar_agents'.
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. While the sibling list implies it is the inverse of 'assign_calendar_agent', no direct guidance or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The [mutation] tag indicates a write operation, but no details are given on side effects, rollback, permissions, or idempotency. The description focuses on the purpose rather than 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences plus a [mutation] tag) and front-loaded with the purpose. The second sentence provides context on the value of updating. No redundant information, but could be slightly more structured (e.g., separating behavior from purpose).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 well-documented parameters and no output schema, the description is nearly complete. It explains what fields are updated and why, fulfilling the needs for invocation. However, missing usage guidelines and behavioral details slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and each parameter has a clear description and enums. The description merely re-lists the fields without adding meaning beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Actualizar') and identifies the resource ('informacion del negocio'). It lists the exact fields updated (business type, sale type, description), clearly distinguishing this tool from siblings like 'update_business_name' and 'update_billing_info'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the information helps AI give more relevant responses, but it does not explicitly specify when to use this tool versus alternatives or provide any exclusions. No guidance on prerequisites or when not to use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a '[mutation]' tag to indicate side effects, but no annotations exist. Beyond noting it's a mutation, it does not disclose processing time, success/failure conditions, or any other 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 a single sentence with a useful [mutation] tag, no wasted words. It is front-loaded with the main action and efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and no output schema, the description covers the core action but omits details like return value, file size limits, or processing behavior. It is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no extra meaning beyond the schema, which already explains 'assistant_id' and 'file'. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subir archivo a Doc-QA') and explains the purpose: upload a document so the assistant can answer questions about its content. This distinguishes it from sibling tools like 'list_docqa_files' or 'check_docqa_file_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor on prerequisites or conditions. The description only states what it does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes the [mutation] tag, indicating a state change, and specifies the campaign should be 'completada'. However, it does not disclose what happens after archiving (e.g., whether it hides the campaign, if it's reversible, or error conditions for non-completed campaigns). With no annotations, the description carries the full burden but provides only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes the [mutation] tag. It is efficient and contains no unnecessary words. However, it could be slightly more structured by separating the purpose and side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter and no output schema, the description provides the essential purpose but lacks details on prerequisites (e.g., campaign must exist and be completed), return value, or potential errors. The presence of sibling unarchive_campaign implies reversibility, but it is not stated. Overall, it is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (campaign_id) with a description that matches the tool's purpose. The schema description coverage is 100%, and the tool description adds no additional meaning beyond what is already in the schema. Therefore, the parameter semantics are adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'archivar' (archive) and the resource 'campaña completada' (completed campaign), with the goal of keeping the list clean. It uses the [mutation] tag to indicate a write operation. This distinguishes it from sibling tools like delete_campaign, pause_campaign, cancel_campaign, and unarchive_campaign.
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 the tool should be used on completed campaigns to maintain list cleanliness, but it does not explicitly state when to use this tool versus alternatives like delete or pause. It lacks guidance on when not to use it (e.g., for active campaigns) or explicit context about reversibility, though the sibling unarchive_campaign hints at 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?
With no annotations, the description carries full burden. It clearly discloses mutation via the '[mutation]' tag and explains partial update behavior, including automatic merging of JSON fields (config_design, config_texts, config_behavior). However, it does not detail error handling, idempotency, or what happens to unspecified fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a tag. The first sentence clearly states the purpose, and the second provides critical behavioral detail about partial updates. No redundant or unnecessary information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, nested JSON objects, no output schema, no annotations), the description is adequate but lacking. It covers partial update behavior but omits response format, error scenarios, permission requirements, or expected outcomes. A more complete description would include success/failure indicators and usage examples.
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% coverage with descriptions for all 14 parameters, so baseline is 3. The description adds significant value by explaining that JSON fields (config_design, config_texts, config_behavior) support partial updates and merging, which is not evident from the schema alone. This clarifies how to use those parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures the chat web widget (verb 'Configurar' and resource 'plugin Chat'/'widget de chat web'). While it differentiates from other configure tools by specifying the chat plugin, it does not explicitly distinguish it from sibling tools like 'configure_plugin_productqa' or 'configure_webhooks', missing a clear differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or scenarios where this tool is appropriate over other configure_plugin tools. The agent must infer usage purely from the tool name and resource focus.
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?
No annotations are provided, so the description bears full responsibility. It discloses that the action is a mutation and requires confirmation, but fails to mention whether deletion is permanent, what happens to associated data, or any authentication needs. The description is insufficient for full behavioral 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 a single sentence that includes the key information: purpose, mutation indicator, and confirmation requirement. It is front-loaded and concise, though it could be more structured with explicit sections. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description covers the main points. However, it lacks details about reversibility, dependencies (e.g., if the file is in use), or any prerequisites. It is adequate but not fully complete for a deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds context by labeling the confirm parameter as necessary for a 'peligrosa' (dangerous) action and instructing to pass 'confirm=true' to execute. This provides behavioral semantics beyond the schema's mere parameter 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 states the verb 'Eliminar' (delete), the resource 'archivo de Doc-QA', and specifies it's a mutation. It distinguishes from siblings like 'upload_docqa_file' and 'list_docqa_files' by clearly defining the action and context.
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 that confirmation (confirm=true) is required to execute, but does not provide guidance on when to use this tool versus alternatives (e.g., delete_knowledge_file) or when not to use it. The usage context is implied but not explicit.
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?
Without annotations, the description discloses it is a mutation and requires confirmation, indicating a destructive action. It also notes system file restriction. However, it does not explain permanence, recoverability, or authorization requirements, which are expected for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and includes essential context (mutation, confirmation requirement, system file restriction). Every sentence adds value 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?
For a simple two-parameter deletion tool with no output schema, the description satisfactorily covers the core functionality, danger level, and specific constraint. It could mention return value or side effects but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds that confirm is required for execution and that system files are excluded, but it doesn't add deeper meaning to the parameters beyond what the schema already provides (e.g., how to obtain file_id).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a knowledge file from the knowledge base and specifies it cannot delete system files. It uses a specific verb-resource pair and marks as mutation. However, it doesn't explicitly differentiate from similar sibling tools like delete_knowledge_snippet.
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 about requiring confirmation (confirm=true) and the limitation on system files. It implies a dangerous action but lacks guidance on when to use this tool versus alternatives like delete_knowledge_snippet or other deletion tools.
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?
No annotations are provided, so the description carries full burden. It only states the action is a mutation (via [mutation]) and affects all accounts, but does not disclose important traits like whether the sync is asynchronous, if there are rate limits, or what side effects (e.g., high resource usage) may occur.
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 includes a Spanish version which adds redundancy but still fits in one line. The [mutation] tag is helpful. It could be more streamlined without the duplicate language, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is adequate but lacks details on return value, expected behavior (synchronous vs asynchronous), or prerequisites. It covers the basic action but leaves some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by specifying that all accounts are synced via IMAP, which provides context beyond the empty schema. However, with zero parameters, the bar for adding parameter semantics is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('force sync'), the resource ('all email accounts'), and the method ('via IMAP'). It marks as [mutation], distinguishing it from sibling tools like 'update_email_sync' (configuration) and 'get_email_accounts' (read).
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 an immediate sync is needed but provides no explicit when-to-use or when-not-to-use guidance. Alternatives like 'update_email_sync' are not mentioned, so the agent must infer context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes '[mutation]' hinting at state change and mentions AI usage, adding some transparency beyond the schema. However, it does not disclose whether the draft is saved, returned, or how it is stored. Without annotations, the description should provide more details on side effects and output 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 very short and front-loaded, using two sentences to convey the core purpose. No unnecessary information. Ideal for quick scanning. Slightly more structure (e.g., specifying output) could be added without bloat, but it remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool without output schema, the description covers the main function and AI aspect. However, it does not explain what the tool returns (e.g., draft text or confirmation) or how to access the generated draft. This leaves some contextual gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage (100%) with descriptions for both 'thread_id' and 'instructions'. The tool's description adds no further semantic value beyond what the schema already states. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generar borrador de email con IA'), the resource (email draft), and the method (using AI). It distinguishes the tool from siblings like 'send_email_reply' (which sends) and 'list_email_drafts' (which lists), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies generating a draft but does not explicitly state when to use this tool vs alternatives. For example, it doesn't mention not to use it for sending or that it creates a draft that can be later sent. More explicit guidance on when to choose this over 'send_email_reply' or 'get_smart_reply_suggestions' would improve clarity.
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?
No annotations provided, so description carries the burden. It indicates a read operation ('Obtiene'), but does not disclose authorization requirements, rate limits, or whether it modifies state. The [query] token is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and to the point. The bracketed [query] is somewhat informal but does not harm clarity significantly. Could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should detail return structure. It lists components but omits pagination, limits, or field details. With 9 parameters, the scope of a 'full profile' is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter descriptions. The tool description adds no detail beyond listing the data types, and the [query] reference is not explained. 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 it retrieves a full customer profile including CRM data, comments, tags, conversation, files, and tasks. The verb 'Obtiene' and specific resource components distinguish it from sibling tools like get_crm_customer or get_customer_comments.
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 others. It implies use for a comprehensive overview, but does not mention prerequisites or alternatives like get_crm_customer for CRM-only needs.
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?
No annotations are provided, so the description bears full responsibility. It discloses that results are unified and deduplicated, but does not mention read-only nature, rate limits, authentication requirements, or other behavioral traits. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core functionality efficiently. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters (only 1 required) and no output schema, the description should clarify how optional parameters filter results, pagination behavior, and return format. It does not address these, leaving the agent underinformed for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the baseline is 3. The description adds minimal extra meaning beyond the schema (e.g., mentioning the query parameter implicitly). It does not elaborate on how optional parameters interact or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 performs a global search of customers across multiple data sources (CRM, contacts, conversations) and returns unified deduplicated results. It distinguishes itself from sibling search tools like search_customers or search_conversations by emphasizing the cross-source scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for cross-source customer searches with 'Busca en todas las fuentes de datos de clientes.' It provides clear context but does not explicitly state when not to use it or mention alternative tools for narrower searches.
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?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It only mentions the output fields and format, but does not indicate read-only nature, potential pagination, or performance implications. Lacks key transparency for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core functionality efficiently. However, it ends with '[query]' which seems out of place and slightly confusing. Otherwise, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, the description provides the essential purpose but lacks details on response structure, filtering, ordering, or any limitations. Adequate for a simple list, but could be more complete (e.g., number of agents, default ordering).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. With no parameters to document, the description does not need to add parameter semantics. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all configured agents in JSON format with complete data fields (nombre, email, teléfono, color, permisos, PIN). This distinguishes it from sibling tools like 'list_agents' by specifying the output format and included details.
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 when JSON format with full agent data is needed, but does not explicitly state when to use this over alternatives like 'list_agents' or other listing tools. No context on 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns counts and upcoming events, but it does not mention if it filters by status, requires authentication, or has rate limits. The inclusion of '[query]' is unclear and may mislead about parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes unclear element '[query]' which detracts from clarity. It is front-loaded with the purpose, but the extra token is unnecessary and potentially misleading.
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 no parameters and no output schema, the description provides adequate context for a simple list tool. It describes the key output (calendars with counts and events), though it does not specify the exact format or any filtering behavior. The '[query]' part is a minor oddity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to explain them. Baseline for zero parameters is 4. The description adds no parameter info, but the stray '[query]' is confusing and could imply a parameter that does not 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 lists all available calendars with counts of services and upcoming events. It uses a specific verb (list) and resource (calendars), and the additional detail on conteo de servicios y eventos próximos distinguishes it from sibling tools like list_calendar_events or list_calendar_services.
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 its many calendar-related siblings (e.g., list_calendar_events, list_calendar_services). No when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only labels the tool as '[mutation]', indicating state modification, but fails to disclose permissions, side effects (e.g., making FAQs visible), rate limits, or return behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that clearly states the purpose and includes the mutation indicator. No redundant words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description does not explain what the tool returns (e.g., updated FAQs, success message) or any post-republish state. This leaves the agent uncertain about the outcome, making it incomplete for a simple mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for 'faq_ids' (IDs of FAQs to republish). The description adds the nuance that it can republish 'una o varias' (one or several) FAQs, which goes beyond the schema by clarifying multiplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Republicar' (republish) and the resource 'FAQ', with the qualifier 'previamente despublicadas' distinguishing it from publishing new FAQs or unpublishing. It effectively differentiates from sibling tools like 'publish_question_as_faq' and 'unpublish_faq'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for republishing previously unpublished FAQs), but does not explicitly state when not to use it (e.g., if FAQs are already published) or mention alternative tools. The usage context is clear but lacks 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?
No annotations provided, so the description must carry the burden. It indicates mutation via [mutation] and mentions the association requirement, but lacks details on side effects like overwriting, rate limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, and includes necessary prerequisite without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers purpose and prerequisite. Lacks information on result or side effects but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for session_id, and the description does not add additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it saves a conversation note by generating an AI summary and saves it to the customer profile. It distinguishes from sibling tools like 'check_plugin_conversation_note' by mentioning generation, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite (visitor must be identified with phone/email) but does not give guidance on when to use versus alternatives, nor 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses mutation via '[mutation]' and that it doesn't delete, but fails to mention reversibility, permissions, or side effects. Basic disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It includes a helpful parenthetical about AI usage and a mutation tag.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and good schema coverage, the description covers the essential action. Minor gaps exist (e.g., idempotency, response), but it is mostly complete for a toggle 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 coverage is 100% with both parameters described. The description adds no extra meaning beyond what the schema provides; it only paraphrases the action. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool toggles activation of a knowledge file, using the verb 'Activar/desactivar' and explains it pauses without deletion. It distinguishes from siblings like delete_knowledge_file and update_knowledge_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use by noting that the AI only uses active files, but it does not explicitly state when not to use or mention alternatives. The context is clear but lacks 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?
No annotations are provided, so the description carries the full burden. It discloses the draft state constraint and that it is a mutation, but omits important behavioral details: what happens if the campaign is not in draft (error? ignored?), whether partial updates are allowed (only campaign_id is required, implying partial updates), what the tool returns (success indicator or full campaign object?), and any rate limits or side effects. This is insufficient for a tool with 16 parameters and complex conditional fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two clear parts: the tool name ('Actualizar campaña') and a single sentence explaining its purpose with a key condition and mutation tag. Every element earns its place, and there is no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters including nested objects, boolean flags, and conditional fields) and the presence of many sibling tools for campaign state changes, the description is too sparse. It does not mention return values (no output schema), error handling, or the workflow for updating a campaign (e.g., that after updating in draft, an approval step might be needed). The lack of completeness forces the agent to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 100% coverage with descriptions for all 16 parameters. The description adds no additional meaning or constraints beyond what is already in the schema (e.g., it does not explain the relationship between `is_recurring` and `recurring_cron` or the meaning of `segment_filters`). The baseline is 3 since the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Actualizar campaña' / update campaign) and specifies the resource ('campaña de marketing masivo existente') and a key condition ('solo en estado borrador'), which effectively distinguishes it from sibling tools like create_campaign, delete_campaign, and approve_campaign.
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 notes that the campaign must be in 'borrador' (draft) state to be updated, which is a crucial usage condition. The [mutation] tag signals it's a modification operation. However, it does not mention what to do if the campaign is not in draft or provide explicit alternatives among the many campaign state-change siblings (e.g., approve, archive), leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions automatic deletion of older emails, which is a key behavioral trait beyond a simple update. However, it does not disclose whether changes are immediate, reversible, or require specific permissions. With no annotations, more detail would improve 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?
Description is short and front-loaded with the purpose. Uses a clear title-like format and a mutation tag. No unnecessary words, though the structure could be more formal.
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?
Describes the action and consequence (deletion) but lacks details on immediate effect, error handling, or return values. Without output schema, some completeness is missing. Adequate for a simple mutation tool but not fully comprehensive.
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 provides descriptions for both parameters ('retention_days' with enum, 'id' as account ID). The tool description adds context about the effect of changing retention (automatic deletion), which goes beyond the schema. Since schema coverage is 100%, score is above 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?
Description clearly states the tool updates email retention period and automatically deletes older emails. The verb 'Cambia' and reference to retention period make the purpose unmistakable, distinguishing it from read-only tools like 'get_email_retention'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the sibling list includes 'get_email_retention', the description itself does not direct the agent to use this tool only for modifications or exclude read scenarios.
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?
No annotations are provided, so the description must cover behavioral traits. It includes a [mutation] tag indicating state change but does not disclose side effects, required permissions, or rate limits. For a mutation tool, more detail is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single sentence plus an example and a [mutation] tag. It is front-loaded with the core purpose and contains 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 has only 2 parameters, no output schema, and no annotations, the description adequately covers the purpose and input semantics. It references a related tool (get_whatsapp_status) for obtaining IDs, which adds context. For a simple update tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds context (e.g., 'max 50 caracteres' is in schema, 'Null para quitar la etiqueta' is also in schema). It does not add significant extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool edits a WhatsApp session by updating its label (name), with a specific verb 'Actualiza' and resource 'sesion de WhatsApp'. The example 'Soporte', 'Ventas' indicates typical use cases, distinguishing it from other session operations like connecting or deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case example (identifying numbers) but no explicit guidance on when to use this tool versus alternatives like get_whatsapp_status or connect_whatsapp. The instruction 'Usa get_whatsapp_status para obtener los IDs' gives a prerequisite but not 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool is a mutation requiring confirmation and has conditional behavior based on level. However, it lacks details on side effects, reversibility, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, front-loading the action and key details. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with conditional behavior), no output schema, and full schema coverage, the description explains the conditional outcome but omits what 'level' refers to and does not cover error states or 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 description coverage is 100%, so baseline is 3. The description adds no new meaning beyond what the schema already provides for suggestion_id and confirm.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 applies a training suggestion and specifies the conditional outcomes (creates knowledge snippet or updates assistant prompt). This distinguishes it from siblings like apply_prompt_instruction or edit_knowledge_snippet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement for confirmation (confirm=true) and hints at mutation via [mutation] tag, but does not explicitly state when to use this tool versus alternatives like apply_prompt_instruction 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?
The [mutation] tag indicates state change, but with no annotations, the description should provide more behavioral details like idempotency, effect on already approved campaigns, or required permissions. Current disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a tag, front-loaded with the action. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description is mostly adequate but lacks behavioral and usage guidance. Could be improved with a note on preconditions or 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 coverage is 100% with parameter description. The description adds no extra semantic meaning beyond the schema, achieving the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'approve', resource 'campaign', and the specific state 'pending approval', distinguishing it from sibling campaign tools like cancel, archive, or pause.
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 campaigns pending approval but does not mention when not to use it or alternatives like start_campaign. No explicit when/when-not guidance.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only indicates mutation via '[mutation]' but lacks details on side effects, reversibility, or error handling (e.g., what happens if the ID is invalid or if dependencies exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a '[mutation]' tag, making it concise and front-loaded. Every word serves a purpose, though it could be slightly more detailed without becoming 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?
For a simple delete operation with one parameter and no output schema, the description adequately explains what resource is affected and when it is appropriate. It is complete for the tool's complexity, though it could mention if the action is irreversible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a clear description for the single 'id' parameter. The tool description adds no additional meaning beyond the schema, resulting in 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 action (delete), the resource (correction from customer-facing WhatsApp AI), and the context (no longer valid). It effectively distinguishes from sibling tools like 'delete_ai_error' which targets a different type of error.
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 when to use: when a correction is no longer valid. However, it does not explicitly state when not to use or mention alternatives like 'update_customer_ai_error' or 'set_customer_ai_error', which are present among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the mutation nature ('[mutation]') and that the result is a draft copy. However, it lacks details on side effects, permissions, or limits. For a simple mutation with one parameter, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose without extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter and no output schema, the description gives the essential behavior. However, it does not mention what the tool returns (e.g., new campaign ID or success status), leaving a gap in 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?
The input schema provides a description for the single parameter 'campaign_id' (ID of campaign to duplicate), achieving 100% coverage. 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 verb 'duplicar' (duplicate), the resource 'campaña' (campaign), and specifies the outcome is a copy in draft state. It distinguishes from siblings like create_campaign or archive_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it creates a copy of an existing campaign, but it does not explicitly state when to use this tool versus creating a new campaign from scratch or other alternatives. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the basic purpose and list of fields, lacking details on side effects, permissions, rate limits, or return format. For a read operation, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a dash separating title and details. It is front-loaded and concise, with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema), the description is adequate but not fully complete. It lacks detail on the response structure or any prerequisites, leaving the agent to infer from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. With zero parameters, baseline is 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves calendar integration settings and lists specific fields (enabled, timezone, booking rules). It distinguishes itself from multiple calendar-related sibling tools by focusing on settings retrieval.
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. While the verb 'get' implies retrieval, there is no comparison to other calendar tools 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?
No annotations provided, so description must disclose behavioral traits. It indicates a read-only query ('Devuelve' = returns), but doesn't explicitly state it's non-destructive, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose. No redundant 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?
No output schema exists, so description should clarify return structure. It mentions 'number of threads for each filter' which gives a basic idea, but doesn't specify format or whether all filters are always included. Adequate but not 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 single parameter (account_id) is described in the schema. The description adds no extra meaning beyond what the schema already provides. With 100% 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 returns counts of email threads per filter (unread, read, sent, archived, etc.), distinguishing it from siblings like get_email_unread_count which only returns a single count.
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 (e.g., get_email_stats or get_email_unread_count). The description implies it provides a breakdown of filters, but doesn't state that.
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?
No annotations are provided. The main description omits the fallback behavior where the tool uses the current prompt if none is provided, which is only mentioned in the parameter description. Side effects (e.g., does this modify anything?) are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action and usage context. Every word serves a purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description outlines the return items (scores, suggestions, improved version) but lacks detail on format or categories. With no output schema, this is a moderate gap. The fallback behavior is handled in the parameter, but not in the main description.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'prompt' includes a detailed description explaining its meaning and fallback logic. The main description adds no further parameter context, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: analyzing a prompt with AI to return scores, improvement suggestions, and an improved version. It distinguishes itself from sibling tools like get_prompt (retrieve only) and save_prompt (persist changes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear use case: 'Útil cuando el usuario quiere saber si su prompt es bueno o como mejorarlo.' It provides when to use but does not explicitly exclude alternative tools or mention prerequisites, which would elevate clarity.
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?
No annotations provided; the description does not disclose any behavioral traits beyond listing all files. Missing details on pagination, ordering, or read-only nature, which are important for an agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence conveying the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, the description is minimal but adequate. It lacks information on output format or potential limitations like pagination, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema, so description adds no parameter info. Baseline for 0 parameters is 4, though the inclusion of '[query]' in the description is ambiguous and could be misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 knowledge base files, specifying examples like PDFs and documents. It distinguishes from sibling 'list_knowledge_snippets' by explicitly mentioning 'archivos'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, given the tool has no parameters and is straightforward, the lack of usage instructions is acceptable but not optimal.
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?
No annotations are present, so the description bears the full burden. It implies a read operation by listing return fields, but does not explicitly state that it is non-destructive or safe. It also does not mention any side effects or behavioral constraints beyond filtering.
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, bilingual, and front-loads the purpose. It is concise but includes both Spanish and English, which may be slightly redundant. Overall, it is efficiently written.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists key return fields and mentions filtering capabilities, which is sufficient for a list tool without an output schema. It covers the essential context for an AI agent to understand what the tool does and what it 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%, so the description adds little beyond the schema. The description notes 'optional status filter' and some default values, but these are already in the schema. No additional parameter semantics are 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 scheduled WhatsApp messages with an optional status filter. It specifies the resource ('scheduled messages') and action ('list'), and provides a detailed list of return fields. While it doesn't explicitly differentiate from siblings like list_scheduled_emails, the mention of 'WhatsApp' makes it distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions an optional status filter but does not provide guidance on when to use this tool versus alternatives (e.g., list_whatsapp_scheduled_sessions). It lacks explicit usage context or prerequisites.
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?
With no annotations, the description must disclose behavioral traits. It only states it shows all available agents, but does not mention read-only nature, required permissions, rate limits, or what 'available' means. The name suggests read-only, but the description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear sentence front-loaded with the action and resource. No unnecessary words. Efficient for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema, the description provides the essential purpose but lacks details on return structure or fields. It is adequate but not rich. Given no output schema, more context on what the list contains could help.
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 is empty (0 parameters), so schema description coverage is 100%. The description adds no parameter information, which is acceptable. Baseline for 0 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?
Tool name 'list_whatsapp_agents' and description 'Listar agentes de atencion — Muestra todos los agentes disponibles para asignar en workflows de WhatsApp [query]' clearly state the action (list), resource (agents), and scope (WhatsApp workflows). It distinguishes from siblings like 'list_agents' and 'list_agents_json' by specifying WhatsApp context.
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 needing agents for WhatsApp workflow assignments, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It indicates mutation and requires confirmation for dangerous action, but lacks details on side effects (e.g., old token invalidation), reversibility, or impact on active sessions.
Agents need to know what a tool does to the world before 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: two lines cover purpose, mutation flag, and confirmation requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, description covers core purpose and safety confirmation. However, for a mutation tool, additional behavioral details (e.g., old token status) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add extra meaning 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 regenerates a token for a Doc-QA assistant, using a specific verb and resource. It distinguishes from siblings like 'create_docqa_assistant' by focusing on token regeneration and explicitly marking it as a mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the need for confirmation (confirm=true) to execute, but does not provide when to use this tool versus alternatives like 'regenerate_plugin_token' or prerequisites (e.g., assistant must exist). No explicit usage 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool validates credentials and OAuth permissions and uses stored config if needed. However, it does not explicitly state whether the operation is read-only or if it has side effects, nor does it describe what happens on success or failure. The behavioral disclosure is adequate but incomplete.
Agents need to know what a tool does to the world before 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, consisting of two short sentences and a tag. Every sentence provides essential information: the action, what is validated, and the fallback behavior. There is no redundancy or unnecessary detail, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally hint at what the tool returns (e.g., success/failure status). It currently does not mention return values, which is a gap. Additionally, given the context of many sibling tools, it could clarify that this is a safe testing operation. The description covers the core functionality but lacks completeness regarding outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all 4 parameters, each clearly described. The description adds value by explaining the behavior when parameters are omitted (fallback to stored credentials), which enhances understanding beyond the schema alone. However, it does not add new semantic distinctions for each parameter, so a 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 'Probar' (test) and the resource 'conexion Shopify', and explicitly mentions validating credentials and OAuth permissions. It distinguishes this tool from sibling tools like test_ecommerce_connection by specifying Shopify, making its 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 when to use the tool (to test a Shopify connection) and notes that it can fall back to stored credentials. However, it does not specify when not to use it or suggest alternative tools like test_ecommerce_connection for other e-commerce platforms. Usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description includes '[mutation]' hinting at state change, but with no annotations, it does not explicitly disclose side effects, permissions, or behavioral details beyond the basic toggling action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two lines with a title and full description. No redundant 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 boolean toggle with one parameter and no output schema, the description fully covers the tool's purpose and effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter explanation. Description adds no additional meaning beyond the schema, so 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 toggles auto-learning, specifying both activation and deactivation. It distinguishes from other toggle tools by naming the specific resource 'auto-learning'.
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., other toggle tools). Missing when to enable or disable auto-learning.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool mutates data (via [mutation] tag), constrains name changes to personal accounts, and optionally applies changes to other sessions. However, it does not describe whether the update is a full replacement or partial update, potential side effects (e.g., overwriting fields), or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a tag) and front-loaded with the main purpose. Every sentence provides relevant information without extraneous content. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description covers the main behaviors (field updates, name constraint, multi-session application) but lacks information on return values, error reporting, or side effects like data overwrite. Adequate but not fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by grouping fields (info/about, company data) and explaining the name constraint and optional session application. However, it does not add detailed semantics beyond what the schema provides, resulting in 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 it updates WhatsApp profile fields, including info/about and company data. It differentiates from siblings like get_whatsapp_profile (read) and remove_whatsapp_profile_picture (specific removal) by focusing on updating multiple fields. The verb 'Actualizar' and resource 'perfil de WhatsApp' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating profile fields, but does not explicitly state when to use this tool versus alternatives (e.g., get_whatsapp_profile for reading, remove_whatsapp_profile_picture for picture removal). It notes that name change is only for personal accounts, which is a constraint but not a usage guideline.
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?
No annotations provided; description indicates mutation via '[mutation]' tag and action verbs, but does not disclose side effects, permissions, or error scenarios.
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; includes title, description, and a clear usage note. Could be better organized with more explicit structure.
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 main purpose and unassignment case, but lacks details on output, error handling, or prerequisites; with no output schema, more context 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?
All three parameters have schema descriptions; description only repeats concept of using null to unassign, 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?
Description clearly states the action (assign email thread to agent) and explicitly mentions using assign_to=null to unassign, distinguishing it from sibling tools like assign_calendar_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on using assign_to=null to unassign, but lacks details on when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses mutation behavior and confirmation requirement, but lacks details on irreversibility, side effects (e.g., notifications), or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a parenthetical note, front-loading purpose. Every word is useful, but it could be slightly expanded for completeness without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no output schema, the description is incomplete. It does not explain that event_id alone is sufficient for deletion, nor does it specify the return value or effect of optional parameters. The confirm requirement is stated, but broader context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds minimal value by highlighting confirm=true but does not clarify the role of other parameters (e.g., date_from, phone) beyond their 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 'Elimina un evento del calendario' (deletes a calendar event), with a [mutation] tag. This verb-resource pair distinguishes it from sibling tools like update_calendar_event and list_calendar_events.
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 execute, providing a critical guardrail. However, it does not compare with alternative deletion tools (e.g., delete_calendar) or outline prerequisites like permissions.
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?
No annotations are provided, so the description must convey behavioral traits. It states the required assistant_id and implies a read-only operation (viewing stats), but it does not mention any side effects, authentication needs, rate limits, or potential limitations. The cryptic '[query]' suffix is unexplained and may confuse. Overall, minimal disclosure beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two short sentences plus the ambiguous '[query]' token. It is front-loaded with the core purpose. However, the stray '[query]' detracts from clarity and may be a leftover artifact, preventing a perfect score. Otherwise, it is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should explain what statistics are returned. It only says 'estadisticas detalladas' (detailed statistics), which is vague. It does not list metrics, time frames, or how days affects the results. The prerequisite hints are helpful but incomplete for a tool that returns a non-trivial response. The unexplained '[query]' adds to the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters: assistant_id (source hint from list_docqa_assistants) and days (default 30, range 1-365). The description reinforces the source hint for assistant_id but adds no new information that the schema doesn't already convey. With full schema coverage, the baseline is 3, and the description does not significantly elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ver estadisticas de asistente Doc Q&A' (view Doc Q&A assistant stats), specifying it provides detailed statistics for a documentation assistant. This distinguishes it from sibling tools like list_docqa_assistants (which lists assistants) and get_docqa_detail (which likely shows details rather than stats). The verb 'ver' and resource 'asistente Doc Q&A' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use list_docqa_assistants first to obtain the assistant_id, which is a clear prerequisite. It does not explicitly contrast with alternatives like get_docqa_logs or get_docqa_detail, but the prerequisite guidance helps the agent avoid errors and directs the user to a necessary preliminary step.
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?
No annotations provided, so description carries full burden. It discloses that the previous token is invalidated and marks the action as mutation. But lacks details on side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear front-loading: 'Regenerar token de plugin'. Includes mutation marker and confirmation requirement. 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?
For a 2-param tool with no output schema, the description explains purpose, invalidation, and confirmation. Implies a new token is generated but does not explicitly state return value. Adequate for agent 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 coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema descriptions; the main description only briefly mentions purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it regenerates a plugin token and invalidates the previous one. It distinguishes from siblings like regenerate_api_key and regenerate_docqa_token by specifying 'plugin'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the confirmation requirement (confirm=true) which is a usage guideline. However, it does not provide explicit guidance on when to use this tool versus alternatives or any 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?
With no annotations, the description carries the full burden. It discloses the mutation nature but lacks details on side effects, error conditions, or required prior state (e.g., number must be currently opt-out). Basic transparency but insufficient depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a tag, with no wasted words. It is efficiently front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation with no output schema, the description covers the essential purpose and effect. However, it could mention expected return (e.g., success confirmation) for completeness. Still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description does not add new meaning beyond the schema. For high coverage, baseline is 3, and no extra value 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 action (remove contact from opt-out), the resource (WhatsApp opt-out list), and the effect (can receive automatic messages again). It also tags it as a mutation, distinguishing it clearly from siblings like add_whatsapp_optout and check_whatsapp_optout.
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 when wanting to re-enable messages for a number, but it does not explicitly state when to use versus alternatives (e.g., remove_from_blacklist) or provide contextual prerequisites. Guidance is implied but not explicit.
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 mentions the mutation effect and that the thread will automatically reopen, which is a key behavioral trait. However, with no annotations provided, it lacks details on permissions, reversibility (though an unsnooze exists), or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the main action. The [mutation] tag is embedded compactly. 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?
For a simple mutation with two required parameters and no output schema, the description covers the core behavior and side effect. Minor gaps like missing mention of thread existence or assignment requirements are acceptable but prevent a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters well. The description adds minimal additional meaning, only paraphrasing the purpose of the 'until' parameter. 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 postpones an email thread until a specific date/time and that it will auto-reopen. The verb 'Pospone' and resource 'hilo de email' are specific, and it distinguishes itself from siblings like 'unsnooze_email_thread' which does the opposite.
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 (when you want to defer an email thread) but does not explicitly state when to use it versus alternatives like assign_email_thread or merge_email_threads. No guidance on prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits beyond a simple mutation indication. It labels itself as [mutation] but does not detail side effects, permissions needed, or potential impacts (e.g., performance). This is insufficient for a mutation tool without 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: a single phrase that conveys the purpose and key action. No redundant information, every word 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 no parameters and no output schema, the description covers the essential information: what it does, that it's a manual override, and that it's a mutation. It lacks some context like prerequisites or result expectations, but overall it is fairly complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with full schema coverage. According to guidelines, baseline is 4. The description adds no parameter-level detail but that is compensated by the absence 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 verb 'sync' and the resource 'learned facts to Vector Store', with a specific action of forcing immediate synchronization. It distinguishes from other sibling knowledge tools like get_knowledge_processing_status or update_knowledge_file.
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 that sync normally happens automatically, implying use when immediate sync is desired. However, it does not provide explicit guidance on when not to use or compare to alternatives, leaving usage context implied rather than explicit.
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?
No annotations are provided, so the description must convey behavioral traits. It mentions testing connectivity and response but does not detail what the test entails (e.g., HTTP request specifics, expected outcomes, side effects). This is minimal but not misleading.
Agents need to know what a tool does to the world before 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 with a subtitle, achieving high conciseness. It front-loads the action and purpose, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (including nested auth object) and no output schema or annotations, the description is too brief. It lacks explanation of how the test works, what response is returned, or any failure handling. Essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 all parameters described. The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tests CRM endpoint connectivity and response ('Probar endpoint CRM — Prueba la conectividad y respuesta de un endpoint CRM'). The verb 'test' and specific resource 'CRM endpoint' make it unambiguous, and no sibling tool shares this exact 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 implies usage for testing custom CRM endpoints configured in the store. While it doesn't explicitly state when to use or exclude alternatives, the context of sibling tools (e.g., test_ecommerce_connection, test_email_connection) makes it clear this is for CRM-specific testing.
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?
No annotations are provided, and the description only includes '[mutation]' to indicate a state change. It lacks details on side effects, permissions, prerequisites (e.g., campaign must be archived), or error conditions. The description does not sufficiently compensate for the absence of 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: a single line with the action and a brief explanation. It is front-loaded with 'Desarchivar campaña', making the purpose immediately clear. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no output schema, no nesting), the description is minimally complete. It explains what the tool does adequately. It could mention that the campaign must be archived first, but the core functionality is conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 clear description for campaign_id. The tool description adds context ('Restores an archived campaign to the main list') but does not enhance understanding of the parameter 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 the tool's action: 'Desarchivar campaña' (unarchive campaign) and explains it restores an archived campaign to the main list. The verb is specific and distinguishes it from sibling tools like archive_campaign or delete_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for restoring archived campaigns, providing clear context. However, it does not explicitly mention when not to use it or compare with alternatives like delete_campaign. The context is sufficient for a simple tool.
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?
No annotations provided, and the description does not disclose side effects, permissions, or reversibility. The '[mutation]' tag hints at a write operation, but more detail is needed for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences (one Spanish, one English) and a mutation tag. 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 (one required parameter, no output schema), the description adequately covers the action. Could mention it is the inverse of snooze, 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% but the description adds no additional meaning beyond the schema's description of 'ID del hilo'. Parameter semantics are minimally conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 reactivates a postponed email thread and returns it to open state, distinguishing it from the sibling 'snooze_email_thread'. Uses specific verb and resource.
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 it is used for threads that were previously postponed, but does not explicitly state when to use it vs alternatives like 'snooze_email_thread' or 'email_thread_action'. Context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the [mutation] tag and explains that sending the content parameter triggers replacement in OpenAI and re-indexing in the Vector Store. It also advises against sending content if only changing title/description. With no annotations, this provides useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before 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 plus a [mutation] tag, front-loading the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the mutation behavior, parameter constraints, and special actions (re-indexing). It lacks error scenarios or prerequisites, but given no output schema, it is fairly complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description reiterates the content constraint already in the schema and adds re-indexing info. This offers marginal additional value, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a knowledge file's title, description, and/or content, specifying that content editing is limited to text file types. This distinguishes it from other tools but does not explicitly differentiate from sibling tools like edit_knowledge_snippet.
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 implicit usage guidance by noting that content can only be updated for certain file types and warns not to send content if only changing title/description. However, it lacks explicit when-to-use or alternative recommendations.
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?
No annotations provided, so description carries the burden. It labels itself as a mutation and requires confirmation via confirm=true, indicating destructive nature. However, it lacks details on failure modes or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, but mixing English and Spanish ('requiere confirmación') may reduce clarity for some agents. Still, it covers key info without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return values. It does not. It covers core functionality but missing details on what the tool returns after update.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds high-level modifiable fields but does not elaborate 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 scheduled message' and specifies it updates a pending scheduled WhatsApp message, listing modifiable fields (text, datetime, sending session). It distinguishes from sibling tools like 'cancel_scheduled_message'.
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 mentions 'Only pending messages can be edited', providing a clear condition. However, it does not explicitly state when to use this over other tools like 'cancel_scheduled_message'.
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?
Despite no annotations, the description explicitly marks the action as a mutation, states it is definitive, and notes that sent messages are not undone. It also requires confirmation, which adds safety transparency. However, it does not discuss undo capabilities or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear structure using a dash separator. Every sentence provides essential information: action, scope, irreversible nature, confirmation requirement. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information about the return value or typical response (success/failure). Since no output schema exists, describing the expected output would improve completeness. Otherwise, the description covers purpose, parameters, and important behavioral notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters with descriptions (100% coverage). The description adds minimal extra meaning beyond emphasizing the requirement of confirm=true. Baseline score of 3 is appropriate as schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it cancels a marketing campaign definitively and lists the states it applies to (en curso, pausada, borrador, programada). It specifies that already sent messages are not undone, leaving no ambiguity about the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the need for confirmation (confirm=true) but does not differentiate when to use this tool versus sibling tools like archive_campaign, pause_campaign, or delete_campaign. Guidance on when to cancel vs alternative actions is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds important behavioral info: it is a mutation requiring confirmation. This helps the agent understand it is a destructive action. It could be enhanced by mentioning irreversibility or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus a parenthetical, no unnecessary words. Front-loaded with purpose. Excellent 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?
No output schema, and description does not specify return value. For a simple mutation, it is adequate but could be more complete by indicating success/failure response. Also missing prerequisites like message must be scheduled.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 described. The description reinforces the confirm parameter's role but adds minimal 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 it cancels a scheduled WhatsApp message, with specific verb and resource. It distinguishes itself from siblings like create_scheduled_message and update_scheduled_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions the need for confirmation (confirm=true), which is a key usage guideline. However, it does not provide guidance on when to use this tool versus alternatives like update_scheduled_message, nor does it state 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?
No annotations are provided, and the description only indicates it checks and displays data. It lacks explicit statements about being read-only or having no side effects, though the verb 'verificar' suggests a query operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence after a dash with no redundant information. The '[query]' tag hints at its purpose. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action and output (shows customer data), but lacks detail on the exact structure of returned data or whether it returns a boolean. Given no output schema, it is slightly incomplete but adequate for a simple check 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 a clear description for session_id. The tool description adds minor context (plugin chat session) but does not significantly enhance 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?
The description clearly states the tool's function: checking if a note exists for a plugin chat session and showing associated customer data. It uses specific verbs (verificar, comprueba) and distinguishes from sibling 'save_plugin_conversation_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 implies usage for checking existence of a note, contrasting with save/update tools. However, it does not explicitly state when not to use or alternative tools, leaving slight 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?
The description flags the operation as a mutation ('[mutation]') and explicitly states it is irreversible and requires confirmation. This goes beyond the lack of annotations to inform the agent about the destructive nature, which is crucial for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one line covering purpose, destructive warning, and confirmation requirement. Every word serves a purpose, with no redundancy. This front-loads critical information efficiently.
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 (2 params, no output schema, no annotations). The description covers the key behavioral aspects (irreversibility, confirmation) but does not mention return values or error states. For a delete operation, this is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with descriptions. The description adds value by explaining the confirm parameter's role ('pasar true para confirmar la ejecución'), but does not enhance the id parameter beyond the schema. 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 ('Eliminar regla de email') and provides a Spanish verb-noun pair. It explicitly identifies the resource (regla de email) and the operation (delete). This distinguishes it from sibling tools like create_email_rule or update_email_rule, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the action is irreversible ('no se puede deshacer') and requires confirmation ('pasar confirm=true para ejecutar'), which provides context for when to use it. However, it does not explicitly state when NOT to use it or suggest alternative tools (e.g., update_email_rule if modification is intended).
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 marks the tool as a mutation and discloses that it returns an existing link if already generated. However, with no annotations, it fails to detail any side effects, permissions needed, or the scope of the mutation (e.g., what gets stored).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear title-like first sentence and a second sentence adding key detail (idempotency). No wasted words, front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic effect but lacks details on the return format, error cases, or any prerequisites. With no output schema, more context about the returned link would help. However, for a simple tool, it is moderately 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?
The input schema has no parameters, so the description adds no param info. Per guidelines, 0 parameters earns a baseline of 4. No additional meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates or returns the unique referral link for the user. The verb 'generar' and resource 'enlace de referido' are specific, and the note about returning an existing link distinguishes it from get_referral_data which likely retrieves referral data without generating.
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 idempotency (returns existing if already generated) but does not explicitly state when to use this tool versus alternatives like get_referral_data. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool lists only 'active' corrections and scopes them to 'this assistant', adding useful context beyond the name. However, with no annotations, it does not disclose other behaviors like pagination, authentication needs, or read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and usage guidance. The stray '[query]' at the end is slightly distracting but does not significantly reduce 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?
For a simple list tool with two optional parameters and no output schema, the description covers the essential usage. It lacks details on return format or pagination, but the context is sufficient for basic 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 coverage is 100%, with detailed descriptions for each parameter. The description reinforces usage but does not add new information beyond what the schema provides, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 active AI corrections for this assistant', specifying the verb (list) and resource (AI corrections). It differentiates from siblings like 'get_customer_ai_errors' by indicating it is per-assistant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'To list ALL corrections, pass no parameters. Only use category or query when filtering specific results.' This clarifies when to use each parameter. However, it does not explicitly mention alternatives like 'get_customer_ai_errors'.
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?
No annotations are provided, so the description bears full burden. It discloses that the tool shows current state (active/disabled, error counter, list) but does not explicitly state it is read-only or non-destructive, nor mention authorization or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Spanish, front-loaded with the purpose. It avoids wasted words, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no parameters and no output schema, the description adequately explains what is shown (endpoints status, active/disabled, error counter, list). It mentions the return format implicitly (list of endpoints).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so description's job is minimal. Baseline for 0 params is 4; description adds no parameter info but also does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 shows CRM health status, including endpoint activity, error counters, and list. It uses a specific verb ('Ver') and resource ('endpoints CRM'), distinguishing it from sibling tools like get_crm_customer or test_crm_endpoint.
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 CRM health but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives like test_crm_endpoint or reset_crm_errors.
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?
With no annotations, the description adds some behavioral context by noting rule priority order, but lacks details on pagination, permissions, or other behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but the trailing '[query]' appears to be a placeholder or leftover, reducing 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?
For a simple list tool with no parameters or output schema, the description sufficiently states what is listed and the behavior of rules, though it does not describe the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds no parameter info, but the '[query]' at the end is unclear and potentially misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Listar reglas de email' and explains it lists all automatic email rules configured for the store, distinguishing it from CRUD siblings like create_email_rule and delete_email_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions that rules apply to incoming emails in priority order, providing context, but does not explicitly guide when to use this tool vs. alternatives or specify 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 explicitly marks the tool as a mutation and requires confirmation ('[mutation] (requiere confirmación: pasar confirm=true para ejecutar)'). This provides key behavioral context beyond the schema. No other side effects or permissions are mentioned, but the mutation flag and confirmation are adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: purpose, use case, behavioral note. No redundant information. Concise and front-loaded with the core 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?
The description covers purpose, use case, mutation nature, confirmation, and source of IDs. It does not mention batch vs. individual operation outcomes or error handling, but given the tool's simplicity and lack of output schema, it is largely 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?
All parameters are covered in the schema (100%), and the description adds value: it notes that faq_ids can be obtained from get_product_qa_faqs and reiterates that confirm=true is required for execution. This enhances understanding without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool manages FAQs by unpublishing, republishing, or deleting them, and specifies the source plugin. However, it does not differentiate from sibling tools like unpublish_faq, republish_faq, and delete_faq, which offer single actions.
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 suggests using the tool for outdated content ('gestionar contenido que ya no es relevante') and notes the need for confirmation. However, it does not explicitly guide when to use this combined tool versus the individual sibling tools, nor does it mention prerequisites like getting FAQ IDs from get_product_qa_faqs.
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?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior (preview columns and first rows) but does not explicitly state it is a read-only operation or describe any side effects. The word 'preview' implies no modification, but a clearer statement would be beneficial.
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 parts. However, the trailing '[query]' appears to be a placeholder or artifact, which slightly detracts from professionalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately explains its purpose and usage context. It could mention the output format or return structure, but the current information is sufficient for an agent to understand its basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 for the single parameter 'file' with a description. The tool description does not add new parameter semantics beyond what the schema already provides, 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 uses the verb 'previsualizar' (preview) and specifies the resource as an import file (CSV). It clearly states it previews columns and first rows before importing contacts, distinguishing it from the numerous import tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'antes de importar contactos' (before importing contacts) indicates when to use the tool. However, it does not explicitly mention when not to use it or provide alternatives, though the context implies it should be used before actual import operations.
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?
No annotations are provided, so the description must convey behavioral traits. It includes '[mutation]' to indicate data modification, but does not disclose side effects (e.g., whether it overwrites existing FAQs), permissions needed, or idempotency. For a simple single-param tool, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the action. It is efficient and avoids redundancy, though a slightly more structured format (e.g., bullet points) could enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, simple action), the description covers the purpose and usage context adequately. It could mention return values or error conditions, but the lack of output schema and straightforward operation make it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for question_id that already explains its origin ('obtener de get_product_qa_questions'). The tool description adds no additional semantics beyond the schema, matching 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 action (publicar manualmente una pregunta) and the resource (como FAQ en tu tienda online). It distinguishes itself from siblings like manage_faq and republish_faq by specifying it is for publishing questions as new FAQs, particularly those not automatically detected. The [mutation] tag reinforces the write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use: 'promover preguntas importantes que no fueron detectadas automaticamente'. It implies use when auto-detection fails, but does not explicitly exclude other scenarios or mention alternatives (e.g., if the question is already an FAQ). Still, it offers clear guidance for its intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is a mutation ([mutation]), requires confirmation (confirm=true), and has a minimum amount (50€) and availability condition. However, it does not describe the return value, potential failure modes, or what happens after execution, which is a gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus tags, all front-loaded with the main action. Every element (minimum amount, availability condition, mutation tag, confirmation requirement) serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should cover what the tool returns or error scenarios. It mentions prerequisites and mutation nature but omits details on success/failure responses, which are important for an agent to handle the tool correctly. It provides a functional but incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter (confirm) described as 'Pasar true para confirmar la ejecución de esta acción peligrosa'. The description reiterates this ('requiere confirmación: pasar confirm=true para ejecutar'), adding marginal value. It clarifies the purpose of the parameter but does not provide 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 'Solicita el pago de las comisiones pendientes' (Requests payment of pending commissions), specifying the action (request payout), resource (pending commissions), and constraints (minimum 50€, no other open request). It distinguishes from sibling tools like 'generate_referral_code' and 'get_referral_data' by focusing on payout initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear condition for use: 'Solo disponible si no hay otra solicitud abierta' (Only available if no other open request). It implies the tool should be used when there are pending commissions meeting the minimum threshold and no existing payout request. However, it does not explicitly mention alternatives or when not to use it, such as checking balances first with 'get_referral_data'.
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 no annotations, the description indicates a read-only search operation with no side effects. It adds context about the purpose (linking to email), but does not detail behavior like no-results handling or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a title prefix. However, it includes a placeholder '[query]' and a semicolon, which slightly detracts from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not specify the return format (e.g., list of contacts with IDs) or behavior for no results or pagination. This is a significant gap for a search 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 a single parameter 'query' described as 'Texto de busqueda (nombre o telefono)'. The description repeats this but adds the linking context, providing marginal added 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 explicitly states the tool searches contacts by name or phone to link to email threads. It clearly distinguishes from sibling tools like link_email_contact or resolve_email_contact by focusing on the search 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 specifies the context of linking contacts to email threads, which implies when to use it. However, it does not explicitly state when not to use or provide alternatives like 'use link_email_contact after finding the contact'.
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 labels the action as [mutation] and notes the confirmation requirement, but does not elaborate on side effects like immediate sending, rate limits, or required permissions. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before 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, front-loading the purpose and including the mutation flag and confirmation requirement in a single efficient sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and confirmation requirement, but lacks details on return values, error conditions, and integration with other email tools. Given no output schema, more context on outcomes would improve 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 coverage is 100% with descriptions. The description adds meaning by clarifying that thread_id=0 indicates a new email and that to/subject are obligatory for new emails, which is not enforced in the schema. It also highlights the confirm parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 sends a reply to an existing email thread or composes a new email, using specific verbs and resources. It distinguishes from siblings like generate_email_draft, which is for drafting only.
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 requires passing confirm=true to execute, which is a key usage condition. However, it does not provide guidance on when to use this tool vs alternatives (e.g., generate_email_draft) or prerequisites like having an email account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It tags '[mutation]' and states it sends a message, indicating a write operation. However, it does not disclose what happens after sending (e.g., confirmation, ticket ID) or any side effects. Given the simplicity, it is marginally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a mutation marker, extremely concise. It front-loads the purpose and provides usage context without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is adequate but could mention expected outcomes or that no output is returned. With no output schema and no annotations, it leaves some gaps, but the core functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents parameters well. The description adds no extra meaning beyond highlighting the type enum values (bug, question, etc.). 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's purpose: sending a support ticket to the WAzion team. The verb 'Enviar' (send) and resource 'ticket de soporte' are specific, and it distinguishes itself from siblings by focusing on contacting support for unresolved issues.
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 lists when to use: when the user has a problem the AI can't solve, wants to report a bug, or needs technical help. While it doesn't state when not to use, the positive conditions are clear and imply the context for this 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?
With no annotations provided, the description carries the full burden. It discloses that the tool mutates state (via [mutation] tag), changes the campaign to draft, and does not delete it. This provides adequate transparency for a simple operation, though it could mention prerequisites like the campaign must be scheduled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a tag) and front-loaded with the key action in the first sentence. Every word adds value, and the [mutation] tag provides a quick hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is fairly complete. It explains the action and the resulting state. However, it could mention the expected return value or confirm that the campaign must be in scheduled status.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter 'campaign_id'. The tool description adds no additional meaning beyond what the schema already provides, which is acceptable given 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 that the tool cancels the scheduling of a scheduled campaign and changes it to draft status, explicitly noting it does not delete the campaign. This distinguishes it from sibling tools like cancel_campaign or delete_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action and what it does not do, but does not explicitly specify when to use this tool versus alternatives such as cancel_campaign or archive_campaign. No direct guidelines are 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?
No annotations are provided, so the description carries the full burden. It includes '[mutation]' to indicate write operation, and states it creates a new file. However, it lacks details on permissions, reversibility, or side effects beyond creation. With no annotations, 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 four sentences, front-loaded with the action, and includes examples and purpose without redundancy. Every sentence adds value, making it 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 no annotations and no output schema, the description covers purpose, usage, and parameter context reasonably well. It lacks specifics on return values or error handling, but for a creation tool with a complete schema, it is fairly complete. Sibling tools handle updates and deletions, so context is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter descriptions. The description adds context that no file upload is needed, complementing the optional filename. However, since schema already documents parameters, the description adds only marginal value, meeting baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Crear archivo de conocimiento desde texto' (create knowledge file from text), with specific examples of content types (promotions, policies, FAQs) and the benefit of no manual upload. It distinguishes from siblings like edit_knowledge_snippet and update_knowledge_file by emphasizing creation from text.
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 'Ideal para añadir información como promociones, políticas, instrucciones, FAQs, etc. sin necesidad de subir un archivo manualmente', providing clear usage context. However, it does not explicitly state when not to use it or compare with alternatives like upload_docqa_file, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that the tool is a mutation requiring confirmation, that it fails without session_id, and explains the two-step confirmation process. However, it does not mention response details after successful scheduling (e.g., returns scheduled message ID) or idempotency.
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, uses clear section headers for prerequisite and flow, and is generally efficient. It is slightly verbose but still concise for the complexity involved.
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 prerequisite and confirmation flow well, but lacks details on the output when confirm=true (e.g., success response fields, scheduled message ID) and how to reference the scheduled message later for update/cancel. Given no output schema, this gap is notable.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 all parameters described. The description adds limited value beyond schema, mainly reinforcing the prerequisite for session_id and the confirm parameter role. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it schedules a WhatsApp message for future sending, distinguishing from immediate sending tools. However, it does not explicitly differentiate from related scheduling tools like update_scheduled_message, though the prerequisite and confirmation flow set it apart.
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?
Provides explicit mandatory prerequisite (call get_whatsapp_status) and detailed confirmation flow: first call returns requires_confirmation=true, then describe to user and stop; do not call again until confirm=true. This offers excellent when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It labels the operation as a mutation and mandates confirmation, which is helpful. However, it omits details about irreversibility, cascading effects, or required permissions, leaving behavioral gaps.
Agents need to know what a tool does to the world before 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 with a clarifying note, front-loading the core purpose. Every part is informative and necessary, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, the description covers the mutation nature and confirmation need, but lacks completeness on side effects, reversibility, and permissions. For a destructive tool with many siblings, it is adequate but not exhaustive.
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 the 'confirm' parameter ('pasar confirm=true para ejecutar'), clarifying its role in confirming a dangerous action. This goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an agent ('Elimina un agente'), specifies it's a mutation, and mentions confirmation requirement. This distinguishes it from other delete tools targeting different entities (e.g., delete_calendar, delete_ai_error).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that confirmation is required to execute, but does not explicitly state when to use this tool over alternatives (e.g., other delete tools) or provide prerequisites like needing the agent ID. Usage context is implied but not fully articulated.
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 no annotations provided, the description carries full burden. It explicitly labels the tool as a mutation ('[mutation]') and requires confirmation (confirm=true) for execution, which are key behavioral traits. However, it does not disclose whether the action is reversible or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parenthetical, front-loading the purpose and key condition. Every part is essential, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no output schema, the description covers the main points: what is deleted and the confirmation requirement. However, it omits potential side effects or prerequisites (e.g., connection must exist). Given simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds minimal extra meaning: 'connection_id' is restated, and 'confirm' is described as 'confirmar ejecución de esta acción peligrosa', which reinforces the need for confirmation but does not add new syntactic 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 tool deletes a calendar provider connection (Google/Microsoft), using a specific verb 'Elimina' and resource 'conexion de proveedor de calendario'. It distinguishes from sibling tools like delete_calendar or delete_calendar_event by specifying the target is a connection, not the calendar itself.
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 deleting a calendar connection, but does not provide explicit guidance on when to use this tool versus alternatives like delete_calendar. The confirmation requirement is noted, but no conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs a mutation (deletion) and requires confirmation. While it doesn't detail irreversibility or side effects, the core behavioral trait is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose, mutation label, and confirmation requirement 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?
For a simple delete operation with two parameters and no output schema, the description covers the essential context: what the tool does, that it requires confirmation, and the expected parameter roles. It could mention error handling or return status but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds minimal value beyond reinforcing the confirm parameter's purpose, 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?
The description clearly states the tool deletes a calendar notification, explicitly labels it as a mutation, and specifies the need for confirmation. The tool name itself distinguishes it from generic 'delete_notification' by including 'calendar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement for confirmation, which is a usage guideline, but does not compare this tool with siblings like 'delete_notification' or explain when to use this specific tool over 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?
No annotations are provided, so the description carries the burden. It clearly indicates the action is permanent ('permanentemente') and a mutation, plus the need for confirmation. However, it does not disclose potential side effects or irreversibility beyond the confirmation step.
Agents need to know what a tool does to the world before 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 Spanish with a parenthetical. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 12 parameters, the description only addresses the confirm parameter. It does not clarify that many parameters (like status, agent_id, phone) are likely not needed for deletion, leading to potential confusion. With no output schema or annotations, the description is incomplete 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% (all 12 parameters described), so baseline is 3. The description only adds context for the confirm parameter but does not explain the usage of other parameters (e.g., status, agent_id) which seem irrelevant for deletion. It adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool permanently deletes a task and requires confirmation. It uses a specific verb ('Eliminar'), identifies the resource ('tarea'), and distinguishes it from sibling tools like create_task, update_task, and list_tasks.
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 that confirmation is required by setting confirm=true to execute. It provides clear context on how to use the tool, though it 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As a getter with no annotations, the description's verb 'obtiene' (gets) reasonably implies a read operation. However, it does not explicitly state non-destructiveness or other traits.
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?
One concise sentence with a title. It is front-loaded and no waste, though could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks output details and the '[query]' hint is inconsistent with the schema. For a simple tool it is mostly adequate but has a minor flaw.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, baseline is 4. The description adds nothing about parameters, but none exist. The confusing '[query]' in the description does not match the empty 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 gets WhatsApp sessions available for sending campaigns. It distinguishes from siblings like 'get_chat_sessions' and 'assign_marketing_session'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving marketing sessions but does not explicitly state when to use vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool 'Genera el codigo de instalacion' (generates installation code), implying a read/generation operation. However, it does not disclose any additional behaviors such as authentication requirements, side effects, or rate limits. 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 short sentences with the key information front-loaded. Every sentence serves a clear purpose: stating what the tool does and when to use it. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the essential information. It could be improved by hinting at the output format (e.g., 'returns the embed code as a string'), but this is not critical for a straightforward 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% with enum descriptions. The description adds value by mapping the enum values to full names ('chat' -> 'Chat Web', etc.) and clarifies that the code is for installation. However, this is largely a restatement of the schema's enum descriptions, so the added value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Obtener codigo embed') and resource ('plugin'), and specifies three specific plugin types (Chat Web, Product Q&A, Doc Q&A). It distinguishes from sibling configuration tools by focusing on retrieval of the embed code for installation.
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: 'cuando el usuario necesite el codigo para instalar...' (when the user needs the code to install). It does not provide negative guidance 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It lists what data is shown but does not disclose any behavioral aspects like authentication, rate limits, or that it is read-only. The zero parameters imply no side effects, but explicit mention is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and lists key data fields. 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 no parameters and no output schema, the description adequately covers what the tool returns. It could explicitly state it retrieves data for the current user, but the context implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters. The description adds meaning by stating the tool returns referral data, commissions, and payout status, clarifying what the tool does without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows referral data, including referrals, pending/paid commissions, and payout request status. It distinguishes from sibling tools like generate_referral_code (which generates) and request_referral_payout (which submits requests).
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 referral data but does not explicitly state when to use this tool versus alternatives like get_credit_history or get_credits_info. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden. It correctly states the tool does not send the message, but lacks other behavioral details like permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with title, no wasted words. Purpose is front-loaded and succinct.
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 tool simplicity (one param, no output schema), description is largely complete. It explains core behavior and key distinction, though preview return format is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 conversation_hash fully (100% coverage). Description adds no extra meaning beyond the schema, so 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 generates a preview of a follow-up message without sending it, distinguishing it from sibling tools like trigger_smart_followup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'without actually sending it', guiding agents to use this tool for previews instead of actual sends. No explicit alternatives named but context from sibling list provides clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the [mutation] tag and confirmation requirement beyond the schema. But with no annotations, it fails to disclose permissions, reversibility, or response format, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and key condition. 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?
For a simple mutation tool with 2 parameters and no output schema, the description covers the core purpose and the confirmation safeguard. It could mention that removal is per session and permanent, but is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so base score is 3. The description reinforces the confirm parameter's role but adds no new meaning beyond what the schema already provides for session_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Eliminar foto de perfil') and the resource ('de WhatsApp', 'de una sesion'). It distinguishes from siblings like 'update_whatsapp_profile' and 'get_whatsapp_profile' by specifying removal.
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 requires confirmation ('pasar confirm=true para ejecutar'), which informs the agent that the tool should not be called without the confirm flag. However, it does not contrast with alternative tools or specify 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?
With no annotations, the description carries the full burden. It discloses that this is a mutation requiring confirmation (confirm=true) and describes the effect: resetting error counter and reactivating endpoints conditionally. It does not cover side effects or authorization needs but is adequate for the simple action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, using a dash to separate purpose and usage. Every sentence is informative 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 simple action and lack of output schema, the description covers the main functionality and conditional behavior. It could mention prerequisites (e.g., admin permissions) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter 'confirm' with 100% description coverage. The description adds context by stating the confirmation requirement and danger, but does not 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?
The description clearly states the verb 'Resetear' and the resources: 'contador de errores CRM' and 'reactiva los endpoints' if disabled. It distinguishes this tool from siblings like 'test_crm_endpoint' and 'get_crm_health_status' by focusing on resetting errors and reactivating endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when CRM endpoints are disabled due to consecutive errors and notes that confirmation is required. However, it does not explicitly compare to alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions resetting error state and retrying connection, plus the '[mutation]' tag. However, it lacks details on side effects, permissions, or behavior when not in error.
Agents need to know what a tool does to the world before 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 a tag, front-loaded with key information. 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?
For a simple tool with one parameter and no output schema, the description covers purpose, usage condition, and mutation nature. Could mention return type but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds 'ID de la cuenta de email a reintentar' which repeats the schema. No additional constraints or formats 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 verb 'reintentar' (retry) and resource 'cuenta de email', and distinguishes itself from siblings like 'test_email_connection' and 'update_email_account' by focusing on resetting error state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when an account is in error state after IMAP/SMTP failures. Does not mention when not to use, but the condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds behavioral context by stating the mutation effect and the scope of impact. However, it lacks details on side effects (e.g., what happens to existing analysis when toggled off) or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two sentences that front-load the purpose and include a [mutation] tag. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple toggle nature and full schema, the description is fairly complete. It explains the tool's effect and scope. However, it omits mention of return values (no output schema) and potential impact on existing media analysis, which would enhance 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% (both params described). The description adds value by expanding on the meaning of auto_describe_images (listing PDFs and audio), but does not address the second parameter auto_sentiment_analysis at all, leaving it ambiguous in the tool 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 it activates/deactivates automatic media reading (images, PDFs, audio) from WhatsApp. The verb 'Activar/desactivar' and resource 'lectura automatica de medios' are specific, and it distinguishes from sibling toggle tools by detailing the affected media types.
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 the scope (affects all AI systems: Piloto Automatico, WhatsApp Auto, respuestas manuales), providing clear context. However, it does not explicitly state when to use this tool versus sibling toggles like toggle_auto_sentiment_analysis, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it mutates sync mode and lists the two options. However, with no annotations, it does not cover side effects, required permissions, or what happens to existing sync state. The '[mutation]' tag adds some awareness but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the purpose and options without any unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no output schema, the description is adequate. It explains the core action and parameter values. Missing details like error scenarios or prerequisites are minor given the tool's simplicity.
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, but the description adds explanatory context for 'bidirectional' (syncs archive, delete, spam). This goes beyond schema enum values, providing clearer semantics for the sync_mode 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 tool updates IMAP sync mode for an email account, specifying the two possible modes (inbox only or bidirectional). It distinguishes itself from sibling tools like 'update_email_account' by focusing solely on sync configuration.
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 when changing sync mode but does not explicitly state when to use it vs alternatives like 'force_email_sync' or 'update_email_account'. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the check purpose but does not specify side effects (e.g., read-only) or return value. The prerequisites add context but behavioral details are lacking.
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, effectively conveying its purpose. However, the trailing '[query]' is potentially confusing and unexplained, detracting slightly from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not clarify what the tool returns (e.g., boolean). Prerequisites are covered, but the missing return type makes it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% description coverage, so the description does not need to explain them. Baseline 4 applies as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks e-commerce connection write permissions for syncing FAQs. It uses a specific verb and resource, distinguishing it from sibling tools like test_ecommerce_connection.
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 prerequisites (connected platform and configured plugin), giving clear context for when to use. However, it does not explicitly state when not to use or list 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?
With no annotations, the description carries the burden. It explicitly states the tool is a [mutation] and that it deletes the email, and requires confirmation. This discloses the core behavioral traits, though it could add details like irreversibility or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences total, front-loaded with the purpose and followed by a crucial usage note. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters with full schema coverage and no output schema, the description is minimal but covers the essential action, mutation flag, and confirmation requirement. It could explain return behavior or that the email is permanently deleted, but it's minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds marginal value. It reinforces the confirm parameter's role as a confirmation flag. 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 cancels a scheduled email and deletes it. The verb 'Cancel' and resource 'email programado' are specific. Among siblings like cancel_scheduled_message and cancel_campaign, this tool is distinctly for email cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the action is a mutation requiring confirmation (confirm=true), which provides clear usage context. However, it does not explicitly differentiate from other cancellation tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the allowed campaign statuses and that it downloads logs as CSV. It does not mention side effects, error handling, auth requirements, or rate limits. For a read operation, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. The inclusion of '[query]' at the end is slightly odd but doesn't detract significantly.
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 and no output schema, the description explains the action (export to CSV) and the status constraint. It does not describe the output format in detail or mention size limits, but it is sufficient for a simple export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter campaign_id has a clear schema description. The tool description adds context that the campaign must be in an allowed status, which goes beyond the schema and helps with correct 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 verb 'exportar' (export) and resource 'resultados de campana a CSV', specifying it downloads send logs of completed campaigns. It lists allowed statuses (completed, cancelled, paused, archived), which distinguishes it from sibling campaign tools like get_campaign_logs or start_campaign.
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 that it only works with campaigns in specific statuses (completadas, canceladas, pausadas, archivadas), providing clear context on when to use it. However, it does not mention alternatives or when not to use it beyond status constraints.
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 no annotations, the description carries the full burden. It correctly indicates a read-only operation ('list pending') and mentions the automatic error detection system. It doesn't disclose any side effects, but none are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, with no unnecessary words. It front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list operation with no output schema. However, it lacks information about the return format or fields in each suggestion, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'status' is fully described in the schema (filter by status with default). The description adds no additional meaning beyond the schema, which has 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing pending AI improvement suggestions from the automatic error detection system. It distinguishes from sibling tools like apply_training_suggestion and dismiss_training_suggestion.
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 these are suggestions needing owner review, implying when to use. It doesn't explicitly state when not to use or mention alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It conveys a read operation returning status, but lacks additional behavioral details like being non-destructive or requiring auth. Adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose. No unnecessary 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?
For a simple 0-param tool with no output schema, the description fully explains what it does and the kind of output (session statuses). 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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, which is acceptable when none are needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows WhatsApp connection status, listing all sessions with their current state (connected, disconnected, pending QR). It uses a specific verb and resource, distinguishing it from siblings like get_whatsapp_health or get_whatsapp_qr.
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 WhatsApp connection status but does not explicitly state when to use or avoid this tool compared to alternatives. No guidance on exclusions or 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?
No annotations are provided, so the description must convey behavior. It indicates a read operation returning a list of accounts with agents, implying no side effects. However, it does not explicitly state it is read-only or safe, which is acceptable but could be more precise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an appended '[query]' that is unclear. While concise, the bracket content adds confusion and could be removed. It is mostly efficient but slightly cryptic.
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 no output schema and no annotations, the description adequately explains that it returns all email accounts with assigned agents. It does not mention pagination or limits, but for a simple list operation, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (empty object), so the description need not add parameter details. The baseline score for 0 parameters is 4, and the description provides no additional information beyond the schema, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all email accounts with their assigned agents, using the verb 'list' and specific resource. This distinguishes it from sibling tools like get_email_account (singular) and create_email_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?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for listing all accounts, but doesn't mention scenarios or exclusions. Siblings include search tools, but no contrast 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?
The description reveals the tool is a pre-check that shows affected settings and alternative sessions. It states the precondition (disconnected state) but does not explicitly state that it is non-destructive; the name 'precheck' implies safety.
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 main purpose, and includes an important note. It is structured but could be slightly more organized with bullet points.
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 single parameter, no output schema, and no annotations, the description covers purpose, preconditions, and what it shows. It could clarify the output format (list of affected items), but is largely complete for a pre-check 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 (session_id) with schema coverage 100%. The description adds no extra meaning beyond the schema description, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Pre-verificar eliminación de sesión WhatsApp' and clearly states it shows affected configurations and alternative sessions, distinguishing it from the actual deletion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an important note that only disconnected sessions can be deleted and instructs to disconnect first if connected. It implicitly advises against using this for actual deletion, but could explicitly mention the sibling 'delete_whatsapp_session'.
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 mutation nature and the need for confirmation (confirm=true) beyond what the schema conveys. No contradictions with annotations (none provided). Could be improved by mentioning idempotency or error responses.
Agents need to know what a tool does to the world before 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: two sentences, front-loaded with the action, no wasted words. Perfectly sized for the information conveyed.
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?
Despite no output schema and no annotations, the description sufficiently guides an agent to invoke the tool correctly. It covers main parameters and a critical behavioral requirement (confirmation). Minor gap: no return value description, but acceptable for a mutation 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% (all params described). The description adds value by explaining the 'permissions' parameter can be null or an object with boolean flags, and clarifies the 'confirm' parameter's role. Exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves/updates agent permissions, using a specific verb and resource. It implicitly distinguishes from the sibling 'get_agent_permissions' (read) but does not explicitly mention alternatives.
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: use to update permissions, explains how to pass 'null' for all or an object for specific ones, and advises about the confirmation requirement. However, it lacks when-not-to-use guidance or explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description marks the operation as a mutation and notes the confirmation requirement, disclosing its destructive nature. No annotations are provided, so the description carries the full burden, and it does so adequately for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a dash and a parenthetical note, conveying the purpose and a critical usage condition without any filler. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential intent and safety requirement. No output schema exists, but for a delete tool, the return value is typically success/failure. It could mention that the deletion is permanent, but the confirmation requirement implies 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?
The input schema already describes both parameters (rule_id and confirm) with clear descriptions. The description adds no additional meaning beyond what the schema provides. With 100% 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 it deletes a calendar availability rule, using a specific verb and resource. It distinguishes from siblings like create, list, and update calendar availability rules.
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 the confirm parameter requirement, which is key for usage. However, it does not explicitly state when to use this tool versus alternatives like updating or listing, but the name and context make 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly labels the operation as a mutation ('[mutation]') and highlights the need for confirmation, indicating destructive behavior. While it lacks details on side effects or permissions, it adequately warns of the action's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with a clarification in parentheses. It conveys essential information without unnecessary words, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects, no output schema), the description is largely complete. It covers purpose, mutation flag, and confirmation requirement. It could mention permanence but is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions (100% coverage). The tool's description reiterates the confirmation flag but does not add significant new semantic meaning beyond what the schema already provides. The mutation label is the main addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Eliminar servicio de calendario') and specifies the resource ('servicio/tipo de cita del calendario'). It distinguishes from sibling tools like update_calendar_service or create_calendar_service by indicating it's a deletion operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a confirmation requirement ('requiere confirmación: pasar confirm=true para ejecutar'), guiding the agent on a necessary step. However, it does not provide explicit when-not-to-use instructions 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?
With no annotations, the description carries full burden. It states the mutation is irreversible and requires a confirmation parameter, covering key 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?
Two sentences with clear, front-loaded information and a tag [mutation]. 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?
The description adequately covers the tool's purpose, behavior, and parameters, but could mention prerequisites like list existence or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description doesn't add significant meaning beyond the schema's parameter descriptions, which already note the confirmation 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 tool deletes a contact list and all associated contacts, specifying a specific verb and resource. It distinguishes itself from sibling tools like remove_contact_from_list by mentioning cascading deletion.
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 deleting entire lists and notes irreversibility and confirmation requirement, but does not explicitly compare to alternatives like removing contacts individually.
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?
No annotations are provided, so the description carries full burden. It discloses that the action is irreversible ('Esta acción no se puede deshacer'), requires confirmation, and tags it as [mutation]. This gives sufficient behavioral context for safe usage.
Agents need to know what a tool does to the world before 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 a tag and a note. It front-loads the key purpose and safely, with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the effect (deletes account and emails), safety (irreversible, requires confirmation), and the confirm parameter. No output schema exists, but given the tool's finality, the description is adequate for an agent to decide and invoke correctly. Minor gap: does not specify if any error or success response is returned.
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 covers both parameters with descriptions (id and confirm). The description adds value by reinforcing the confirmation requirement and the irreversible nature, though schema coverage is 100%. A slight bump from baseline 3 due to added 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?
Description explicitly states 'Eliminar cuenta de email — Elimina una cuenta de correo y todos sus emails asociados.' It clearly identifies the action (delete), resource (email account), and scope (including all associated emails). This distinguishes it from other delete tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that confirmation is required (confirm=true) and the action is irreversible, implying it should be used with care. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., deactivating or archive options) nor when not to use it, leaving some 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?
Discloses that CRM records are anonymized rather than deleted, which is critical behavioral information. No annotations exist, so description carries full burden; it does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with all key info: purpose, side effect, and required confirmation. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two parameters, description explains the core action and side effect. Sibling tool for export provides differentiation. Missing output format or return value, but adequate for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions; description adds no extra semantic value beyond echoing that confirm is for dangerous action. Baseline score of 3 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?
Clear verb ('Eliminar'), specific resource ('datos del cliente'), GDPR context, and distinguishing sibling tool (gdpr_export_customer_data). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states requirement for confirmation parameter. Implies this is a dangerous delete operation, but doesn't explicitly state when not to use or alternatives beyond the sibling export tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It indicates a read-only operation by stating it shows information and does not mention any side effects. However, it does not explicitly state it is non-destructive or safe, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first focuses on purpose, second on usage guidance. No wasted words, front-loaded with key information. The [query] placeholder is minor but does not detract.
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 tool with no parameters and no output schema, the description adequately explains what it returns (credit details with specific fields). It is complete enough for its simplicity, though it could note that it does not modify data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. With 0 parameters, the baseline is 4, and the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 shows detailed information about credits, listing specific fields (free, purchased, used percentage, renewal date). It distinguishes itself from sibling tools by specifying when to use it: when the user asks specifically about credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this action when the user asks specifically about credits,' providing clear context. It does not mention when not to use it or alternatives, but given the specificity, it's 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 are absent, so description bears full burden. It indicates a list operation (no mutation), but does not explicitly state read-only behavior, pagination, or authentication needs. The safe read nature is implied by the 'get' prefix.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear title-like lead, no redundant info, and front-loaded purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filtered list tool, the description covers inputs well and implies output (a list of corrections). No output schema exists, but the tool's simplicity mitigates the gap. Could mention the format of returned corrections.
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 already covers parameters with descriptions and enum values, but the description adds practical usage context: 'pass no parameters to list all' and 'use single keywords only' for query. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'Customer AI Corrections' for the CUSTOMER-FACING WhatsApp AI, using a specific verb ('List') and resource ('corrections'). It distinguishes from siblings like get_ai_errors (internal AI) and delete_customer_ai_error.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: pass no parameters for all corrections, use category or query for filtering. Does not mention when to prefer this over sibling list tools, but the context of customer-facing vs internal AI is implied by the tool 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?
With no annotations, the description must disclose behavior. It states that messages and notes move from source to destination and marks the operation as [mutation]. The parameter description hints that the source thread is deleted. The description is clear but could mention additional side effects or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a mutation tag—no wasted words. Essential 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?
The description covers purpose, constraints, and required confirmation. Given no output schema, it is fairly complete, though it could mention error conditions or permissions. 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?
All three parameters have schema descriptions (100% coverage). The tool description adds no extra semantics beyond the schema; it only repeats the confirmation requirement. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool merges email threads, moving messages and notes from source to destination, and specifies the constraint of same email account. This distinguishes it from siblings like assign_email_thread or delete_email_thread.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a precondition (same email account) and a required confirmation parameter (confirm=true). However, it does not explicitly contrast with alternative tools for similar operations, leaving some ambiguity about when to use merge versus assign.
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?
No annotations provided, but description discloses destructive effect (invalidates key, blocks access) and confirmation requirement. Doesn't mention return value, but adequate given mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers purpose and effect, second gives usage guideline. No fluff, 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 purpose, effect, usage warning, and confirmation. Lacks output format but mutation tools often return simple success. Adequate for a dangerous action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with two boolean parameters. Description adds only that confirm=true executes the action, mostly redundant with schema descriptions. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it regenerates the API key, invalidates the current one, and blocks access. Distinguishes from sibling tools like get_api_key (read) and regenerate_plugin_token (different token).
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 'Usar solo si el usuario lo pide explicitamente' (use only if user explicitly asks) and notes it's a mutation requiring confirmation. No explicit alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly marks the tool as [mutation] and explicitly states it requires confirmation (confirm=true). It discloses that both conflicting snippets are rejected and a new one is created, but could be more precise about what 'reject' entails (e.g., deletion or archival).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and outcome. Every part adds value without redundancy. The use of [mutation] tag is 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 tool with no output schema and 4 parameters, the description covers the main logic: rejection of both snippets, creation of new one, and confirmation requirement. Missing details like return value or what happens to database state, but sufficient for basic 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of 'proposed_content' (content proposed by user), the 'confirm' parameter requirement, and the optional 'conflict_with_id' parameter's default behavior (taken from snippet's field).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Rechazar conflicto y proponer dato correcto' and explains it rejects both conflicting snippets and creates a new one with proposed content. It distinguishes from siblings like 'reject_knowledge_snippet' (likely single reject) and 'keep_both_knowledge_snippets' by its combination of actions.
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 when there is a knowledge conflict and the user wants to propose correct content. It mentions requiring confirmation (confirm=true) but does not explicitly differentiate when to use this tool vs other conflict resolution tools like 'resolve_knowledge_conflict' or 'edit_knowledge_snippet'.
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 no annotations, the description carries the burden. It discloses mutation behavior, the confirmation requirement, and automatic checks for unsubscribed contacts and negative sentiment. However, it could mention more about side effects or validation beyond these checks.
Agents need to know what a tool does to the world before 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 plus a short tag and note. It is front-loaded with the main action and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration update tool with many parameters and no output schema, the description covers the essential behavioral aspects: partial updates, auto checks, and confirmation. It lacks details about response format or prerequisites but is sufficiently complete 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?
The input schema has 100% description coverage, so the baseline is 3. The description adds overarching context (partial updates, auto checks) but does not provide additional per-parameter semantics 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 uses the verb 'Actualizar' (update) and specifies the resource 'configuración de seguimiento inteligente' (smart follow-up configuration). It clearly distinguishes from siblings like get_smart_followup_config and trigger_smart_followup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage hint: 'Solo envia los campos que quieras cambiar' (only send fields you want to change). It also explains automatic checks. However, it does not explicitly state when to avoid using this tool or compare it to 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?
No annotations are provided, so the description carries the full burden. It denotes a mutation with '[mutation]' and states it records a mistake, but lacks details on potential side effects, idempotency, auth requirements, or rate limits. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the purpose and usage. It is clear and structured, though slightly verbose. Every sentence serves a purpose, earning a high score.
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 (3 params, no output schema, no nested objects), the description covers purpose, usage, and parameter context adequately. It provides enough information for an 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 descriptions for all 3 parameters. The description adds minimal new meaning beyond the schema, e.g., 'The correct information or rule to remember' is almost identical. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Record', the resource 'AI Correction', and clearly distinguishes from sibling set_customer_ai_error by stating it is for YOUR OWN responses/behavior. The title 'Record AI Correction' reinforces the action.
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 call: 'when the user corrects you' and 'when you proactively detect you did something wrong'. Provides clear exclusion for errors in customer content, directing to set_customer_ai_error. This is excellent 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?
Without annotations, the description discloses that this is a mutation and requires a confirm flag for execution, labeling it a 'peligrosa' (dangerous) action. This provides sufficient behavioral transparency for an AI agent.
Agents need to know what a tool does to the world before 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, consisting of two short sentences that front-load the action and conditions. Every part is necessary and 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 (2 params, no output schema), the description covers the key aspects: what it does, when it can be used (draft/scheduled campaigns), and the confirmation requirement. It is mostly complete, though could mention expected outcome or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 already provides full description coverage for both parameters. The description adds context that confirm is needed for a dangerous action, which is helpful but does not significantly enhance 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?
The description clearly states the tool's purpose: to initiate a marketing campaign by sending mass emails. It specifies it works with campaigns in draft or scheduled status, distinguishing it from sibling tools like cancel_campaign or pause_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the tool works with campaigns in 'borrador' (draft) or 'programadas' (scheduled) status, implying it should not be used for already running campaigns. It also notes the need for confirmation, but does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates it's a mutation by including '[mutation]' and explains the fallback to configured values, but lacks details on side effects (e.g., HTTP request, potential errors) and does not cover rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundant information, and front-loads the purpose. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema, no annotations), the description is fairly complete. It covers purpose, default behavior, and mutation nature. Could be improved with success/failure indicators, but overall adequate.
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 clarifying that parameters are optional and will use store configuration if omitted, which is not evident from the 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 the tool tests a webhook by sending a test webhook, and specifies it uses configured URL/secret if parameters are omitted. This distinguishes it from sibling tools like configure_webhooks and get_webhook_config.
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 (to test a webhook) and explains the optional parameter behavior, but does not explicitly mention when not to use it or compare with 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?
With no annotations provided, the description carries the full burden. It discloses the mutation nature and the need for explicit confirmation. It doesn't detail effects of adding/removing functions, but the input schema covers that. Overall, adequate transparency for a simple mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a dash, front-loading the purpose and action. Every part earns its place, 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?
For a mutation tool with 3 parameters and no output schema, the description provides sufficient context: purpose, mutation flag, and confirmation requirement. It could mention return value or error handling, but not essential given schema completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what the schema already provides for parameters. It mentions confirm=true but that's in schema. No added semantic 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 configures custom AI functions (APIs) that the AI can call during conversations. It uses specific verb 'Configurar' and resource 'funciones personalizadas IA', distinguishing it from many update_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that the tool is a mutation requiring confirmation ('requiere confirmación: pasar confirm=true para ejecutar'). This gives clear context for when to use it, though it doesn't explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully handles transparency. It labels the tool as mutation, describes the confirmation flow (buttons, confirm parameter), and warns against multiple calls. However, it doesn't detail side effects or revertibility, but overall is quite transparent.
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 slightly long but well-structured with bold and caps for critical instructions. Each sentence serves a purpose: stating the action, giving prerequisites, warnings, and confirmation requirement. No fluff, though it could be marginally shorter.
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 and no output schema, the description covers usage context, mutation nature, confirmation mechanism, and links to get_webhook_config. It omits return value description, but the schema details parameters adequately. Overall, it provides sufficient context for an 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?
Input schema has 100% coverage, so baseline is 3. The description mentions 'URL, eventos, etc.' but does not add significant meaning beyond what the schema already provides for each parameter. It does reference the confirm parameter indirectly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 modifies webhook configuration ('Modifica la configuracion de webhooks'). It distinguishes from sibling tools like get_webhook_config by specifying that you must call that first. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidelines are provided: always call get_webhook_config before, confirm with user, only call with concrete data, and never call again after (as system will ask for button confirmation). The need for confirm=true is also noted. This helps the agent avoid misuse.
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?
No annotations provided, so description carries full burden. It clearly discloses that the deletion is permanent and requires confirmation, indicating destructive behavior. Could mention side effects like cascading deletions, but sufficient for a straightforward delete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with parenthetical note, front-loaded, no unnecessary words. Efficient and to the point.
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 is a simple delete; description covers identity, permanence, and confirmation requirement. No output schema needed. Complete given the tool's nature and sibling 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 already provides full descriptions for both parameters (100% coverage). Description reinforces the need for confirm=true but adds little beyond 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 the action (eliminar permanentemente) and resource (campaña de marketing masivo), distinguishing it from siblings like archive_campaign, pause_campaign, cancel_campaign. The [mutation] tag reinforces the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the requirement for a confirmation parameter (confirm=true to execute), providing clear usage guidelines. Lacks comparison to alternatives (e.g., archive vs delete), but the safety instruction 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 explicitly tags the action as a mutation, mentions resource deletion scope, and requires confirmation. With no annotations provided, the description carries the full burden and performs reasonably well, though it could detail what resources are associated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and includes necessary detail. 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 delete tool with two simple parameters and no output schema, the description is complete: it specifies the action, scope, and required confirmation. Sibling tools are covered by distinct names.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 no new meaning beyond what the schema already provides. The description repeats the confirmation requirement, but the schema already says the same.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a Doc-QA assistant and all associated resources, distinguishing it from sibling tools like delete_docqa_file. The verb 'eliminar' and resource 'asistente Doc-QA' 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 indicates it requires confirmation (pass confirm=true), which is a key usage guideline for a destructive action. However, it does not explicitly state when not to use or mention 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?
No annotations provided, so description carries full burden. It states it shows the current key and URL, implying read-only behavior. However, it doesn't explicitly confirm no side effects or disclose any other behavioral traits, which 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 a single sentence plus a usage directive, front-loaded with the purpose. Every part earns its place 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 no parameters and no output schema, the description adequately explains what the tool returns (API key and MCP server URL) and when to use it. It is complete for a simple getter 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?
Input schema is empty (no parameters). Schema description coverage is 100%. With 0 parameters, the description needs no additional param info; a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the current API key (token_ext) and MCP server URL. It uses a specific verb ('Ver' = view) and resource, distinguishing it from siblings like regenerate_api_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: when the user asks for API key, token, how to connect MCP, or configure Claude/Cursor/VS Code. While it doesn't explicitly state when not to use, the guidance is clear and sufficient for a simple read 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?
Without annotations, the description adds value by flagging the mutation, requiring confirmation, and setting a limit. However, it doesn't cover OAuth configuration (only mentions IMAP/SMTP), which is present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second adds constraints and behavior. Very concise and front-loaded with critical 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 19 parameters and no output schema or annotations, the description covers purpose, limit, and mutation traits. Missing return value details and OAuth mention, but the schema fills gaps. Decent completeness 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?
With 100% schema coverage, the baseline is 3. The description adds a business constraint (max 10 accounts) and a confirmation flag, exceeding schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 new email account with IMAP/SMTP configuration, distinguishing it from other email-related siblings like update_email_account or delete_email_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage limit (max 10 per store) and a confirmation requirement (confirm=true), which guides the agent on when to use. Lacks explicit alternatives but clearly defines conditions for execution.
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 mutation nature, cascade effect, and confirmation requirement. With no annotations, this description adequately covers behavioral traits. Could mention irreversibility or permissions, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and scope, no redundant information. Each sentence adds essential detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main aspects: action, scope, requirement. Lacks detail on response or behavior when confirm is false. For a destructive tool with no output schema, it is reasonably complete but could include more safety warnings.
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 provides parameter descriptions, but description adds context about cascade and that confirm must be true to execute. This adds 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 it deletes a calendar and its associated events, services, and availability. The verb 'Eliminar' and specific resource are explicit. Differentiates from siblings like delete_calendar_event by indicating cascade deletion.
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 condition for execution: requires confirm=true. However, lacks explicit guidance on when to use this vs other delete tools (e.g., delete_calendar_event). Context is clear but exclusions are omitted.
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?
With no annotations, the description fully carries the burden. It explicitly states 'permanently eliminates' and requires confirmation, clearly warning about the destructive nature and safety mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and includes the key behavioral note about confirmation. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with good schema coverage, the description is fairly complete. It covers purpose, permanence, and confirmation. However, it omits details on return values or success conditions, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions. The description repeats the confirmation requirement but adds no new meaning beyond what the parameter descriptions already provide, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it permanently deletes one or more FAQs from the Product Q&A plugin, distinguishing it from sibling tools like manage_faq (for other operations) and republish_faq (for publishing).
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 the need for confirmation (confirm=true) to execute, which is a key usage guideline. However, it does not provide explicit when-not-to-use or alternative tool references beyond the implied context of deletion.
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 no annotations, the description carries the full burden. It identifies the operation as a mutation via '[mutation]' and requires confirmation ('confirm=true'). It does not explicitly state irreversibility or data implications, but the migration parameter is described in the schema.
Agents need to know what a tool does to the world before 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 a mutation label and confirmation requirement. It is front-loaded with the main action and condition, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with 3 parameters and no output schema, the description covers the essential behavioral traits (precondition, mutation, confirmation). It could mention the sibling precheck tool for completeness, but it is sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The main description adds value by stating the precondition for session_id (must be disconnected), which is not in the schema. This extra context helps the agent select the correct session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Elimina una sesion de WhatsApp desconectada' (deletes a disconnected WhatsApp session), specifying the resource and action. It distinguishes from siblings by noting it only works with disconnected sessions, 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 a clear precondition: 'Solo funciona con sesiones en estado disconnected'. However, it does not explicitly mention when not to use this tool or suggest alternatives like the sibling 'precheck_delete_whatsapp_session' for verification.
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?
No annotations are provided, so the description carries the full burden. It discloses the mutation nature, deletion of auth data, and the need for confirmation. It could mention reversibility or side effects but is reasonably transparent.
Agents need to know what a tool does to the world before 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 and a note, front-loading the purpose. Every sentence contributes necessary information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers purpose, parameter conditions, and confirmation. It references a related tool for IDs. It does not describe success/failure responses but is sufficient for a simple mutation.
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%. The description adds context: session_id required when multiple numbers, references get_whatsapp_status for IDs, and labels confirm as required confirmation for a dangerous action. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool disconnects a WhatsApp session and deletes authentication data. It uses a specific verb ('Desconectar') and resource ('WhatsApp'), and distinguishes from siblings like connect_whatsapp and reconnect_whatsapp.
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 guidance: requires session_id if multiple numbers, and requires confirm=true for execution. However, it does not explicitly specify when to use this tool versus alternatives like delete_whatsapp_session or precheck_delete_whatsapp_session.
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 clearly states the action is safe ('SEGURA'), does not send messages or modify anything. However, lacks details on what the simulation entails (e.g., does it return logs or errors?) and no mention of permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear purpose, usage triggers, safety note, and use case variations. Slightly verbose but efficient. The trailing '[query]' is a minor flaw.
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 simulation tool with no annotations or output schema, the description provides comprehensive guidance: when to use, how to use multiple times, safety, and preferred over alternatives. 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 all 3 parameters with descriptions. The description adds context by suggesting multiple calls with different test_message, but this is reinforcement rather than new meaning. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates workflow execution without sending real messages. It differentiates from siblings by explicitly recommending this over save/update when validation is needed.
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 lists user phrases that trigger this tool ('pruebalo', 'simulalo', etc.) and advises preferring this over save/update for validation, providing clear when-to-use and 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?
No annotations are provided, so the description bears full responsibility. While it clearly indicates a read-only operation by stating 'obtiene la lista' (gets the list), it does not explicitly state the absence of side effects. However, the nature of a list tool is sufficiently clear.
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 main purpose. The inclusion of '[query]' at the end is a minor distraction but does not significantly harm clarity. Overall, it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could provide more details about the returned data (e.g., fields, pagination). It mentions that workflows have name and ID, but lacks information on whether the list is paginated or other metadata. This leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% (trivial). The description does not need to add parameter info. Baseline 4 applies per instructions. The trailing '[query]' is unclear but does not detract from parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Obtiene la lista de todos los workflows de automatizacion de WhatsApp'. It distinguishes from sibling tools like delete_whatsapp_workflow by specifying that it must be called before deletion to identify workflows by name and ID.
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 that calling this tool is mandatory before any deletion operations (delete_whatsapp_workflow, bulk_delete_workflows) and before combining workflows. This provides clear when-to-use guidance and differentiates from other 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?
No annotations are provided, so the description bears full responsibility. It discloses the mutation nature, the need for confirmation, and that the secondary record is eliminated. This provides adequate transparency for an agent to anticipate the destructive effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose, effect, and requirement. It is front-loaded with the action and resource, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters and no output schema, the description covers the core behavior and parameters. It does not explain return values or error handling, but this is acceptable for a straightforward destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaning beyond parameter names by specifying that comments, tags, and CRM data are combined during the merge. This helps an agent understand the full effect beyond just merging phone numbers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 merges two customer records into one, combining comments, tags, and CRM data. It specifies the action (fusionar), the resource (clientes), and the scope of merging, distinguishing it from other customer-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires confirmation via confirm=true to execute, indicating it's a dangerous operation. It does not explicitly state when to use versus alternatives, but the confirmation requirement provides clear guidance on cautious 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?
No annotations are provided, so the description must carry the behavioral burden. It includes '[mutation]' to indicate a write operation and defines the scope clearly. However, it does not disclose side effects (e.g., whether the correction is applied immediately or queued) or any error states, leaving some gaps.
Agents need to know what a tool does to the world before 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 well-structured with a clear header, followed by usage rules and an important note. Every sentence adds value without redundancy. It is concise yet comprehensive.
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 lack of output schema and annotations, the description covers purpose, usage boundaries, and sibling differentiation. However, it omits details about the result of recording (e.g., does it return a confirmation?) and any prerequisites, leaving minor completeness 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 description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 records a correction for customer-facing WhatsApp AI content. It specifies the exact scope (wrong info, tone, unnecessary questions) and distinguishes it from the sibling tool set_ai_error, which handles behavioral rules.
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 (only for content corrections) and when not to use (behavioral rules, referencing set_ai_error). The italicized note further clarifies a common misinterpretation, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description labels the tool as [mutation] and requires confirmation, communicating safety-critical behavior. It also describes the preview-before-execution pattern. However, it does not detail side effects like irreversibility or what happens after update, though the requirement for confirmation mitigates risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with clear front-loading of purpose, examples, and workflow. Could be more structured (e.g., bullet points) but remains concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (4 params, no output schema), the description adequately covers usage and workflow. However, it lacks details on the preview response format and error handling, which would be helpful for full autonomous 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?
Schema coverage is 100% with good parameter descriptions. The description adds workflow context (preview then confirm, use of selected_ids) beyond the schema, guiding effective invocation. However, it only moderately enhances understanding of each parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'actualización' (update) and resource 'conocimiento' (knowledge), with examples of user instructions that trigger it. Distinguishes from sibling tools like `edit_knowledge_snippet` by emphasizing intelligent search and batch update based on contradictions.
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 provides usage triggers (e.g., 'now we accept PayPal') and a two-phase workflow: call without confirm for preview, then with confirm=true and selected_ids to execute. This tells the agent exactly when and how to use the 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?
No annotations exist, so the description carries full burden. It states the operation is permanent and requires confirmation, which adequately discloses the destructive nature and necessary safeguard.
Agents need to know what a tool does to the world before 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 lines, front-loaded with the action and key details about permanence and confirmation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two parameters and no output schema, the description covers all necessary context: what it does, that it's permanent, and the confirmation requirement. Completely adequate.
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 100% of parameters. The description reinforces the confirm parameter's role (required to execute), adding semantic value 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?
The description clearly states the action 'Eliminar snippet de conocimiento' (delete knowledge snippet) and the permanent nature of the operation. It distinguishes itself from sibling tools like edit or approve by explicitly being a delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the key usage guideline: confirmation (confirm=true) is required for execution. It does not explicitly contrast with alternatives, but the context of deletion is clear from the name and 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?
With no annotations, the description fully bears the behavioral disclosure burden. It reveals that deletion is a mutation requiring confirmation, describes the special response flow, and marks it as a dangerous action. It does not discuss side effects or permissions, but the main behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph, front-loaded with purpose, then details the confirmation flow. While it could be slightly more concise, every sentence serves a purpose and the flow explanation is crucial for correct usage.
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 confirmation behavior, which is critical for this tool. There is no output schema, but the description explains the expected response format (requires_confirmation=true, success=false). It lacks details about success after confirmation, but given the deletion nature and lack of output schema, it 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?
Input schema already describes both parameters (id and confirm). The description adds value by explaining the confirm parameter's role in the confirmation flow and the need to pass true for execution, extending beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Eliminar plantilla de WhatsApp' and 'Elimina una plantilla de mensaje de WhatsApp', specifying the verb (delete) and resource (WhatsApp template). This distinguishes it from sibling tools like delete_contact_list or delete_agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on the confirmation flow: it explains that the action will return requires_confirmation=true with success=false, instructs the agent to describe to user and stop, and notes not to call again. It also states that confirm=true is required to execute, which is excellent usage 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?
With no annotations, the description carries the full burden. It discloses it's a polling endpoint and a query operation. While it does not detail rate limits or side effects, being a status check implies no destructive behavior. The revelation of polling intention adds transparency beyond the 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 a single sentence with a clear title and action. Every word is necessary: 'Estado de procesamiento de archivos' explains the resource, 'Obtiene el estado de procesamiento de todos los archivos de conocimiento' states the action, and 'polling endpoint' adds behavioral context. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is adequate. It explains the purpose and polling nature, but could benefit from mentioning what statuses are returned or typical polling intervals. Still, it's largely complete for a status endpoint.
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?
There are no parameters, so the schema coverage is 100%. The description adds meaning by specifying it retrieves status for all knowledge files, which is not evident from the empty schema alone. This is highly effective.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 gets the processing status of all knowledge files, using a specific verb ('Obtiene') and resource. It labels itself a 'polling endpoint,' distinguishing it from siblings like check_docqa_file_status which targets individual files.
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 it's a polling endpoint, implying repeated use for monitoring, but does not explicitly state when to use it over alternatives or include exclusions. The context of siblings is clear enough for an agent to infer.
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 manual QR scanning may be required, which is a behavioral trait beyond the schema. The [mutation] tag also indicates state change. No annotations are provided, so description partially fills the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a mutation tag. No wasted words; critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose, condition, and behavioral hints. Could mention expected result (e.g., success status) but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and the description adds context: session_id is required when multiple numbers exist, and references get_whatsapp_status to obtain IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 reconnects an existing WhatsApp session, distinguishing it from sibling tools like connect_whatsapp and disconnect_whatsapp. It adds specifics about QR scanning and session_id requirement when multiple numbers exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (to reconnect an existing session) and conditionally requires session_id. However, it does not explicitly exclude initial connection or reference alternative tools like connect_whatsapp.
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?
With no annotations, the description thoroughly discloses the confirmation behavior: initial response with requires_confirmation=true, the need for user confirmation, the fact that success=false is normal, and the instruction not to retry. It also notes the mutation nature and the confirm parameter's role, providing full transparency for the agent.
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 long but well-structured, starting with the main purpose, then phone format, then the crucial confirmation instructions. It uses emphasis effectively. While every sentence serves a purpose, it could be slightly more compact without losing 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?
The description covers the core sending function, phone format handling, and confirmation flow comprehensively. However, it omits details on post-confirmation behavior (e.g., success response), and lacks context for optional parameters and potential limitations like message length or rate limits, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters (100% coverage), so baseline is 3. The description adds value by explaining how to handle phone numbers without prefix and emphasizes the confirm parameter's role, which is not fully captured in the schema. However, it does not add context for optional parameters like session_id, archive_after_send, or direction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 this tool sends a WhatsApp message to a phone number, specifying the action and resource. It distinguishes from sibling tools like create_whatsapp_template or update_whatsapp_profile by focusing on sending a one-off message, including the required phone format and confirmation process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on phone number format (E.164), instructs the agent to ask for country if no prefix is given, and details the confirmation flow (requires_confirmation=true, success=false, no retry). However, it does not mention when to use this tool over alternatives like scheduling or templating, missing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description carries full burden. It discloses that the tool returns a preview without saving, automatically reads current prompt if omitted, and requires a follow-up save. Could mention error behavior or permissions, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise with imperative structure. Key information is front-loaded. Important directives are capitalized for emphasis. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return value ('devuelve el prompt modificado como preview') and workflow. Slightly incomplete on potential errors or limitations, but sufficient for agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters (100% coverage). Description adds context: for 'prompt', it clarifies optional behavior and eliminates need for prior get_prompt call; for 'instruction', provides usage examples. Adds clear 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?
The description clearly states 'Modifica el prompt existente segun una instruccion en lenguaje natural' with specific verb and resource. It explicitly marks this as the correct action for adding/changing/removing prompt content and distinguishes itself from saving via 'NO guarda los cambios'.
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?
Provides explicit when-to-use context: 'ESTA ES LA ACCION CORRECTA cuando el usuario quiere añadir, cambiar o quitar algo del prompt' with concrete examples. Also clearly states that after using this, the agent must call save_prompt: 'DEBES llamar a save_prompt para guardar los cambios'.
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?
With no annotations, the description fully discloses behavioral traits: it is a mutation requiring confirmation, describes the two-step API interaction (first call returns success=false with requires_confirmation=true), and warns that re-calling invalidates the confirmation token. It also states the need for the 'confirm' parameter to execute.
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 long but every sentence serves a purpose. It is front-loaded with the purpose and then provides step-by-step instructions. It could be slightly more concise, but the structure effectively guides the agent through a complex flow.
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 destructive nature and the required confirmation flow, the description is comprehensive. It covers prerequisites (list workflows), user confirmation, the two-step API behavior, and the confirm parameter. It also references sibling tools appropriately. No output schema, but the return behavior is partially described.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds no new meaning beyond the schema: it repeats 'Array de IDs de workflows' and 'pasar true para confirmar', which are already in the input schema. No additional parameter details are 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's purpose: 'Eliminar workflows en lote — Elimina multiples workflows de WhatsApp a la vez.' It specifies batch deletion of WhatsApp workflows, differentiating from the sibling tool 'delete_whatsapp_workflow' for single deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it mandates using 'list_whatsapp_workflows' first to obtain workflows and confirming with the user exact IDs. It warns against deleting without explicit confirmation, outlines the confirmation flow, and instructs the agent not to call the tool again after the initial response.
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?
No annotations provided. Description discloses mutation behavior, creation limit (10 per store), error handling strategy, automatic name generation, and default status. Adequately covers behavioral aspects beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with logical flow, front-loaded main purpose. Some verbosity due to detailed parameter explanations, but justified by tool complexity (7 params, nested objects). 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?
No output schema exists, but description covers purpose, parameters, limits, error handling, and alternatives. For a creation tool, it's fairly complete. Lacks explicit return value description.
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% (baseline 3). Description adds significant value: explains action types (reply_with_ai, reply, delay, ai_filter) with detailed options like pre_send_check, no_repeat, and ai_filter prompt; clarifies conditions, status, session_id, and id for update. Goes far beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a WhatsApp workflow for automation, specifies required fields (name and actions), mentions automatic name generation, and differentiates from sibling tools like list_whatsapp_workflows, update_whatsapp_workflow, and delete_whatsapp_workflow.
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 create a workflow), what to do if limit reached (call list_whatsapp_workflows and suggest deletion/reuse), default status, and when to use 'disabled'. Provides clear do-not-retry instruction on limit error.
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?
With no annotations, the description fully discloses behavioral traits: it's a mutation requiring confirmation, explains the confirmation flow in detail (returns requires_confirmation=true with success=false as normal), and notes that the custom part remains unchanged. This goes well beyond what annotations would 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 front-loaded with purpose and then explains the confirmation flow. It is informative but could be slightly more concise. Still, 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?
Despite no output schema and no annotations, the description covers all critical aspects: what the tool does, how to get the required version_id, the confirmation flow, and the behavior after the first call. It is complete 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 good descriptions for both parameters. The tool description does not add additional parameter meaning beyond the schema, so baseline 3 applies. The description does mention the confirmation flow but that is already implied by the confirm 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 tool reverts the auto-generated part of the prompt to a previous version while preserving the custom part. This is a specific verb+resource and differentiates from siblings like restore_default_prompt or get_prompt_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: first call without confirm to get the confirmation response, inform the user, stop, and let the system handle buttons. It also tells the agent to get version_id from get_prompt_history and not to call again after the confirmation response.
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 no annotations, the description carries full burden. It accurately describes a read-only operation and what data is returned. However, it does not mention potential errors or auth requirements, which is minor given simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first explains purpose and details, second gives usage guidance. No wasted words, front-loaded with core 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 no output schema, the description sufficiently details what is returned (activated, URL, events, secret). For a simple read tool with no params, this is 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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but baseline is 4 for zero parameters. No additional value needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads current webhook configuration, listing specific details (activated, URL, subscribed events, secret). It uses a specific verb 'Lee' and distinguishes from sibling tools like 'configure_webhooks' by advising to use this before modifying.
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 says to always use this action before configuring or modifying webhooks and when the user asks about their webhook configuration. This provides clear when-to-use and when-to-avoid 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?
With no annotations, the description discloses key behaviors: requires prior session, returns image URL, and informs status if already connected. It does not mention rate limits or authentication, but covers the main aspects adequately.
Agents need to know what a tool does to the world before 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 no wasted words. It front-loads the purpose, uses explicit formatting ('IMPORTANTE:'), and provides actionable instructions in a few sentences.
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 or output schema, the description covers purpose, prerequisites, alternative tool, and return format. It is complete for its 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?
The tool has no parameters and 100% schema coverage, so the description cannot add parameter details. Baseline is 4, and it appropriately adds context about prerequisites and return 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 explicitly states that it obtains the WhatsApp QR code for scanning. It distinguishes itself from sibling tools like connect_whatsapp by referencing it as an alternative when no session exists.
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?
It provides clear when-to-use guidance (requires a session in 'qr_pending' state), when-not-to-use (no session or already connected), and names the alternative tool (connect_whatsapp).
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?
With no annotations, the description carries full burden. It discloses partial update behavior, the need to copy full actions array when editing a message, and validation rules for delay seconds. Ends with '[mutation]' to explicitly indicate mutation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and front-loaded purpose. However, it is verbose with repeated warnings and somewhat lengthy, which could be more concise without losing 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?
Despite no output schema, the description is highly complete: covers id requirement, partial update, actions handling, validation, and special instructions for ai_filter. Given the tool's complexity (7 params, nested objects), it provides sufficient context for correct invocation.
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 description adds significant meaning: explains the id's critical role and how to obtain it, details each action type (reply_with_ai, delay, ai_filter), provides validation rules, and emphasizes partial update semantics. Much more than 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 'Modifica un workflow existente' with specific actions like changing conditions, keywords, actions, renaming, activating/deactivating. It distinguishes from siblings like create_whatsapp_workflow by requiring an id.
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 when-to-use guidance for follow-up responses, warns never to send without id, and gives detailed instructions for updating actions vs other fields. However, it doesn't explicitly mention when not to use this tool compared to alternatives like delete_whatsapp_workflow.
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?
With no annotations, description fully discloses destructive nature, confirmation requirement, two-step flow (first call returns requires_confirmation=true, second call needs confirm=true), and warns against re-calling prematurely. Very transparent.
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 long but well-structured: purpose, exclusions, alternative, pre-step, confirmation flow. Every sentence is necessary given the complexity. Slightly verbose but justified.
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 all agent needs: purpose, exclusions, alternative, mandatory pre-confirmation step, detailed confirmation flow, and behavioral response. No gaps for a destructive tool without 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?
Input schema has 2 params (id, confirm) with descriptions. Description adds context about the confirm parameter's role in the confirmation flow and the dangerous nature of the action, enhancing 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?
Description clearly states it is for permanently deleting a WhatsApp workflow, with explicit exclusions (editing, modifying, etc.) and naming sibling tool update_whatsapp_workflow. Verb 'Eliminar' and 'SOLO para BORRAR/ELIMINAR' are specific and distinct.
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?
Provides explicit when-to-use (only deletion) and when-not-to-use (editing, etc.), names alternative tool (update_whatsapp_workflow), and outlines a mandatory confirmation flow with pre-step to list workflows. Comprehensive 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?
With no annotations, the description fully discloses behavioral traits: it is a mutation tagged [mutation], requires confirmation via the confirm parameter, and describes the normal flow where the first call returns requires_confirmation=true. It warns against calling again and explains how to handle user insistence.
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 long but well-structured and front-loaded with the purpose and critical warning. Every sentence adds value, though it could be slightly more concise. However, the clarity and completeness outweigh the length.
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 complexity of the tool (mutation with confirmation flow, sibling tools for modification), the description covers all necessary aspects: when to use, step-by-step confirmation, error handling, and how to respond to user. No output schema is needed as the flow is explained.
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 context beyond the schema: it explains when to use the 'prompt' parameter vs apply_prompt_instruction, and how the 'confirm' parameter functions in the confirmation flow. This additional guidance justifies a 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 'Guardar prompt — Guarda un nuevo prompt para la IA', specifying the verb (guardar) and resource (prompt). It explicitly contrasts with apply_prompt_instruction for modifications, distinguishing it from a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: use apply_prompt_instruction for adding/modifying/removing parts of the prompt, and only use save_prompt for a complete replacement. It details the confirmation flow step-by-step, instructing the agent to stop after receiving requires_confirmation=true and never call again even if the user verbally confirms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/wazionapps/mcp-server'

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