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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait: the tool returns a confidence value based on observed relationships or transitive closure logic. This gives insight into how results are computed. However, it does not explicitly state that the tool is read-only (no side effects) or mention any authorization requirements, which would be helpful for safety.

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 efficiently conveys the tool's purpose and output semantics. It is front-loaded with the key concept ('confianza de la relacion') and uses a clear formatting for confidence levels. It earns its place with no wasted words, though it could benefit from a brief usage example or structural separation of purpose and output.

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 simplicity (2 required string params, no nested objects) and the presence of an output schema, the description covers the essential output semantics. However, it lacks context about the system (e.g., sessions, relationship types) and does not explain whether 'a' and 'b' must be previously defined or if the tool works independently. Sibling tools like 'crear_sesion' hint at session dependency, which is unaddressed.

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 0% description coverage, meaning the properties 'a' and 'b' have no type or usage hints in the schema. The description calls them 'terminos' (terms) but does not specify what kind of terms (e.g., entity IDs, strings, session-related variables). This leaves ambiguity about valid values. The description adds minimal semantic value beyond 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 clearly states the tool's function: checking the confidence of a relationship between two terms. It explains the three possible confidence levels (1.0 observed, 0.5 inferred by transitive closure, 0.0 no relationship), which distinguishes it from sibling tools like 'declarar_relacion' (which declares a relationship) and 'procesar_consulta' (a broader query tool). The verb is implicit but the resource is well-defined.

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

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

The description implies the tool is used to obtain relationship confidence for two terms, but it does not explicitly state when to use it versus alternatives like 'estado' or 'stats'. No exclusions or contextual triggers are provided. The usage context (e.g., requirement of an active session) is not mentioned, leaving the agent to infer from the tool's purpose 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the context is bounded by a budget and that observed relations come first, but it does not disclose side effects, authentication requirements, rate limits, or what happens when the term is missing. The output schema exists but is not referenced, so the description alone is insufficient.

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

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

The description is very concise, consisting of two short sentences with no extraneous information. It is front-loaded with the purpose and key details. While it could benefit from a bit more structure, it efficiently communicates the core idea without waste.

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 two parameters, existence of an output schema, and lack of annotations, the description is incomplete. It does not explain the output structure, the meaning of 'activation neighborhood', or how the budget is applied. An agent would need to infer too much, making the description insufficient for robust selection and 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?

The input schema has 0% description coverage, so the description must compensate. It associates 'presupuesto' with a budget limit and 'termino' as the term to query, adding context beyond the schema's bare types. However, it does not specify the format of 'termino' or what the budget limits (e.g., number of relations, tokens), leaving partial clarity.

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 retrieves associative context of a term for injection into a model, mentioning observed relations and activation neighborhood bounded by budget. It distinguishes itself from navigation ('separate mechanism from navigation'), providing a specific verb-resource combination. However, the exact output format and meaning of 'activation neighborhood' remain vague.

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 only hints that this tool is not for navigation, but does not explicitly state when to use it versus siblings like 'consultar', 'declarar_relacion', or 'mover'. No scenarios, prerequisites, or alternatives are provided, leaving the agent without clear usage 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 full burden to disclose behavioral traits. It mentions the return values and suggests a workflow step, but it omits important details such as whether the tool is destructive, requires authentication, or has rate limits. It does not explain what happens if participants are invalid or if the claim already exists.

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 concise, with only two sentences that communicate the core purpose and a key workflow hint. It front-loads the primary action and return value. However, the second sentence could be integrated into the first or expanded with more context about limitations.

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 that there are 5 parameters with 0% schema description coverage, an output schema exists, and no annotations, the description is somewhat incomplete. It covers the basic action and return but fails to explain parameter roles, usage constraints, or error scenarios. It meets the minimum viability but has clear gaps, especially for parameters like 'arbitro' and 'contexto'.

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 provides no explanations for individual parameters like 'claim', 'participantes', 'arbitro', 'contexto', or 'limite_turnos'. The description only hints at the overall purpose but does not clarify parameter meanings or constraints beyond the schema types. Baseline 3 is appropriate as the description adds minimal value.

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 creates a debate session about a claim ('Crea una sesion de debate sobre un claim'), specifies the return value ('Devuelve sesion_id y el estado inicial'), and distinguishes itself from siblings by mentioning the first required action ('El primer movimiento es proponer(actor)'). This differentiates it from other tools like 'mover' or 'declarar_relacion'.

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 it (to start a debate) and offers a minimal hint about the next step ('El primer movimiento es proponer(actor)'), but it does not explicitly state when not to use it or provide alternatives. It lacks guidance on prerequisites (e.g., whether participants must be existing users) or exclusion criteria.

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 must carry the full burden of behavioral transparency. While it states the tool declares a relationship 'sin pasar por texto crudo' (without raw text), it does not disclose side effects (e.g., whether relationships are persisted, overwritten, or if they affect existing data), nor does it mention any authentication or rate limits. A mutation tool describing its behavioral impact is essential here.

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 concise with two sentences that front-load the core purpose and include a practical usage note. Every sentence adds value, and no extraneous information is present.

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 a 0% schema coverage, no annotations, and an output schema present (but not described), the description is incomplete. The user must guess parameter semantics, return format, and side effects. For a tool with 2 required params and no visual hints from sibling names, this is inadequate.

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%, meaning the schema provides no documentation for parameters 'a' and 'b'. The description does not specify what each parameter represents (e.g., term IDs, names, or URIs) or any constraints. Given low coverage, the description should compensate but fails to add meaningful semantics beyond 'dos terminos'.

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 declares a relationship (co-occurrence) between two terms. It specifies that it avoids raw text, distinguishing it from text-processing tools. However, it could further differentiate from 'procesar_consulta' or 'consultar' by noting that this is specifically for explicit co-occurrence relationships.

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 mentions it's useful for scripting and integrations, implying a programmatic use case. However, it provides no guidance on when NOT to use this tool (e.g., if raw text analysis is needed) or how it relates to siblings like 'procesar_consulta'. The phrase 'sin pasar por texto crudo' hints at an alternative approach but doesn't name alternatives.

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?

There are no annotations provided, so the description carries the full burden. It discloses that the tool returns both state and a replayable log, hinting at a read-only nature. However, it does not mention response size limits, potential replayability constraints, or side effects, leaving some behavioral gaps.

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

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

The description is a single, concise sentence that conveys the core function. It is front-loaded with the primary output (current state) followed by the log, minimizing 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?

Given the tool has an output schema, the return format is covered structurally. The tool is relatively simple with one required parameter, but the description lacks context on when to choose this over sibling tools like 'ultimos_eventos' or 'reproducir_sesion', leaving the agent to guess. Overall, it is minimally adequate for the complexity level.

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 elaborate on the 'sesion_id' parameter (e.g., format, examples, or how to obtain it). The schema defines it as a required string with no further detail, and the description adds no semantic value to help the agent provide a correct value.

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 provides the current session state and the complete event log (replayable). The verb 'Estado actual de la sesion mas el log completo' is specific enough to distinguish from siblings like 'ultimos_eventos' (last events) or 'reproducir_sesion' (replay session), though it lacks explicit contrast.

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 given on when to use this tool vs alternatives like 'ultimos_eventos' for a short event list or 'reproducir_sesion' for replay. The description does not mention prerequisites, such as whether the session must be active, nor does it specify when not to use it.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states it applies a movement and returns event/state, but does not reveal whether the action is destructive, reversible, requires permissions, or has side effects. For a mutation-like tool, this is critically insufficient.

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 concise at two sentences, but it is under-specified. It does not earn its brevity because critical information is omitted. The structure is clear, but the lack of substance makes it merely minimal rather than efficiently informative.

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 four parameters with zero schema coverage, no annotations, and an output schema that is not explained in the description, the tool definition is incomplete. The description relies on external module documentation (not provided) to explain payloads and types, leaving the agent without necessary context 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 description coverage is 0%, and the description adds no meaning to the four parameters. It only mentions that payload expects JSON per tipo, but does not explain 'tipo', 'actor', 'sesion_id', or 'payload' semantics. The agent gets no help understanding what values are valid or how they interact.

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 'Aplica un movimiento a la sesion' (Applies a movement to the session), which clearly identifies the action and resource. However, 'movimiento' is vague and does not differentiate this tool from siblings like 'reproducir_sesion' or 'procesar_consulta', which might also apply changes. The mention of returning event and state adds purpose context but lacks specificity about what movements are possible.

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. The description does not mention prerequisites, when not to use it, or reference sibling tools. The pointer to the module docstring for payload details is not a usage guideline; it is external documentation that the agent may not have access to.

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 must carry the full burden of behavioral disclosure. It reveals that the tool performs a multi-step pipeline (tokenization, normalization, filtering, creating/reinforcing context bubbles), which implies modification of internal state. The return of 'processed terms and pool events' gives some insight. However, it does not explicitly state whether the operation is destructive, idempotent, or requires special permissions. The description adds context beyond a simple read/write label but lacks complete safety documentation.

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 extremely concise: two sentences covering purpose, internal steps, and output. Every phrase adds value, and the information is front-loaded with the key action ('Ingesta: procesa una consulta humana completa'). No superfluous 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?

Given the tool's complexity (a processing pipeline with potential side effects), the description covers the main steps and output. However, it omits prerequisites (e.g., whether a session must exist via 'crear_sesion'), error conditions, and the meaning of domain-specific terms ('burbujas del contexto', 'piscina'). The output schema exists but is not visible, so the return description is helpful but incomplete. Overall, it is adequate for a basic understanding but lacks depth for safe autonomous use.

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 single parameter 'texto' has no description in the schema (0% coverage), so the description must compensate. It refers to 'una consulta humana completa', suggesting the text is a full query. However, it does not specify expected format, length limits, encoding, or examples. The meaning is partially inferred but not explicitly detailed, leaving room for ambiguity about what constitutes a 'complete human query'.

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 processes a human query ('procesa una consulta humana completa') and details the steps: tokenization, normalization to canonical concepts, filtering, and creating/reinforcing context bubbles. It also specifies the output: processed terms and pool events. This is a specific verb+resource with sufficient differentiation from sibling tools like 'consultar' (which likely retrieves without processing) and 'contexto_primado' (which may set context directly).

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 explicit guidance is provided on when to use this tool versus alternatives. Siblings like 'consultar', 'contexto_primado', and 'declarar_relacion' exist, but the description does not compare them or explain when this tool is appropriate. The agent must infer from the name and context that it is for initial processing of a full human query, but no exclusion criteria or prerequisites are mentioned.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions reconstructing a session and checking determinism, but it does not specify whether this operation has side effects (e.g., does it modify the actual session state?), what happens if the claim doesn't match, or any authentication requirements.

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

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

The description is just two compact sentences, each with a distinct purpose: first states the main reconstructive action, second adds the determinism check. There is 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 no annotations, 2 required parameters with no schema descriptions, and an output schema not shown, the description covers the high-level purpose but lacks details on parameter formats, return values, and error handling. It is adequate but not comprehensive.

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 0% description coverage, so the description is the only source. It explains that 'log' is a JSON list of events, and that 'claim' is the expected final state to verify. However, it does not clarify the format of the 'claim' parameter (e.g., JSON string, ID), which leaves ambiguity.

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 'Reconstruye' (reconstructs) and the resource 'una sesion' (a session) via replaying an event log, plus the additional goal of verifying determinism. This distinguishes it from siblings like 'crear_sesion' (create) or 'estado' (state) which do different operations.

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 when you need to replay a log and check if the final state matches the original, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it (e.g., if you only need the current state without verification).

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 bears full responsibility for behavioral disclosure. It only lists output dimensions (terms, nodes, edges) but does not state whether the tool is read-only, has side effects, requires permissions, or has performance implications. The agent lacks critical behavioral context.

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

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

The description is extremely concise (one short phrase) but lacks a clear sentence structure. It is not overly verbose, but the minimalism sacrifices completeness and clarity. It could be improved with a verb and more context without losing 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 tool has no parameters and an output schema exists, the description minimally explains the output content (memory dimensions). However, it does not explain the meaning of 'terms, nodes, edges' or how the agent should interpret the results. It is adequate but incomplete for an agent to fully understand the tool's value.

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 baseline is 4 per guidelines. The description does not add parameter semantics because there are none, but it does not detract. No additional information is needed 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 'Dimensiones de la memoria: terminos, nodos, aristas' indicates the tool provides memory dimensions (terms, nodes, edges) but lacks a verb or action verb (e.g., 'get', 'retrieve'). The purpose is inferred but not clearly stated, and there is no differentiation from sibling tools like 'estado' or 'consultar'.

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 guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or context where other tools would be preferred.

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 must carry the full burden. It discloses the core behavior (returning events with seq > desde_seq) and its polling nature. However, it does not explicitly state whether the operation is read-only, idempotent, or if there are any side effects. For a simple retrieval tool, this is acceptable but leaves 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 consists of two concise sentences. Every word serves a purpose, defining the input filter and the intended use case. There is no redundancy or unnecessary detail.

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 an output schema, so the description does not need to detail return values. The description is adequate for a simple polling tool, covering the purpose and key parameter. It could be more complete by mentioning that it returns only new events, but given the output schema existence, it is sufficiently complete for an AI agent.

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 explains the meaning of desde_seq ('seq mayor a desde_seq'), adding value beyond the schema's parameter name and default of 0. However, it does not describe sesion_id, which is required. With 0% schema description coverage, the description should cover more parameters; 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 clearly states the tool returns events with seq greater than desde_seq, positioning it as a polling primitive for live discussions. The verb 'eventos' (events) and the specific filtering condition differentiate it from sibling tools like crear_sesion (create session) and consultar (general query). However, it doesn't explicitly name the resource (e.g., 'session events'), which slightly reduces specificity.

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 labels the tool as a 'polling primitive for live discussion,' implying it should be used when an agent needs to query for new events since a known sequence number. It does not mention when to avoid using it (e.g., if full event history is needed) or suggest sibling tools like consultar as alternatives. The guidance is present but implicit.

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