postari

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses the 503 metrics_recalculating condition with retry guidance and that results are never partial sums, the null-vs-invented-0 semantics, and the delivered/sent denominators for rates. It also flags deprecated alias fields and a cross-tool naming mismatch (bounce_hard_rate vs bounce_rate_hard), which is valuable behavioral context beyond any structured field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and core metric list are front-loaded, and nearly every clause earns its place by encoding return-value semantics that no output schema captures. It is nonetheless a single dense run-on paragraph, which costs it a point on structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description compensates by documenting the return shape in depth: rate units and decimals, rate bases, hard/soft bounce separation, total_bounces composition, and the recalculation state. An agent has everything needed to call and interpret the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so from/to are already documented, and the baseline would be 3. The description adds meaning the schema lacks: both bounds are inclusive ('ambos incluidos') and the range is interpreted in the account's timezone, which materially affects how an agent sets the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names the resource (métricas globales de la cuenta) and enumerates the exact metrics returned (enviados, entregados, abrieron, clic, bajas, rebotes, contactos nuevos), which is concrete enough to distinguish it from list_campaigns or get_subscriber. It explicitly contrasts itself with get_campaign_stats at the end, letting an agent separate the two.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives solid selection context: it is scoped to account-wide metrics over a day range, the cohort is the send day (same source as /metricas), and get_campaign_stats is named for the per-campaign case. It stops short of a fully explicit when-to-use-this-vs-that rule, but an agent can route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 critical behavioral nuance that activation does not trigger sending, which prevents a common misunderstanding. It does not elaborate on permissions or return values, but for a status toggle this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the main action and a critical warning. No filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one required parameter and one optional boolean, the description covers the core behavior and the key caveat. The absence of output schema is not a major deficit here, but it could mention edge cases like invalid flow_id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning to the 'paused' parameter by showing its effect, but the schema already provides that description. It does not add any explanation for 'flow_id', which remains undocumented. With 50% schema coverage, the description only partially compensates for the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: putting the automation into service (active) or pausing it. It explicitly distinguishes itself from the sibling tool arm_flow by warning that activating does not send, which is essential for correct selection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance by naming arm_flow as the alternative for sending, effectively saying 'use this to change status, but for sending use arm_flow.' This is a clear when-not and alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It only states the basic action, omitting details like whether contacts are created if missing, duplicate 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence in Spanish fully captures the tool's purpose without any wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 is too minimal. It lacks information on return values, error conditions, prerequisites, and use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning by indicating that the contact can be specified via email or contact_id, and that list_id is the target list. However, it does not explain behavior when both email and contact_id are provided, or if neither, and does not cover the remaining parameters beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: adding a contact to a list, and specifies two identification methods (email or contact_id). It distinguishes from siblings like create_subscriber (creating a new subscriber) and tag_subscribers (adding tags).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_subscriber or tag_subscribers. 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral burden. It discloses major side effects: sends real emails, requires a specific confirmation string, is not retroactive, and depends on prior testing and account permissions. This goes beyond the schema by adding safety-relevant context, though it does not mention error behavior or return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main action, then lists prerequisites and a key limitation (non-retroactive) in two dense sentences. Every sentence earns its place, and there is no fluff, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 covers the essential aspects: purpose, side effects, prerequisites, and behavioral constraints. It does not describe return values or failure modes, but for an action that arms a flow, this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67% (flow_id lacks a description). The description mentions the 'confirm' requirement but merely restates what the schema already says ('debe ser exactamente "ARMAR ENVIOS"'). It does not explain flow_id or acknowledge_no_list_filter, though flow_id is self-explanatory from context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'ARMA la automatización' (arms the automation) and specifies the consequence: 'a partir de aquí envía correos REALES sola' (from here it sends real emails on its own). This distinguishes it from siblings like test_flow or activate_flow by emphasizing real sends and non-retroactivity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit prerequisites: literal confirmation with 'ARMAR ENVIOS', prior flow testing, and account permission for agent sends. This implies the tool should be used after test_flow and only when ready for real sends, giving clear usage context even though no alternative tools are explicitly named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses that without `aplicar:true` the tool is a dry run returning only a count, that it writes the reason onto the contact, and the precise removal criteria. It omits permission requirements and reversibility, but the destructive side effects and safe default are clearly explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each earning its place: core criteria, the exception, the side effect, and the dry-run default. The removal criteria are front-loaded. Slightly long but no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation tool with no annotations and no output schema, the description covers criteria, side effects, and dry-run behavior adequately. Only permission/prerequisite details are absent, which is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented. The description reinforces the dry-run semantics of `aplicar` and the account-wide scope when `list_id` is omitted, but adds little beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (removing contacts from circulation) on a specific resource (bounced subscribers) and defines the exact inclusion criteria (permanent bounce or 3 consecutive temporary bounces). An agent can understand the tool's behavior without opening the schema. No sibling performs this action, so differentiation is not needed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states when contacts qualify (permanent bounce, or 3 consecutive temporary bounces with no engagement) and, importantly, when they do NOT (a single temporary bounce never removes anyone). No alternative tool is named, but none of the siblings competes for this task, so the routing guidance is effectively complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the transparency burden. It discloses a key behavioral trait: the flow is created as a draft and disassembled, sending nothing until tested and activated. This goes beyond the schema and gives crucial context about the tool's 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action. Every sentence adds relevant information without unnecessary fluff, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, nested objects, and no output schema or annotations, the description is lean. It covers the core creation action and the draft state, but lacks details on return values, prerequisites, or post-creation workflow. The graph format clarification helps, but overall completeness is moderate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, with parameters like name, trigger_type, and trigger_config already described. The description adds value by clarifying that the 'graph' parameter uses the same format as get_flow's return value, which is helpful, but it does not expand on the other parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with the verb 'Crea' (creates) and resource 'automatización' (automation). It distinguishes itself from sibling tools like test_flow, activate_flow, and arm_flow by noting the automation is created in draft/disassembled state, implying a distinct creation step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is the first step in creating an automation, but does not explicitly state when to use it versus alternatives. The note about being born as a draft suggests subsequent use of test_flow and activate_flow, but this 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Al no haber anotaciones, la descripción asume la carga de revelar comportamiento. Indica el retorno (URL pública y código embebible) y un comportamiento por defecto (campo de correo cuando no se pasan campos). Aunque no detalla más efectos secundarios, aporta información útil más allá del esquema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

La descripción es de dos frases breves, directas y sin relleno. La información clave aparece al inicio y cada palabra aporta valor.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

La herramienta tiene 6 parámetros, sin anotaciones ni esquema de salida. La descripción cubre el propósito y el valor de retorno, pero deja sin contexto parámetros como double_optin y thank_you_message. Aun así, es suficiente para entender la operación básica de creación de formularios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

El esquema tiene un 50% de cobertura de descripciones y la descripción solo añade detalle sobre 'fields' (que por defecto incluye un campo de correo). No explica 'name', 'double_optin' ni 'thank_you_message', por lo que compensa parcialmente la falta de documentación de parámetros.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

La descripción usa el verbo 'Crea' y especifica el recurso 'formulario de captación', además de indicar que devuelve URL pública y código para embeber. Esto la distingue claramente de herramientas hermanas como create_list, create_flow o create_segment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No menciona cuándo usar esta herramienta frente a alternativas ni excluye casos (p. ej., update_form). La única indicación de uso es implícita: si no se pasan campos, se incluye uno de correo. No hay guía explícita de cuándo o cuándo no usarla.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It does state that the tool creates a resource and returns a public URL, which is helpful. However, it omits details about potential side effects, permissions, or error cases. The information provided is adequate but not rich enough to earn a higher score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured. The first sentence establishes the primary purpose and return value, and the second provides essential parameter context. Every sentence adds value with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (9 parameters with many optional) and no output schema, the description adequately covers the most important aspects: the return value (URL), the 'kind' variants, and the form integration. It does not need to repeat schema details. Some minor omissions, like default kind, are available in the schema, so the description is complete enough 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, and the description adds meaningful context for key parameters: it explains the 'kind' values (blocks, code, ai, iframe, external_url) and clarifies the purpose of form_id ('Conéctale un formulario... para que capte suscriptores'). This goes beyond the schema and compensates for parameters with no description in the schema, like iframe_url and external_url.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Crea una página de aterrizaje y devuelve su URL pública.' It specifies the resource (landing page) and the action (create) with an additional outcome (returns URL). It also enumerates the different 'kind' variants, distinguishing this tool from siblings like create_launch or update_landing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 create a landing page) and includes additional guidance on how to attach a form with form_id. While it doesn't explicitly mention alternatives like update_landing or list_landings, the tool's purpose is obvious and no misleading exclusions are present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the behavioral disclosure burden. It provides valuable behavior details: a launch groups campaign emails with dates, and if `stages` is omitted and type is curso/infoproducto, it seeds 8 standard stages (lead magnet → webinar → apertura de carrito → cierre). This goes beyond a simple 'creates a launch' statement, though it doesn't mention permissions, reversibility, or return shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundant content. The first sentence is front-loaded with the verb and object, and the second sentence adds a conditional behavioral rule. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 7 parameters, no output schema, and no annotations. The description explains the core purpose, the structure of a launch, and a key default behavior. It doesn't cover error conditions, return values, or all edge cases, but for a creation tool with high schema coverage, it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 7 parameters have schema descriptions, so baseline is 3. The description adds context beyond the schema by explaining the default seeding behavior tied to `stages` and `seed_default_stages`, and lists the specific 8-stage sequence, which the schema does not enumerate. This elevates the value to 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Crea un LANZAMIENTO' (Creates a launch), specifying the exact resource and verb. It clarifies the launch type with examples (curso, infoproducto, evento) and distinguishes from sibling tools like get_launch and list_launches by indicating this is the creation action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for creating a launch object and explains the default stage seeding, but it does not explicitly state when to use this over other creation tools like create_flow or create_campaign. No alternatives or when-not-to-use conditions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the burden of behavioral disclosure. It only states 'creates', implying mutation, but does not mention permissions, reversibility, or 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence. It is front-loaded with the core action, but could include more detail without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations, output schema, and sibling differentiation, the description is too minimal. It fails to provide necessary context such as how the list relates to subscribers, duplicate handling, or typical use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50% (the 'description' parameter lacks a description). The tool description does not add any meaning beyond what the schema provides; it merely repeats the concept of creating a list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 of contacts, using a specific verb and resource. However, it does not differentiate from sibling tools like 'add_subscriber_to_list' or 'list_lists', 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.

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, when not to use it, or any prerequisites or side effects.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden for behavioral disclosure. It reveals a key trait: the segment is a 'regla de quién entra que se recalcula sola' (self-recalculating rule), which is valuable. However, it doesn't mention potential side effects like overwriting existing segments, required permissions, or error scenarios, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core purpose ('Crea un segmento'), and adds just enough context to be useful. Every word earns its place, with no redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a nested `definition` object and no output schema or annotations. The description provides the core concept but not enough detail on constructing the definition JSON, what the return value is, or required prerequisites. It is adequate for basic understanding but leaves clear gaps for an AI agent to invoke it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (33%: only the 'definition' parameter has a description). The tool description helps by explaining the concept of a segment ('quién entra' rule), which clarifies what 'definition' should contain. However, it does not add semantics for 'name' or 'description' parameters, and the definition's JSON structure is only referenced via 'same JSON as the UI'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's function: 'Crea un segmento' (creates a segment) and differentiates it from sibling tools by explaining it's a self-recalculating 'who enters' rule used to segment launches without duplicating lists. This distinguishes it from create_list and create_launch, which are siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: 'Es lo que se usa para segmentar un lanzamiento sin duplicar listas' (it's what is used to segment a launch without duplicating lists). This implies when to use it, but it doesn't explicitly state when NOT to use it or name alternative tools. The guidance 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The only behavioral trait disclosed is the upsert ('no duplicar'). With no annotations, more details like idempotency, field merging behavior, or error handling are needed. The description 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no fluff, but it is too short for the tool's complexity. Conciseness is good, but structure suffers from omission of details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, upsert behavior, no output schema, and no annotations, the description is incomplete. It lacks return value info, conflict resolution specifics, and requirements beyond email.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no parameter-level information. Only 57% of parameters have schema descriptions, and the description does not compensate for the missing ones (phone, first_name, last_name). It adds no value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs an upsert (create or update) on a subscriber. The verb 'Crea o actualiza' and 'suscriptor' are specific. However, it does not explicitly contrast with sibling 'update_subscriber', which could cause minor ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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_subscriber' or 'add_subscriber_to_list'. The implied usage (to create or update) is not sufficient for a clear decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite having no annotations, the description discloses a key behavioral trait: idempotency. It explicitly states that if the tag already exists, it returns the existing one without duplicating. This adds context beyond the schema, though it does not cover permissions or response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core purpose and appends the idempotency behavior in parentheses. Every word earns its place, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple, the description lacks usage guidance and parameter semantics. It also does not mention return values or potential errors, and with no annotations or output schema, it carries more burden. The idempotency note is helpful but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, and the description does not explain the 'name' or 'color' parameters. It only mentions creating a tag and idempotency, leaving parameter semantics entirely to the schema's bare structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Crea una etiqueta' (creates a tag), using a specific verb and resource. It clearly distinguishes from sibling tools like create_flow or create_list by explicitly naming 'tag' as the resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 mentions idempotency but does not discuss use cases, prerequisites, or exclusions. Sibling tools like tag_subscribers or create_subscriber exist, but no differentiation is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosure. It reveals that templates can be duplicated from catalog and that catalog templates are shared and immutable. However, it doesn't address permissions, return behavior, or what happens if the template name already exists, leaving transparency gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main action, and includes a useful clarification about catalog templates. Every sentence carries meaning, so it is concise and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters, no output schema, and no annotations, the description should provide more detail about the template's content fields and return value. It only covers the duplication aspect, leaving many aspects of the tool undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description only adds context for from_template_id, which is already described in the schema. It doesn't explain the purpose of blocks, subject, preheader, or other fields, and the schema has low coverage (14%). Thus, the description adds minimal value for most parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an account-specific template ('Crea una plantilla propia de la cuenta') and optionally duplicates from a catalog using from_template_id. This specific verb+resource distinction sets it apart from catalog templates and differentiates it from sibling tools like create_flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool: when you need a custom template, and that catalog templates are shared and cannot be edited, so users should duplicate them here. This provides clear context, but it doesn't explicitly name alternative tools or state 'use this instead of X'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 return shape (veredicto sano/a_vigilar/en_riesgo + acciones priorizadas), the definitive-vs-temporal bounce distinction, and threshold values. It does not state auth/permission requirements or the read-only nature of the tool, but for a zero-param diagnostic the operational semantics are well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads scope and metrics, then judgment details, then the call-to-action. Dense but every clause earns its place; slightly heavy on parenthetical detail (bounce_rate_temporal, threshold percentages) that could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description does the work of explaining the return verdict, the prioritized actions, and the metric definitions. Complete enough to invoke and interpret. Missing only ancillary details such as data freshness beyond the 28-day window or whether the call is read-only.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so baseline is 4. The description adds real semantic value by defining the metric denominators (rebotes y quejas sobre ENVIADOS; open_rate sobre ENTREGADOS) and the healthy thresholds (<2 %, <0,1 %), which is exactly the meaning an agent needs to interpret the output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Diagnóstico de entregabilidad de la cuenta') with explicit scope (últimos 28 días) and enumerates exactly what is measured: rebotes, quejas, aperturas, salud del dominio (DNS). Distinguishable from sibling account_stats, which it explicitly references for the open_rate basis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Ends with an explicit trigger: 'Úsalo antes de un envío grande o si los correos no llegan.' It also clarifies the relationship to account_stats, so the agent can tell which tool computes what.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 describes the tool as listing actions (read-only behavior) and covers the what/on-what/when aspects. However, it does not mention authentication, scope, or rate limits; for a simple read tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the key purpose ('Transparencia...') and covers all essential information with zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one optional parameter and no output schema, the description adequately explains the purpose, scope, and output fields ('qué se hizo, sobre qué y cuándo'), providing sufficient context 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter 'limit'. The description adds no additional meaning beyond the schema's '1-100, default 50.' Baseline of 3 is appropriate as the schema already fully documents the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists account actions originated by an agent/AI, specifying sources (Atelier chat, agent API, A2A) and the purpose ('qué se hizo, sobre qué y cuándo'). The verb 'lista' and resource 'acciones de la cuenta originadas por un agente/IA' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the use case ('Para auditar lo que un agente ejecutó'), providing clear context. While no explicit alternatives or exclusions are given, the sibling tools are all different (campaigns, subscribers, etc.), so differentiation is inherent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers: it defines the computation path (base = today's active list members, excluded = filter removals), explains that audience_live_total is TODAY's public, discloses the post-send addition of recipients_snapshot, excluded_on_send (frequency cap and blocked domains) and remaining_to_send, and flags total_recipients as a deprecated alias. That is unusually rich 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The leading question front-loads the purpose and each following clause maps to a distinct return field, so the sentences largely earn their place. It is dense and slightly long, but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 must describe return values — and it enumerates the key fields and their meaning, plus the pre/post-send distinction and the deprecated alias. For a single-parameter read tool this leaves nothing an agent needs missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the lone parameter (campaign_id) is undocumented in both schema and description. The description implies a campaign context ('este correo') but never defines the identifier's source or format, so it only partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action (compute the REAL recipients of a campaign applying the saved filter) and frames it as the send-time path, which cleanly separates it from set_campaign_audience and get_campaign_stats. An agent knows exactly what question this tool answers without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than stated — 'aplicando el filtro guardado' and the pre-send framing suggest calling it before launch_campaign, but there is no explicit 'use this when X, use Y instead' guidance or prerequisite. The behavioral branch (extra fields if sending already started) implies a state but does not say when to prefer it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so extensively: it defines every metric, explains rate bases, clarifies null semantics, describes maturity states (sending/paused/settling), and warns that stale=true means unreliable numbers. This is exceptional behavioral disclosure for a read-only stats tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded with the core purpose, then systematically defines metrics. It avoids fluff and repetition, though the single long paragraph with semicolons could be better structured for scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 fully compensates by detailing return fields, rate calculations, maturity states, staleness, null behavior, and deprecated aliases. Nothing critical for correct interpretation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter campaign_id is fully documented in the schema. The description adds no additional parameter semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Métricas reales de una campaña leídas de los eventos en vivo', clearly identifying campaign-level live metrics. It does not explicitly differentiate from sibling tools like account_stats or list_campaigns, so it misses the top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no when-to-use guidance, no conditions for selecting this tool over alternatives, and no prerequisites. It only describes the data returned, leaving the agent to infer usage 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it defines each KPI, gives the conversion_rate formula and its 1-decimal/percentage formatting, and states the null condition when views are not measured. It also discloses a failure mode (503 metrics_unavailable, never an unannounced number). It does not mention permissions/auth, hence not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that front-loads the resource and return shape before drilling into KPI formulas. The parenthetical formula detail is heavy but each clause earns its place by disambiguating metric semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must explain returns, and it does: it enumerates the returned KPI fields, their units, and the null/error conditions. Only permission requirements and pagination/size concerns are unaddressed, which are minor for a single-record fetch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single form_id parameter, so the schema already documents it. The description adds no extra parameter-level meaning beyond that, which is the expected baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the resource (a form with its fields) plus the live KPI payload it returns, and names the sibling whose semantics it mirrors (list_forms). It is distinguishable from list_forms and create/update_form, though the verb itself is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance; the reference to list_forms only says the metric definitions match, not when to pick one over the other. An agent must infer that this is the single-form fetch by ID versus list_forms for enumeration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it defines the dedup rule ('cada campaña se suma una sola vez'), explains stages_sent vs stages_total, clarifies that metrics null means no email yet rather than 0, and specifies the denominators for each rate. It stops short of stating auth or rate-limit behavior, hence not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the metric definitions are genuinely needed given the absence of an output schema. However the content is delivered as a single dense run-on paragraph mixing purpose, formula definitions, null semantics, and deprecation notes, which hurts scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description does the heavy lifting by documenting return semantics, rate bases, and null handling thoroughly. The remaining gap is the input parameter, which is left entirely unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single parameter launch_id has no description. The tool text is entirely about output metrics and never clarifies what launch_id is, its source, or its format. It fails to compensate for the coverage gap, though the parameter name is largely self-evident.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: retrieves a launch with its stages and 'MÉTRICAS REALES'. The line 'Es la forma de saber cómo va un lanzamiento' makes the intent unambiguous. It does not, however, differentiate itself explicitly from siblings like list_launches or get_campaign_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Es la forma de saber cómo va un lanzamiento' implies the use case (assessing launch health), which gives implied usage. But there is no explicit when-to-use/when-not guidance and no reference to alternatives such as get_campaign_stats or list_launches, so an agent must infer routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 disclose the return shape in detail, including the bounce object and its enum-like values, which is genuinely useful. However it omits key behaviors such as what happens when the email is not found, error conditions, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the opening clause, and the remaining text is devoted to output detail that earns its place. The single dense sentence is somewhat heavy but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by describing return fields and the bounce structure, which is the key complexity. For a one-parameter lookup this is largely complete, though not-found behavior is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter and schema coverage is 100%, so the schema already fully documents 'email'. The description reinforces that the lookup is by correo but adds no syntax or format detail beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it finds a contact by email and returns its data, status, tags, and basic history. This is clearly a read-by-email lookup, implicitly distinct from create_subscriber/update_subscriber siblings. It does not, however, explicitly name an alternative tool to contrast with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied — search a subscriber by email — but there is no explicit when-to-use, when-not-to-use, or reference to an alternative such as list_lists or get_campaign_audience. The agent can infer the context but is given no routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses that the default is draft-only and does NOT send, that a second call with confirm_send:true is required to send, the required scopes (`write` for draft, `send` for send), and that agent sending must be enabled on the tenant. This is exactly the safety-relevant behavior an agent needs before invoking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and the critical default-no-send behavior, and efficiently sized for a complex tool. Loses a point for the low-value marketing line 'Es la forma de "dile el objetivo y Postari lo logra",' which earns no place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description still explains the return artifact (a draft with preview_html), the send confirmation path, and the auth scopes. For a 13-parameter agentic tool this is nearly complete; error handling is left to the schema (e.g. 409 smart_list_not_sendable).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 13 parameters, including confirm_send and scheduled_at. The description reinforces the confirm_send workflow but adds little parameter-level meaning beyond what the schema provides; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (lanza) and resource (campaña de correo) and clarifies it generates the email from a natural-language brief. This is clearly distinguishable from the launch-feature siblings (create_launch, get_launch, list_launches), which are a different resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the operative workflow: call it and get a draft by default, then call again with the same fields plus confirm_send:true (or scheduled_at) to actually send. Clear context for the two-step pattern, though it never names alternative siblings (e.g. send_transactional_email) 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.

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 linking/unlinking behavior, the prerequisite that the email must already be written, and the ability to modify title, date, and status. However, it does not mention side effects, overwrite behavior, or permission requirements, leaving some ambiguity for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise Spanish sentences, front-loaded with the primary action, then providing essential context and additional capabilities. Every sentence adds value with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and no annotations, the description covers both primary purposes (linking/unlinking and updating stage fields) and explains the KPI dependency. It omits return value or error behavior, but these are less critical for a straightforward tool. The required vs optional parameters are clear from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, and the description compensates by explaining that title, scheduled_at, and status are stage fields to update, and that campaign_id null disconnects. It doesn't explicitly describe launch_id and stage_id, but their role as identifiers is clear from tool name and required status. This adds meaning beyond the sparse schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it connects an already-written email to a launch stage (or disconnects with campaign_id null) and can also update stage title, date, or status. This specific verb-resource pair distinguishes it from sibling tools like launch_campaign or update_flow_emails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear situational context: without this link, the stage measures nothing, so use it to enable KPIs. It also notes the additional use case of updating stage fields. While it doesn't explicitly name alternatives or exclusions, it gives enough guidance for when to invoke the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so richly: it discloses that counters can lag a few minutes behind get_campaign_stats, enumerates exactly which fields return null and why (null = not measured), explains audience_count timing/audience_basis, and states null semantics rather than invented zeros. This is a substantial behavioral disclosure beyond any structured field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is relevant and front-loaded with the tool's purpose, and every clause about metric definitions earns its place given there is no output schema. However, it is one very dense, uninterrupted paragraph with no structure, making it hard to scan for an agent that only needs the purpose and status filter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 must explain return values, and it does so thoroughly: it defines enviados, entregados, abrieron, clics únicos, the rate denominators (rate_base "delivered"), and flags *_fraction as deprecated. Nothing needed to interpret the response is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real value the schema lacks: the enumerated status values (draft, scheduled, sending, sent) for a parameter whose schema has no enum. It does not elaborate on limit semantics beyond the schema's "1-500, default 20".

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Lista las campañas/correos del tenant con sus métricas") and immediately scopes what it returns. It distinguishes itself from get_campaign_stats and get_campaign_audience by naming them and stating which data belongs to which, so an agent can tell the three apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing to alternatives: the null counter fields must be requested from get_campaign_stats, and the exact net audience from get_campaign_audience. It also documents the status filter values. It lacks an explicit "use this when you want to enumerate campaigns" statement or any exclusions, so it stops short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden but only describes the output contents. It does not explicitly state read-only behavior, pagination, permissions, or error conditions. The historical aside about emails living 'buried in the flow' is colorful but not behaviorally informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is concise and informative, front-loading the core purpose and output details. The second sentence is an unnecessary poetic aside that adds no functional value, though it does not make the description overly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter list tool with no output schema, the description provides some return fields (node_id, subject, URL) but omits possible additional fields, pagination, ordering, and error handling. It is minimally adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, flow_id, has no schema description, and the tool description never mentions it by name. It implicitly equates flow with 'automatización' but does not explain the expected value, format, or how it affects the results, leaving the agent to infer from the parameter name alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (emails within an automation/flow) and lists key returned attributes (node_id, subject, own URL). It differentiates from sibling list tools by focusing on flow emails rather than campaigns, launches, or lists, though it lacks an explicit verb like 'list'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. It does not mention when to choose list_flow_emails over list_campaigns, list_launches, or update_flow_email, nor does it state any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It richly defines the KPI output semantics (people vs submissions vs views, conversion_rate formula and null case, views_measured flag), but it says nothing about pagination behavior, result limits, ordering, or any permission/rate constraints — and the existence of a 'limit' parameter implies pagination that goes unaddressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and each subsequent sentence defines a distinct KPI, so the length is largely earned given the absence of an output schema. It is a dense single block with no structural breaks, but there is little redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by explaining what each returned metric means and how conversion_rate is derived. It is strong on return-value semantics but incomplete on operational behavior (pagination, ordering, default result count) for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (limit and is_active) are already documented in the schema. The description adds no additional meaning about either parameter, so the baseline 3 for fully-covered schemas applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence 'Lista los formularios con sus KPIs' gives a specific verb (list) and resource (forms) plus the distinguishing detail that KPIs are included, which separates it from the singular get_form sibling. It is clear what the tool does, though it never explicitly contrasts itself with the alternative form-reading tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contains no when-to-use, when-not-to-use, or alternative-routing guidance. It never mentions get_form or explains the conditions under which a caller should list forms rather than fetch one, leaving usage entirely to inference 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the full behavioral burden; it does usefully disclose the exact conversion_rate semantics (formula, 2-decimal rounding, 100 cap, null-vs-0 distinction) and a dated contract change, which is real value. However it says nothing about read-only nature, pagination, ordering, or result size, so it is only partially transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the main clause, with the detailed metric rules correctly relegated to a parenthetical. It is dense but every clause (formula, cap, null semantics, contract date) carries information an agent would otherwise get wrong.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain the returned shape; it covers conversion_rate well but says nothing about visits/conversions format, the limit parameter, or pagination. Adequate for the headline metric but incomplete overall.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter (limit) at 0% schema description coverage, and the description never mentions it, so neither source explains its meaning, default, or range. The description does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Lista las páginas de aterrizaje') and names the metrics returned (visits, conversions, conversion rate), which cleanly separates it from create_landing/update_landing. It does not explicitly distinguish itself from the other list_* siblings, keeping it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of alternatives (e.g. get_form, list_launches), and no stated preconditions or exclusions. The agent must infer the usage context entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior. It indicates a read-only listing operation and adds details about the returned counts (stages and email connections). However, it does not mention pagination, rate limits, or any potential side effects, leaving some transparency gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the primary action and then adds key details. Every word contributes value without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains the tool's purpose and what it returns for a simple read-only list, but it omits any guidance on the parameters (limit, status) and the return format. Given the lack of an output schema, this leaves the agent with partial information for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only status has a description); the tool description does not explain the limit or status parameters. Since the description adds no meaning beyond the schema, it fails to compensate for the low coverage, especially for the undocumented limit parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists launches for the account and includes specific details (number of stages and email connections). This distinguishes it from siblings like get_launch (single launch) and list_campaigns (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing account launches but does not explicitly state when to use this over alternatives like get_launch or list_campaigns. No exclusion or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it explains that active_count means contacts receiving sends vs total_count being all memberships, names the source (list_sizes_v1, same as the app), discloses the size_ok=false null-count edge case, and flags contacts_count as a deprecated alias. This is rich semantic disclosure beyond the empty schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, followed by field semantics and caveats. Dense but every sentence adds meaning; only mild run-on tendency across the long first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 correctly fills that gap by defining active_count, total_count, size_ok, smart-list behavior, and the deprecated alias. It is nearly complete for a zero-parameter read tool; the only missing piece is explicit usage guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. The description appropriately spends its budget on return-value semantics rather than parameter explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Lista todas las listas de contactos') with an immediately clear scope: enumerate contact lists with their sizes. An agent can distinguish this from sibling write tools like create_list or the per-resource listers (list_campaigns, list_forms) without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never says when to call this tool versus alternatives, nor states any prerequisites or exclusions. It mentions that smart lists aren't currently sent to, but that is a data caveat, not usage guidance. No when/when-not framing is present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers: keyset pagination and ordering, a dated behavior change for tag vs imported_tags, the include_count 503 count_unavailable error (never 0), and the smart-list zero-row quirk. These are non-obvious behaviors an agent could not infer from 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and pagination model, then filters. It is a dense single paragraph where nearly every clause earns its place, though the tag-date clause is heavy for one sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description partially compensates by naming returned fields (tags, catalog_tags, total_count) and the cursor. It omits other row fields and rate/auth considerations, 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 83%, yet the description adds meaning beyond it: list_id is physical membership only, tag matches the exact catalog name with the imported_tags/catalog_tags distinction, and include_count's failure mode is spelled out. This is substantive enrichment, not repetition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list paginated contacts) plus ordering (most recent first, keyset cursor). It differentiates from siblings by routing smart-list size lookups to list_lists, so an agent can place it precisely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for each filter and a strong edge-case rule: list_id returns 0 rows for smart lists, whose size lives in list_lists. It stops short of naming a when-not or explicit alternatives beyond the count pointer, so it is strong but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers: it discloses side effects ('No reanuda flujos viejos ni envía la bienvenida'), error semantics (409 codes, domain_sugerido payload), and required preconditions. This is rich behavioral context beyond a plain mutation statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, followed by conditions, error behavior, and the sibling alternative. It is dense and slightly long, but each clause (bounce type, domain validity, 409 payload, side effects, alternative) earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter reactivation tool with no output schema or annotations, the description supplies preconditions, error responses, and side effects. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'email' parameter is already documented as accepting an email or id. The description's note about correcting the address (gmail.co, hormail.com) touches on input validity but does not add syntax or format meaning beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Devuelve a tus envíos a un contacto que salió por un rebote TEMPORAL') and immediately scopes it to temporary bounces, distinguishing it from generic subscriber updates. An agent can tell what it does and what it does not do.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists preconditions (temporal bounce only, domain not blocked/misspelled, no unsubscribe/spam), the failure mode (409 with reason), and names the alternative it replaces ('Úsalo en vez de update_subscriber con status "active"'). When/when-not/alternative are all present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the load, and it does disclose two real behavioral traits: 'Síncrono' and 'Requiere scope `send`'. The sensitive confirm_send gate and its account prerequisite are covered in the schema rather than the description. It still omits return/idempotency behavior, but the scope and sync disclosure is genuinely useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short clauses, zero waste, front-loaded with the core action and followed by scope and sync behavior. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-param send tool with no output schema and no annotations, the description covers purpose, synchronicity, scope, and recipient cardinality. What is missing is only post-call information (message id/status), which is minor given the safety gate is fully documented in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in Spanish with examples (mustache variables, template vs html_body, confirm_send). The description only conceptually references template and variables, adding nothing beyond the schema. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (sends a transactional email) with tight scope: '1-a-1 ... a UNA dirección, usando una plantilla y variables'. This cleanly separates it from the bulk-send siblings like launch_campaign and trigger_flow, so an agent can route correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The parenthetical examples (quote, receipt, welcome, reminder) and '1-a-1 a UNA dirección' give clear context for when this applies versus campaign/flow tools. It never explicitly names an alternative or a when-not condition, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It adds valuable behavioral context: returns the real recipient count and fails with HTTP 400 if any reference is missing instead of saving partially (atomicity). It does not disclose whether existing audience rules are overwritten, which is a minor gap, but the disclosed behaviors are significant and non-obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, each earning its place: purpose, return value/confirmation, and error behavior. It is front-loaded with the core function and avoids any filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 6 parameters, no output schema, and no annotations, the description provides a solid high-level overview including purpose, output behavior, and error handling. However, it omits mention of include_tags (positive targeting) and tag_on_delivery side effects, which are covered only in schema param descriptions. Overall, it is reasonably complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, and param descriptions in the schema are already informative (e.g., 'nombre o UUID', 'manda a A menos los de B'). The tool description adds no additional parameter meaning beyond restating the exclusion concepts, so it does not elevate above the baseline for well-documented schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool defines who receives an email and who does not, with specific exclusion criteria (tags, lists, previously received campaigns). It distinguishes from sibling get_campaign_audience by using the verb 'define' (set) and mentioning the return of the real recipient count, which is a unique behavioral feature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage before sending a campaign ('confirmar antes de enviar'), providing clear context for when to use it. However, it does not explicitly exclude alternatives or mention sibling tools like get_campaign_audience, so it lacks an explicit when-not-to-use statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 acknowledges mutability (add/remove) but omits details like idempotency, error behavior, or whether partial failures occur. The lack of annotation makes this 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-formed sentence with no extraneous information. Every word earns its place, providing efficient communication of the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters, no output schema, no annotations), the description is insufficient. It fails to describe return values, error conditions, or whether the tag must pre-exist. A more complete description would cover these aspects for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%; the description adds value by clarifying that emails or contact_ids identify contacts, and that multiple contacts are supported. However, it does not explain the relationship between these two parameters (mutual exclusivity) or the default operation value, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool adds or removes a tag to multiple contacts using emails or contact IDs. It uses specific verbs ('añade o quita') and identifies the resource ('etiqueta', 'contactos'), distinguishing it from sibling tools like update_subscriber or add_subscriber_to_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. It does not mention prerequisites, exclusions, or context for using tag_subscribers over other subscriber management tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 clearly states that the tool sends a real email ('enviándola de verdad') to one account member, defaulting to the owner, which is the key side effect. It could mention additional behavioral details (e.g., whether the flow state changes), but the disclosed info is sufficient for a test action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, front-loaded with the action and resource. Every clause adds value: the mandatory timing, the default recipient, and the restriction. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking annotations and an output schema, the description covers the core action, the required context (before arming), the recipient constraint, and the default behavior. These details are sufficient for an agent to select and invoke the tool correctly without additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only documents to_email; flow_id lacks a description. The description adds critical semantics for to_email: it must be from an account member and defaults to the owner. flow_id is left implicit, but the tool name and context make its purpose clear. The added value is meaningful despite the partial coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Prueba' (test) with a clear resource ('una automatización') and states the key scope: sending to one account member. This differentiates it from sibling tools like arm_flow, activate_flow, and trigger_flow, which operate on flows in different ways.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states 'Es OBLIGATORIO antes de armar' (mandatory before arming), giving a clear when-to-use directive. It also provides an exclusion: 'No se puede usar para mandar correo a terceros', which tells the agent 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must disclose behavior. It lacks details on idempotency, side effects, permissions, or what happens if the contact is already in the flow. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that conveys the core purpose without fluff. It could be slightly more informative but remains concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and no annotations, the description fails to cover important aspects like trigger_data usage, flow requirements, and behavioral implications. It is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 25% schema coverage, the description should compensate. It explains email and contact_id but says nothing about trigger_data, which is an arbitrary object. The param semantics are poor.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool puts a contact into an automatic flow using email or contact_id. It distinguishes from sibling tools like launch_campaign or list_campaigns, though it doesn't explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: use when you want to enroll a contact in a flow sequence. No explicit when-not or alternatives are provided, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and does well by disclosing that the tool cannot arm but can disarm via armed:false. It also scopes exactly which parts of the automation are editable. It doesn't cover permissions or return values, but the provided constraints are meaningful and prevent misuse.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences deliver the core purpose and a critical exclusion/alternative. The information is front-loaded, and every clause earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for a 6-parameter tool with nested objects and no output schema: it covers main editable fields, disarming semantics, and sibling differentiation. It lacks explicit mention of partial-update behavior (whether omitted fields are unchanged) or return format, but these are not essential for basic invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low (33%), so the description compensates by mapping human-readable concepts to parameters: 'nombre' (name), 'disparador' (trigger_config), 'pasos (graph)' (graph), and 'estado' (status). It also clarifies the armed semantic. Only flow_id is not spelled out, but it is required and self-evident.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Edita') and names the exact resource (una automatización) and fields (nombre, disparador, pasos, estado). It also explicitly differentiates from arm_flow by stating this tool is not for arming and can only disarm, eliminating ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear when-to-use versus when-not-to-use guidance: use for editing and disarming, not for arming. It names the alternative tool (arm_flow) and mentions its confirmation requirement, which helps the agent choose correctly among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full behavioral disclosure burden. It does add valuable context that changes are scoped to one email and do not affect the rest of the flow, which is a meaningful safety guarantee. However, it omits details like reversibility, required permissions, error conditions, or side effects beyond the scoped fields, which are important 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the main action and scope. The second sentence provides a safety rationale without unnecessary detail. Every word contributes value, and the structure is clean and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description excels at purpose and scope, it leaves gaps typical for a mutation tool with no annotations or output schema: no return value description, parameter format details for blocks, or error handling expectations. For a 6-parameter tool, the description is above the minimum viable but still incomplete for an agent needing full invocation confidence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at only 17%, the description compensates by explicitly naming all editable fields: subject, preheader, blocks, and label. This adds meaning beyond the bare property types. It does not explain the structure of blocks or the roles of flow_id and node_id, but these are inferable from the tool's purpose, so the compensation is solid but not complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb 'Edita' (edits) and identifies the resource as a specific email within an automation, listing the editable fields (subject, preheader, blocks, label). It also distinguishes itself from editing the entire flow by stating 'sin tocar el resto del flujo' (without touching the rest of the flow), which differentiates it from sibling update_flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: use this to modify a single email without affecting the rest of the flow. It suggests an alternative ('reescribir el graph entero' – rewriting the entire graph) and positions this as safer, implicitly indicating when to prefer this tool over a broader update. However, it does not explicitly name the alternative tool or provide 'when not to use' conditions, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 lists editable fields but does not disclose side effects such as whether existing fields are overwritten, whether permissions are required, or what happens to the form after update. This is a significant 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that covers most relevant aspects. It is front-loaded with the primary action ('Edita un formulario') and efficiently lists the editable attributes. However, the comma-separated list is slightly unwieldy but still earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters, no annotations, and no output schema, the description is incomplete. It omits the redirect_url parameter, lacks any note about postconditions or return values, and does not clarify how the update interacts with existing form data. This 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite having 0% schema coverage, the description adds meaningful semantics for 6 of the 8 parameters (e.g., 'lista donde caen las altas' clarifies list_id, 'doble opt-in' clarifies double_optin). However, it omits redirect_url and does not explain parameter types or constraints, leaving some gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Edita' = edits) and resource ('formulario' = form). It enumerates the editable aspects (title, fields, list, double opt-in, thank-you message, activation), which distinguishes it from sibling tools like create_form or update_flow by focusing on form-specific updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 implies usage for editing an existing form, but there are no exclusions, prerequisites, or mentions of when create_form or other update tools would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that changing the slug breaks shared URLs and that the response warns about it, which is valuable. However, it does not explain partial vs. full updates, permissions, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with purpose and editable fields, and adds a crucial warning in a concise manner. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 8 parameters and no output schema or annotations, the description is incomplete. It does not explain the return value, whether the update is partial or full, or how the remaining parameters behave, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning for some parameters (blocks as content, slug, form_id as connected form, is_active as activation) but leaves ai_prompt, html_code, name, and landing_id unexplained. Since schema coverage is 0%, this partial coverage is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool edits a landing page and lists the editable aspects (content, slug, connected form, activation). This distinguishes it from siblings like create_landing and list_landings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose implies use for editing existing landings but does not explicitly mention when to use this tool versus create_landing or list_landings. No exclusions or alternatives are stated, so guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses the scope of mutation, the deliberate exclusion of subscription state, the audit semantics of confirmar_resuscripcion, and the actual runtime failure (403 resuscripcion_no_disponible_para_agentes). It stops short of stating permission/auth requirements or the response shape, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and the field scope, then the alternative-tool routing. The final sentence is dense with an API path and error code, but that content is load-bearing (it explains the agent-only restriction) rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 0% schema description coverage, the description supplies the safety and boundary context an agent needs to call this correctly. The only real gaps are the required email identifier and the shape of the return, which are minor for an update tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 6 parameters, so the description must compensate. It names four fields (first_name/last_name as "nombre", country as "país", phone as "teléfono", tags as "etiquetas") but omits the required email parameter and gives no format hints for tags or country codes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Actualiza datos de un contacto existente") and enumerates the editable fields (nombre, país, teléfono, etiquetas). It distinguishes itself from state-change tools by clarifying it does not alter subscription status, though it doesn't explicitly differentiate from other writers like tag_subscribers or update_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it, what it will not do ("no cambia su estado de suscripción"), and names a sibling alternative (reactivate_bounced_subscriber) with its own trigger condition. It also spells out the case where no agent action is possible (unsubscribed/spam contacts) and why, which is unusually complete routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.