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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds nothing beyond them: no note on result ordering, pagination, result limits, or whether matching is full-text or exact. For a search tool where result shape drives downstream behaviour, this is thin.

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 short sentence with the verb and scope front-loaded and no filler. Nothing is redundant or 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?

For a one-parameter search tool with full schema coverage and annotations covering the safety profile, the definition is minimally viable. It omits anything about the result set (counts, ordering, empty-result behaviour), which is the main remaining gap given there is no output 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?

There is a single parameter and schema description coverage is 100%, so baseline is 3. The phrase 'por palabras clave' loosely maps to the query field but adds no syntax, matching, or formatting guidance beyond 'Texto de búsqueda' 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?

States a specific verb (busca), the resource (ideas en el Banco de Ideas) and the search mode (por palabras clave), so the agent knows this is a keyword search over the idea corpus. It does not explicitly contrast itself with the sibling leer_ideas/leer_idea read tools, so differentiation must be inferred.

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 exclusion, and no named alternative among the six siblings (leer_ideas, leer_idea, publicar_idea, comentar_idea, publicar_bisociacion, estadisticas). The keyword-search phrasing only weakly implies the use case.

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, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the write/non-idempotent profile is covered structurally. The description adds that the target idea is public (so the comment is publicly visible) and mentions the thread context, but says nothing about permissions, moderation, or edit/delete behavior for a posted comment.

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, front-loaded with purpose, then usage routing, then the size limit. Nothing is padded, though the trailing character-limit sentence duplicates what the schema already enforces.

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 small two-parameter write tool with annotations covering the safety profile and no output schema, the description supplies purpose, the relevant sibling alternative, and the size cap. Missing prerequisites (auth, whether the idea must belong to the caller) are minor given the low complexity.

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 both parameters (id, texto) are documented in the schema, including the 24-hex-char id format and the maxLength/minLength bounds. The description's 'Máximo 1000 caracteres' merely repeats the schema constraint, adding no new parameter meaning, so the 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 ('Comenta una idea pública concreta') and clarifies it operates on an existing idea's thread, which separates it from the create-a-new-idea siblings. It does not explicitly contrast with publicar_idea or publicar_bisociacion, but the 'idea existente' scope makes the distinction inferable.

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 ('responder en el hilo de una idea existente') and names the right alternative for the adjacent read task ('usa leer_idea para ver sus comentarios'). No when-not conditions are given, but the routing to leer_idea is the only alternative an agent realistically needs.

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 read profile is covered. The description adds the scope of what is counted (ideas, bisociations), which is useful, but reveals no auth requirements, freshness, or whether figures are global or per-user — relevant given 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?

A single front-loaded sentence with no filler. The 'etc.' is the one vague element, but overall it is appropriately sized for a no-argument tool.

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 bears the burden of describing the return shape. It names only two example metrics plus 'etc.', so an agent cannot fully anticipate what keys or units come back. Adequate but leaves the response shape underspecified.

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 are zero parameters, so the baseline is 4. The description correctly implies no input is needed, and there is no schema gap to compensate for.

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 (obtiene estadísticas del Banco de Ideas) and names concrete outputs (total de ideas, bisociaciones). This clearly distinguishes it from the sibling tools, which are all CRUD/search operations on ideas. The trailing 'etc.' slightly blurs the full scope.

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 indication of when to call this versus the sibling read tools (leer_ideas, buscar_ideas). The aggregate, read-only nature is implied by the name and annotations but never stated as usage guidance or with 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds one useful behavioral fact — that the response includes the idea's comments ("con sus comentarios") — but omits error behavior for an invalid id and any return shape detail.

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 short sentence with zero filler, front-loading the action and the scoping key. 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?

For a one-parameter read tool with annotations and full schema coverage, the definition is nearly complete; it even notes that comments are included. Without an output schema it could say a bit more about failure modes (unknown id), but nothing essential 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 id parameter is fully documented in the schema (24 hex chars). The description only restates "por su id" without adding format or constraint information, so the 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 ("Lee") and resource ("una idea concreta") scoped by id, which implicitly distinguishes it from the plural sibling leer_ideas. It does not explicitly name or contrast with that sibling, so it stops 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?

Usage is only implied: the singular "una idea concreta por su id" suggests retrieval of a single known item, contrasting with leer_ideas/buscar_ideas. There is no explicit when-to-use statement or named 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds a useful behavioral contract the annotations cannot convey: the response may include next_offset, which must be fed back as offset for the next page.

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 zero filler; the core read is front-loaded, the enum gloss follows, and the pagination tip is last where an agent will look after a first call.

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 carries the burden of return-value behavior, and it does disclose the key pagination field. It stops short of describing the shape of an idea object or an empty-result case, which would complete the picture for a 3-parameter listing 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 the baseline is 3. The description does add value by glossing the category enum ('user' = human ideas, 'bisociation' = bisociations) and showing how offset is driven by next_offset, but limit and offset semantics remain fully schema-defined.

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 in Spanish ('Lee las ideas y bisociaciones del Banco de Ideas'), so the agent knows this is a read over the idea bank. It does not explicitly distinguish itself from the sibling buscar_ideas, so it stops 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?

Gives the filter options ('user', 'bisociation', 'all') and the pagination recipe (pass next_offset as offset), which is real usage context. However, it never says when to prefer this over buscar_ideas or how it relates to leer_idea, so guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write/safe profile is covered. The description adds domain semantics (a creative connection between two apparently unrelated domains) but says nothing about persistence, deduplication of pairings, rate limits, or what a published entry looks like.

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, front-loaded with the action and resource, followed by one illustrative example. The example earns its place by making an abstract term concrete, though the definition could be tightened slightly.

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 does not need to describe return values, and the full parameter set is documented in the schema. It is complete enough to invoke correctly, with only the sibling-routing distinction left 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 100% and all four parameters are documented there, so the schema does the heavy lifting. The description's 'Origami × Arquitectura de software' example mirrors the schema examples for conceptoA/conceptoB rather than adding new meaning (e.g., constraints on domain dissimilarity or insight length).

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 a specific verb ('Publica') and a specific resource ('una nueva bisociación'), and defines what a bisociación is, so an agent knows this creates a novel concept-pairing entry. It does not, however, differentiate itself from the sibling 'publicar_idea', which is the one distinction an agent actually needs.

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 prerequisites, and no mention of the alternatives ('publicar_idea', 'comentar_idea'). The agent must infer from the name alone that this is for cross-domain pairings rather than ordinary ideas.

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, idempotentHint=false and destructiveHint=false, so safety is covered. The description adds nothing beyond that — no mention of authentication requirements, whether duplicate ideas are rejected, or what publishing triggers downstream, which matters for an openWorld write operation.

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

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

A single short sentence with no waste and the action front-loaded. It is efficient, though arguably under-specified rather than deliberately 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?

For a two-parameter write tool with complete schema coverage and annotations carrying the safety profile, an agent has enough to invoke it correctly. What is missing is behavioral context around a mutation in an open-world system: validation rules, duplicate handling, or failure modes.

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?

Both parameters are fully documented in the schema (100% coverage), including that 'tags' is optional, so the baseline is 3. The description adds no extra meaning about the 'texto' content expectations or tag formatting.

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 ('Publica una nueva idea en el Banco de Ideas'), so an agent knows this creates an idea record. It does not explicitly contrast itself with the closely named sibling publicar_bisociacion, but the resource noun is distinct enough to 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as publicar_bisociacion or comentar_idea. The agent must infer usage 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.