Sarao

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

Las anotaciones ya declaran readOnlyHint=true y openWorldHint=false, así que la seguridad de la operación está cubierta. La descripción añade contexto conductual relevante que las anotaciones no aportan: ventana temporal de cobertura, comportamiento por defecto (solo futuros) y el mensaje que debe darse ante consultas fuera de rango. No detalla ordenación ni paginación, de ahí que no sea un 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?

Tres frases con la información importante al principio: propósito y alcance, luego campos devueltos y finalmente las salvedades temporales. La enumeración de ciudades duplica lo que ya está en el esquema y es el único fragmento prescindible.

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 solo lectura, con cinco parámetros opcionales, sin esquema de salida y con anotaciones que cubren el perfil de seguridad, la descripción aporta lo necesario: qué devuelve, qué rango temporal cubre, el comportamiento por defecto y cómo manejar consultas fuera del horizonte de datos. No queda ninguna laguna relevante para invocarla correctamente.

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 de descripción del esquema es del 100%, por lo que el esquema ya documenta los cinco parámetros, incluido el comportamiento de 'texto' cuando no hay coincidencias. La descripción repite la lista de ciudades que ya aparece en el esquema y no añade sintaxis ni matices adicionales sobre los parámetros, así que se aplica la base de 3.

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 indica un verbo y un recurso concretos (buscar encuentros de IA) y delimita el alcance con precisión: presenciales, gratuitos o casi gratuitos, en España y en siete ciudades. Queda claro qué devuelve y para qué sirve, aunque no menciona explícitamente al hermano 'ciudades' ni explica en qué se diferencia de él.

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?

Da contexto operativo útil: por defecto solo eventos futuros y la agenda cubre aproximadamente los próximos dos meses, con instrucción de qué responder si preguntan por fechas más lejanas. Falta una indicación explícita de cuándo usar esta herramienta frente a 'ciudades' o de cuándo no usarla, por lo que no llega al nivel de guía completa con alternativas.

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=false, covering the safety and scope profile. The description adds a useful hint about the returned data (per-city future event counts), but nothing about format, ordering, or freshness of the counts.

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 well-formed sentence that front-loads the resource and states what is returned, 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?

With no output schema, the description usefully discloses the return content (cities plus future event counts), which is the main thing an agent needs. Minor gaps remain around output ordering or format, but for a zero-parameter discovery tool it is nearly 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?

The tool takes zero parameters, so the schema carries no semantic burden and the baseline of 4 applies. There is nothing for the description to disambiguate.

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 (lista/list) and resource (ciudades) plus the returned payload (future-event counts per city), so the tool's job is unambiguous. It does not explicitly contrast with buscar_eventos, but the two are clearly distinguishable by 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?

There is no explicit guidance on when to use this versus buscar_eventos; usage is only implied by the fact that it returns the catalog of covered cities. No prerequisites or exclusions are stated.

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?

readOnlyHint=true and openWorldHint=false already establish that this is a safe, self-contained read, so the description only needs to add context. It does add real value: the fallback script for out-of-coverage cities. But it says nothing about what the tool actually returns (a fixed text block? links? markdown?) or whether the content is static, which is the salient behavioral question for a content-delivery 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?

Word count is reasonable, but it is delivered as one long run-on sentence with an imperative instruction ('si preguntan por otra, dilo y ofrece...') buried in a parenthetical mid-enumeration, which makes it harder to parse than a short topic list plus a separate routing line. The front-loaded contrast with buscar_eventos is the strongest structural choice.

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, no-output-schema informational tool, the description enumerates enough of the covered topics that an agent can decide whether a caller's question falls inside its scope. The one gap is the unresolved boundary with 'ciudades', which matters because that sibling exists.

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 input schema has zero properties, so there are no parameters whose semantics could be elaborated; the baseline of 4 applies. Nothing in the description misrepresents the parameter surface.

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 'Lo que no es buscar eventos' explicitly positions the tool against the sibling buscar_eventos, and the sentence enumerates concrete content: authorship/contact, city coverage, event-proposal links, newsletter, MCP setup, suggestions. It is clear what the tool is. However, the claim that it answers 'qué ciudades cubre' overlaps with the sibling 'ciudades' and the description never resolves which one an agent should prefer for that question.

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 routing rule for the ambiguous case: if the user asks about a city not covered, say so and offer the Spain-wide hackathons. It also implies when to call it (contact, propose event, newsletter, MCP, suggestions). It stops short of saying when to defer to 'ciudades' for plain city lookups, which is the one remaining ambiguity among the siblings.

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