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

The annotations already signal a non-read-only, non-destructive mutation. The description adds useful behavioral context beyond that by explaining what 'deactivated' means: the invitation cannot be opened or confirmed. It does not contradict the annotations and gives an agent the state-change semantics needed to reason about consequences.

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 short sentences, front-loaded with the action and followed immediately by the key consequence. Every sentence earns its place and there is 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?

For a simple two-parameter toggle with annotations covering the safety profile, the description states what the tool does and what effect deactivation has. It could add explicit return-value or confirmation behavior, but no output schema exists and the operation is simple enough that the agent can invoke it correctly from the current text.

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 0% schema description coverage, the description must compensate, and it partially does: 'Activa o desactiva' maps to the boolean activa and the deactivation consequence clarifies the false state. However, it never explicitly names the parameters or states that activa=true enables and activa=false disables, leaving the mapping mostly inferential.

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 ('activate or deactivate') and a clear resource ('an invitation'), and defines a concrete consequence of the deactivated state. It is immediately distinguishable from sibling tools like crear_invitacion, editar_invitacion, and ver_invitacion.

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 usage context is implied rather than explicit: the description notes that when deactivated, no one can open or confirm the invitation, which suggests using it to control access. However, it never states 'use this when...' nor names alternatives or exclusions, so guidance is left to inference.

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?

Annotations already declare destructiveHint=false, so the tool is known to be non-destructive. The description adds the specific detail that it does not remove existing photos, providing concrete context beyond the annotation. This is useful for an agent to understand the exact scope of side effects, though it does not cover other potential behaviors like authentication or error conditions.

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

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

The description is a single, concise sentence that is front-loaded with the action ('Agrega fotos') and immediately clarifies the key non-destructive behavior. No unnecessary words 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 simple two-parameter tool with annotations covering safety, the description provides the core behavior and a key constraint. However, openWorldHint=true suggests there may be side effects (e.g., network calls) that are not disclosed. It also does not mention behavior for invalid inputs or what happens if the invitation ID does not exist, leaving some ambiguity.

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%, so the description must compensate for explaining parameters. It mentions 'fotos' and 'galería', which loosely map to 'urls' and 'invitacion_id', but does not explicitly state which parameter is which or provide details about expected formats. The agent must infer that 'urls' are the photo URLs and 'invitacion_id' identifies the gallery. This is insufficient given the lack of schema documentation.

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 verb 'agrega' (adds) and the resource 'fotos a la galería' (photos to gallery), making the tool's primary action unambiguous. It also explicitly distinguishes itself from destructive operations by noting 'sin quitar las que ya estaban' (without removing existing ones), which differentiates it from sibling tools like 'cambiar_foto_portada'.

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 want to add photos to a gallery) but does not explicitly mention alternatives or exclusions. It provides a hint about non-destructive behavior, but does not state 'use this instead of X' or give conditions for choosing between this and sibling tools like 'buscar_fotos'.

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?

Annotations already indicate this is a mutating but non-destructive operation, and the description aligns with that. It adds a little context by mentioning a personalized link and number of places, but it does not disclose side effects, requirements, or what happens on success.

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, direct sentence that front-loads the action. There is no wasted text or redundancy.

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 three flat parameters and no output schema, so the description should carry more weight. It is incomplete because it omits the meaning of the required invitacion_id parameter, does not clarify how the custom link is generated or supplied, and gives no selection guidance relative to sibling tools.

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 0% schema description coverage, the description must compensate, but it only hint at 'número de lugares' for lugares. It does not explain the required invitacion_id parameter or the nombre parameter, and 'link personalizado' does not map to any actual parameter in 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 ('Agrega un invitado') and the resource, which distinguishes it from listar_invitados and ver_invitacion. However, it does not explicitly distinguish it from crear_invitacion, and the mention of 'link personalizado' is not reflected in any schema parameter.

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 guidance about when to use this tool versus alternatives like crear_invitacion or editar_invitacion. The description does not mention prerequisites, such as needing an existing invitacion_id, or scenarios that would make this tool inappropriate.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds modest value by indicating the photos are 'listas para usar' and providing typical tags, but it does not disclose behavior like filtering semantics, result ordering, or whether an empty etiqueta returns all photos.

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 sentences with no filler. The core purpose is stated first, followed by a compact list of typical tags. Every word contributes meaning.

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 optional parameter and read-only annotations, the description provides sufficient context to understand the basic call: a catalog lookup with typical tag hints. It does not explain the return structure, but the tool's simplicity and the phrase 'con nombre' partially cover what to expect.

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%, so the description must compensate for the undocumented 'etiqueta' parameter. The description lists typical tag values such as boda, xv, and cumpleaños, which gives useful examples for the parameter. However, it never explicitly states that 'etiqueta' is a filter or what an empty value means, so it only partially compensates.

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 the tool is a catalog of ready-to-use photos for offering options to the user, which clearly identifies a photo-retrieval purpose. It distinguishes itself from sibling tools like agregar_fotos_galeria and cambiar_foto_portada by framing this as a read-side catalog, though it does not explicitly use a verb like 'buscar' or contrast with siblings.

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

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

The phrase 'para ofrecerle opciones al usuario' gives a clear usage context: use this tool when presenting selectable photo options to the user. It does not explicitly exclude alternatives or mention sibling tools, but the context is specific enough for a reasonable agent to know when to invoke 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?

The description's 'Pone' (sets) aligns with readOnlyHint=false (a modifying operation) and no contradiction exists. It adds value beyond annotations by constraining the image source to `buscar_fotos` results or public user images. However, it doesn't disclose what happens to the previous cover photo or any side effects, leaving behavioral depth limited.

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 with zero waste. The primary action is front-loaded ('Pone la foto principal de la invitación') followed by the input-source guidance. 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?

Adequate for a simple 2-parameter mutation tool with no output schema and no nested objects. It covers the core action and URL sourcing, but omits error cases, success confirmation, and what happens to the existing photo—gaps that matter for an agent calling a write operation.

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 0% schema description coverage, the description must compensate. It partially does by clarifying `url_foto` (must come from buscar_fotos or be a public image), but `invitacion_id` is left to its self-explanatory name with no added format or purpose detail. The compensation is incomplete given the low 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 states a specific verb and resource: 'Pone la foto principal de la invitación' (sets the main/cover photo of the invitation). This clearly distinguishes it from the sibling `agregar_fotos_galeria`, which adds to a gallery rather than setting a cover. The purpose is unambiguous and specific.

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 gives useful context on the URL source ('Usa una URL de buscar_fotos o una imagen pública del usuario'), which guides the agent on where to fetch input. However, it does not explicitly contrast this tool with `agregar_fotos_galeria` or state when NOT to use it, leaving alternatives implicit.

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 description adds meaningful behavioral context beyond the annotations: it is a blocking wait with an approximate 1-minute timeout and depends on user action in an external browser. The annotations already signal non-read-only/external-world behavior, and the description enriches that without contradicting it.

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, front-loaded sentence communicates the core behavior, the duration, and the dependency on user approval. Every word earns its place and there is no redundancy.

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 zero-argument tool with simple behavior, the description is largely complete: it says what happens, in what environment, and for how long. It does not state what occurs on timeout/failure or explicitly link to the prerequisite conectar_cuenta step, but sibling context and the simple shape make this 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?

The tool has zero parameters and 100% schema coverage, so there is nothing for the description to add. Per the rubric baseline, a 4 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 uses a specific verb ('Espera') and a concrete resource/outcome ('que el usuario apruebe la conexión en el navegador'), with a time bound. This clearly distinguishes it from siblings like conectar_cuenta (likely initiates) and estado_conexion (likely checks status).

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 intended context is implied: it waits after a connection has been initiated and requires user action in the browser. However, it never explicitly says 'call after conectar_cuenta' or mentions when not to use it, leaving the usage guidance mostly inferential.

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?

Beyond the annotations, the description explains a non-trivial interactive flow: it returns a link and code, the user must open the link and approve, and a successor call is required. This adds real behavioral context on top of readOnlyHint=false and openWorldHint=true.

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 sentences with no filler: the purpose is first, the returned artifacts and user action are second, and the next step is last. Every sentence adds necessary 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 one-optional-parameter tool with no output schema, the description covers the output (link and code) and the required follow-up. It is slightly incomplete only because it leaves the single parameter unexplained.

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 description never mentions 'nombre_del_agente'. The agent is left with only the schema title and default to infer meaning, so the description does not compensate for the missing parameter documentation.

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 the specific action 'Conecta (o renueva) el acceso a la cuenta InvitaAI del usuario', clearly identifying a verb and resource. It also distinguishes itself from the sibling tool completar_conexion by framing this as the initiation step that returns a link and code.

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 gives clear context: use this to connect or renew access, and it explicitly instructs 'Después llama completar_conexion' as the follow-up. It does not mention exclusions or when to prefer estado_conexion, 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?

Annotations already indicate this is a write operation (readOnlyHint=false), and the description adds useful behavioral details about accepted date and time formats. It does not disclose side effects, return values, or any system behavior beyond creation, but the create action is simple and reasonably transparent.

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

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

The description is two short sentences with no filler. The core purpose and the key formatting rules are front-loaded, making it easy for an agent to parse quickly.

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 create tool with 8 parameters and no output schema, the description gives the essential format requirements but omits a concrete usage example, any mention of required fields (tipo, titulo, fecha), or what response to expect after creation. These are partially recoverable from the schema, so the description is adequate but not fully complete.

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

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

The schema has no parameter descriptions (0% coverage), so the description must compensate. It explains the two most format-sensitive fields: fecha (AAAA-MM-DD) and hora (free-form, e.g., '18:00'). The other parameters are left to self-explanatory titles and enum/default values, so the compensation is partial but meaningful.

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 evento,' a specific verb and resource, clearly identifying the action and object. It also adds format constraints for date/time, which helps distinguish it from sibling tools like ver_evento or editar_evento.

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 makes clear this tool is for creating a new event, which implicitly tells an agent when to use it versus editing or viewing existing events. However, it does not explicitly name alternatives or conditions like 'use editar_evento to modify an existing event'.

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?

Beyond the annotations, the description discloses important behavior: if text parameters are omitted, generic templates are used. It also clarifies that the agent is expected to author the invitation texts rather than simply passing through user content. This adds meaningful behavioral context beyond the readOnlyHint and destructiveHint flags.

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 filler. It front-loads the main purpose and then gives a concrete operational instruction with a clear fallback. Every clause adds useful 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?

The description covers the core action and fallback behavior, but with nine parameters and no output schema, it could say more about what happens after creation, how to obtain event details, and whether duplicate invitations are possible. It is adequate for a first call but leaves some operational context implicit.

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%, so the description partially compensates by explaining that text parameters are optional and fall back to generic templates. However, it does not clarify individual parameters such as tema, codigo_vestimenta, linea_anfitrion, or mensaje_cierre, leaving per-parameter semantics mostly to the schema titles.

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 verb and resource: 'Crea la invitación digital de un evento.' This clearly distinguishes it from sibling tools such as ver_invitacion, editar_invitacion, and activar_invitacion, and adds the expectation that the agent should write the invitation texts.

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 gives clear context for when to use the tool: to create an event's digital invitation. It also instructs the agent to write the texts using the event information and the user's requested tone, with a fallback to generic templates. It does not explicitly mention alternatives or exclusions, but the intended use is evident.

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 annotations already indicate a non-read-only, non-destructive mutation. The description adds the key behavioral trait beyond annotations: this is a partial or patch-style update that changes only the explicitly indicated fields and leaves the rest untouched. This is valuable and consistent with the annotation hints.

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

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

A single front-loaded sentence communicates the action, resource, and update semantics with no filler. It is appropriately sized for the tool's complexity.

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 partial-update tool, the description plus the input schema and annotations is enough for an agent to select it and construct a valid call: pass evento_id and the fields to change. It does not describe return values or permissions, but those are not essential for this mutation tool and no output schema is expected.

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%, but the description's 'solo los campos que indiques' clarifies the meaning of the optional parameters: an agent should include only the fields to update and can omit the others. It does not, however, add per-field detail or explain the role of evento_id, so it only partially compensates for the missing schema descriptions.

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 gives a specific action ('Cambia'), a clear target ('un evento existente'), and an explicit scope ('solo los campos que indiques'). This distinguishes it from crear_evento (new events) and from ver_evento/listar_eventos (read-only), so an agent can identify the tool without relying on the name alone.

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 establishes a clear context: use it when an existing event must be modified, and only the fields supplied should change. It does not name alternatives like crear_evento, but the existing-event wording and partial-update wording make the selection obvious among the sibling 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?

Annotations indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds that it only touches what you send, leaving the rest unchanged, which is important behavioral context beyond annotations. It doesn't mention concurrency or error behavior, but given annotations cover safety, 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 with no waste. The key constraint (only touched what you send) is front-loaded, and the alternative usage is clearly stated. Perfectly 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 9 parameters, 0% schema coverage, and no output schema, the description does not list all parameters but the important ones (tema, textos) are covered. The openWorldHint annotation suggests flexibility, so the description's guidance is sufficient for an agent to understand the tool's purpose and constraints, though a fuller parameter list would be ideal.

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%, so the description must compensate. It mentions 'tema o los textos' which maps to multiple text parameters, but does not enumerate all 8 optional text fields. However, most parameter names are self-explanatory, and the description's partial compensation keeps it above 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 it edits an existing invitation's theme or texts, distinguishing it from creating a new invitation. The verb 'Cambia' and resource 'invitación existente' are specific.

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 says to use it instead of creating another invitation, which provides clear context for when to use this tool. However, it doesn't explicitly name the alternative tool (crear_invitacion) or mention exclusions for other edit 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?

Annotations already declare readOnlyHint=true, so the safe, non-mutating nature is covered. The description adds the useful behavioral detail that the tool reports account identity and remaining access duration, but does not disclose anything further such as output format or refresh behavior. No contradiction with annotations.

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

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

A single, information-dense sentence. It front-loads the core purpose and wastes no 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 simple zero-parameter, read-only status tool, the description gives the agent enough to know what information it will receive. It does not detail the output structure, but there is no output schema and the reported facts are self-explanatory. It is complete for practical invocation purposes.

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 has zero parameters, so the description need not explain parameter semantics. The rubric baseline for zero-parameter tools is 4, and nothing in the description detracts from that.

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 ('Muestra') and clearly identifies the resource: the connected account and remaining access days. It is easily distinguished from sibling tools like conectar_cuenta, which mutate the connection state.

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 a status-checking use case, but it does not explicitly state when to prefer this tool over conectar_cuenta or completar_conexion. There are no exclusions or alternative-naming cues, leaving usage timing to inference.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds that the result includes confirmation counts, which is useful, but it does not disclose other behavioral details such as sorting, pagination, or auth requirements. This matches the lower burden for annotation-covered tools but is not especially rich.

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 front-loaded sentence says exactly what the tool returns with no filler. Every word contributes to meaning.

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 no-parameter, read-only listing tool with an output schema and clear annotations, the description is complete. There are no prerequisite inputs to explain and the key return characteristic, confirmation count, is included.

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 has zero parameters, so there is nothing to explain in the description. Schema coverage is trivially 100% and the description instead clarifies the return content, which is appropriate. The baseline of 4 applies because parameter semantics require no compensation.

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 a specific verb and resource: listing the user's events, and adds the distinguishing detail that it includes the confirmation count. This makes it clearly distinct from sibling tools like ver_evento (individual event detail) and listar_invitados (invitees).

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 phrase 'eventos del usuario' provides clear context for the tool's scope: use it when the goal is to retrieve the current user's event list with confirmation counts. It does not name exclusions or alternatives, but the singular/plural contrast with ver_evento and the mention of counts supply enough contextual signal for a simple parameterless listing 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?

Annotations already declare readOnlyHint=true, so the read-only behavior is covered. The description adds useful context about the returned guest data, but it does not disclose pagination, filtering, or other behavioral details beyond the annotations.

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

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

The description is very short and front-loaded with the key output concept. It wastes no words, though it is a noun phrase rather than a full imperative 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?

Given the simple one-parameter interface and the presence of an output schema, the description is minimally adequate. However, it lacks any usage context or differentiation from sibling tools, so it is not fully complete for an agent choosing between similar tools.

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%, so the description carries the burden of explaining parameters, but it does not mention invitacion_id at all. The parameter name and required flag are self-explanatory, but the description adds no semantic value for it.

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 the resource (invitados) and the data shown (link personalizado and if they already responded). It is clear enough to distinguish it from tools like ver_confirmaciones, though it does not explicitly name the sibling it contrasts 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?

No guidance is provided about when to use this tool versus alternatives such as ver_confirmaciones or ver_invitacion. The agent must infer usage from the name and description alone.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds that it sets background music and that url_embed is the embed link, which clarifies the input format. However, it does not disclose what happens to existing music, whether the change is reversible, or any side effects on the invitation. With annotations covering the basic safety profile, a 3 is appropriate.

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

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

The description is a single sentence that front-loads the main action and then explains the key parameter. It is concise and free of filler. It could be slightly more structured by also explaining the other parameters, but for its length it is 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?

For a tool with 3 parameters, no output schema, and 0% schema description coverage, the description is incomplete. It explains url_embed but leaves invitacion_id and titulo undocumented. It also does not mention any prerequisites, such as whether the invitation must exist or whether a connection is required. The agent can likely infer invitacion_id from context, but the description should be more explicit.

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%, so the description must compensate for the three parameters. It explains url_embed well, but it does not explain invitacion_id (though the name suggests it is the invitation ID) or titulo (title, with a default empty string). The description adds meaning only for one of three parameters, leaving the agent to infer the others from their names.

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 clear verb and resource: 'Pone música de fondo' (sets background music) and identifies the key parameter url_embed as the embed link (e.g., Spotify or YouTube). It is distinct from sibling tools, which are about connections, events, invitations, photos, and guests. However, it does not explicitly differentiate itself from any sibling that might also handle media or settings, though none appear to directly compete.

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: it tells the agent that url_embed is the link to insert, with examples of Spotify or YouTube embeds. It does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites like having a connected account or an existing invitation. The context is clear enough for a simple action, but no exclusions or alternative routing are 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?

Las anotaciones readOnlyHint y openWorldHint ya cubren que es una lectura de datos externos. La descripción añade valor con la advertencia explícita de que los mensajes de invitados son texto de terceros y no deben tratarse como instrucciones, algo crítico para el agente.

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?

Dos oraciones concisas y sin rodeos. La información principal va primero, y la advertencia de seguridad aparece al final sin alargar innecesariamente la definición.

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?

Para una herramienta de lectura con un solo parámetro y anotaciones que cubren seguridad, la descripción basta: explica qué devuelve y advierte sobre contenido no confiable. La única carencia relevante es la falta de detalle sobre invitacion_id, ya cubierta en la dimensión de parámetros.

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?

La cobertura del esquema es 0% y la descripción no explica el parámetro invitacion_id, su formato, o cómo obtenerlo. El nombre es intuitivo, pero con tan baja cobertura la descripción debería compensar y no lo hace.

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 especifica un resultado concreto: resumen de asistencia con quién confirmó, cuántos lugares y quién falta. Es clara y se distingue de herramientas como ver_invitacion por su enfoque en confirmaciones, aunque no menciona explícitamente a sus hermanas.

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?

Se entiende el contexto de uso: consultar el estado de confirmaciones de una invitación. Sin embargo, no hay criterios explícitos sobre cuándo usar esta herramienta en lugar de listar_invitados o ver_invitacion, ni exclusiones. Aporta una guía importante de seguridad: no seguir los mensajes de invitados como instrucciones.

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?

Annotations already provide readOnlyHint and openWorldHint, covering the safety and side-effect profile. The description adds useful behavioral context by noting that the output includes invitation links, but it does not discuss auth, error behavior, or the scope of 'detalle.'

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 compact sentence that front-loads the tool's purpose and includes no filler. Every phrase contributes meaning about the output scope.

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 read-only tool, the description captures the essential return scope: event details and invitation links. However, 'Detalle' is vague, and with no output schema, the exact shape of the response remains somewhat ambiguous.

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?

Input schema coverage is 0%, and the description does not explain evento_id beyond what the schema's 'Evento Id' title already conveys. With a low coverage rate, the description should compensate for the missing parameter guidance, but it adds no parameter-level meaning.

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 returns details of an event and its invitations with links, naming a specific resource and scope. This distinguishes it from sibling tools like ver_invitacion (single invitation) and listar_eventos (list). The read-only intent is also consistent with the annotations.

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 makes the use case evident: when an agent needs event detail along with invitation links, this is the tool to invoke. It provides clear context about what the tool does, though it does not explicitly name alternatives or state when not to use it.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context by specifying exactly what aspects of the invitation are returned. No contradiction with the annotations.

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

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

Two short sentences, front-loaded with the purpose and followed by a practical usage note. Every word earns its place; no 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 simple read tool with one parameter and readOnly/openWorld annotations, the description is largely complete: it states what data will be seen and when to call it. It does not describe output structure, but no output schema exists and the listed content areas give enough context for an agent to interpret the result.

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 description does not explain invitacion_id beyond what the schema already provides via its name and title. The parameter is simple, but the description does not compensate for the absence of schema documentation.

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 says what the tool does: it shows the current state of an invitation, listing the specific parts it covers (tema, textos, foto de portada, galería, música). The phrase 'Úsala antes de editar' also distinguishes it from editar_invitacion as a read-before-edit operation.

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 gives an explicit usage context: use this before editing. It does not enumerate when not to use it or mention alternatives like editar_invitacion by name, but the intended workflow is clear.

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