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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions a backend requirement but does not explain side effects, success/failure outcomes, authorization needs, or what happens to the pairing state. The action 'accept' implies mutation, but no details are provided about its 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?

The description is extremely concise, consisting of a single sentence with two clauses. It front-loads the core action and includes the key differentiator (mobile-initiated) and a prerequisite. There is no wasted text, though it is so brief that it borders on under-specification.

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 is a state-changing action with no annotations and only one parameter, the description is inadequate. It omits error handling, return behavior (despite having an output schema), and any edge cases. An agent could not fully assess the impact of calling this tool.

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

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

Schema coverage is 0% and the description does not elaborate on the meaning of 'device_id' beyond the schema's minimal 'Device Id'. It does not clarify that it identifies the device whose request is being accepted, nor any format or constraints. The description adds no value to the parameter understanding.

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 ('acepta') and the resource ('solicitud de emparejamiento entrante'), and explicitly notes it is initiated by the mobile, which distinguishes it from sibling tools like request_pair and reject_pairing. An agent can immediately understand what action this performs and when it applies.

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 specifies that the request is incoming (initiated by the mobile), which implies it should be used for accepting rather than initiating pairing. It also mentions a prerequisite ('Requiere backend kcd'), giving a concrete condition for use. However, it does not explicitly contrast with reject_pairing 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?

With no annotations provided, the description carries the burden of behavioral disclosure. 'Marca eventos como reconocidos' implies a state mutation (acknowledging events), but it does not mention side effects, reversibility, permissions, or the meaning of 'acknowledged'. The statement 'por ids o por antiguedad' gives selection context but not behavioral 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?

The description is a single concise sentence that front-loads the main action and then specifies selection modes. There is no fluff or redundant wording. It loses a point only because its brevity comes at the cost of important missing details, but as prose 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?

The description is too sparse for a tool with three optional parameters, no required fields, and zero schema descriptions. It fails to explain the 'kind' parameter, usage context, or behavioral effects, so an agent would struggle to invoke it correctly without extra inference or external knowledge.

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 clarifies 'ids' as the event IDs and 'antiguedad' as the age-based selection (likely before_minutes), which adds meaning beyond the bare titles. However, the 'kind' parameter is entirely unexplained, leaving one of three parameters semantically orphaned.

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 ('Marca') and resource ('eventos'), and adds selection modes ('por ids o por antiguedad'). It clearly communicates marking events as acknowledged, which is distinct from the read-oriented siblings like get_events or wait_for_events. However, it does not explicitly name or differentiate from siblings, so it misses the top tier.

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 on when to use this tool versus alternatives, nor any mention of conditions or exclusions. It only says what the tool does, not when an agent should choose it over get_events, wait_for_events, or other event-related siblings.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses some filter behavior (kind, app, since_minutes, unread_only) but does not state whether the tool is read-only, what data source it reads from, how pagination works, or what 'ya redactada' means operationally.

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

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

The description is compact and uses a clear label-plus-parameter list structure. It wastes little space, though the opening phrase is slightly ambiguous and could be clearer.

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

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

For a 7-parameter tool with no annotations and no schema-level descriptions, this is incomplete. The output schema covers return shape, but missing device_id and pagination semantics, plus a lack of usage context among many siblings, leaves an agent under-informed.

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 partially compensates by explaining kind values, app partial matching, since_minutes semantics, and unread_only. However, it omits limit, offset, and device_id, leaving 3 of 7 parameters without meaningful explanation.

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

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

The description names a resource ('Timeline unificado de actividad ya redactada') and lists filters, so it is more than a tautology. However, it lacks an explicit verb like 'returns' or 'lists', and the phrase 'actividad ya redactada' is ambiguous, making the exact purpose unclear.

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 no guidance on when to use get_activity versus siblings such as search_activity, get_call_log, or get_events. It provides filter semantics but no context, exclusions, or alternative routing.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'call history' and a parameter hint, but does not mention read-only nature, pagination, ordering, response format, rate limits, or any side effects. This is a significant gap for a tool with no structured behavioral metadata.

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 terse: two short sentences with no wasted words. It is front-loaded with the core concept. It sacrifices detail for brevity, but given the tool's simplicity, it is appropriately sized, though borderline on under-specification.

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 there is an output schema (though not shown), return values may be covered, but the description lacks context for the tool's usage scope, parameter meanings, and behavioral traits. For a 3-parameter tool with no annotations, this is incomplete. An agent would still be unsure how to set days or limit effectively.

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 explain parameters. It only explains 'only_missed' (for missed calls) but leaves 'days' and 'limit' without any meaning or usage examples. It partially compensates but is insufficient for two of the three parameters.

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

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

The description clearly identifies the resource: 'Historial de llamadas' (call history). It implies a retrieval action, but does not explicitly state a verb like 'get' or 'list'. It does not differentiate from siblings, but the sibling list shows no overlapping resource, so the purpose is sufficiently clear for an agent to infer the tool's function.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or why one might choose this over list_devices, get_events, or other siblings. The only hint is about parameter usage, not selection context.

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 reveals that filtering supports partial phone matching, which is useful, but it does not state whether this is a read-only operation, how results are ordered, whether messages are paginated, or what happens when both address and contact are supplied.

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 in Spanish with no filler and the core resource is front-loaded. It is efficient, though its brevity contributes to the missing parameter and usage 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 is simple: three optional parameters, an output schema, and no required inputs. The description covers the basic purpose and two filter parameters, but lacks guidance on limit behavior and parameter precedence. It is minimally adequate but leaves clear gaps for an agent deciding how to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It maps 'address' to phone and 'contact' to contact name, including the partial-match behavior, which adds real meaning beyond the schema. However, it does not explain the 'limit' parameter, its default, or how the two filter parameters interact when both are provided.

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

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

The description clearly identifies the resource as 'Hilo de SMS' (SMS thread) and states the filtering criteria: partial phone number or contact name. It is specific enough to distinguish from sibling tools like get_call_log or get_events, though it never explicitly names an alternative.

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 on when to use this tool instead of related siblings such as search_activity, sync_sms_history, or get_call_log. The description implies its use when an SMS thread is needed, but it provides no exclusions or comparison with 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?

With no annotations provided, the description carries the full burden and does it well: it discloses ordering, cursor semantics, the returned next_after_id, and the edge case that notification withdrawals update the row and are not re-emitted. This goes well beyond a generic 'get events' and gives agents concrete behavioral expectations.

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

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

The description is three short, densely informative sentences with no filler. The core incremental-cursor behavior is front-loaded, followed by the continuation pattern and a specific behavioral edge case. Every sentence earns its place.

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

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

The output schema covers return values, so that is not a gap. However, for a tool with no annotations and incomplete parameter coverage, the description should explain kind and limit to be fully actionable. The core stream behavior is well covered, but the parameter ambiguity leaves the definition only partially 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?

Schema description coverage is 0%, so the description must compensate. It explains after_id ('eventos con id > after_id') and relates it to next_after_id, but it does not explain the meaning or accepted values for kind, nor the semantics of limit. Two of three parameters remain effectively undocumented.

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

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

The description clearly identifies the tool as incremental cursor-based event consumption ('eventos con id > after_id, en orden de llegada'). It differentiates itself from siblings by emphasizing the stream/log pattern and the next_after_id cursor, though it does not explicitly name alternatives.

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

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

It provides clear usage context: consume events incrementally with after_id and continue using next_after_id for the next call. The 'patron de stream/log' makes the intended polling pattern evident, but it does not explicitly state when not to use this tool versus siblings like wait_for_events.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does communicate that the tool returns aggregate counts rather than raw redaction events, which is useful, but it omits details such as scope, time window, or whether the stats are global or device-specific.

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

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

The description is a single concise sentence that front-loads the core behavior and category list with no filler. Every word contributes to the agent's understanding.

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 is simple, parameterless, and has an output schema, which reduces the need for the description to explain return structure. The description adequately covers what the tool does, though it could add a bit more context about scope or timing.

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 no parameter semantics burden on the description. The baseline of 4 applies, and the description does not need to compensate for undocumented inputs.

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 that the tool returns a count of redactions grouped by category and even enumerates the categories (otp, card, iban, phone). It is specific about the verb/resource relationship, but it does not explicitly distinguish itself from sibling tools like get_activity or get_events.

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 on when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The context of when redaction stats would be needed versus other stats/activity tools is entirely left to the agent to infer.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what information is returned (listener, capture/PII config, counts) but does not explicitly confirm it is a read-only operation or mention any side effects, permissions, or rate limits. For a status tool, this is likely safe, but the description does not make that explicit.

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

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

The description is a single, efficient sentence that front-loads the core purpose and lists the key components. There is no wasted wording, and it is appropriately sized for a tool with no parameters.

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 return values are defined elsewhere. The description covers the key aspects of what the status includes (listener, capture/PII config, counts), which is sufficient for a simple zero-parameter tool. Nothing critical is missing for an agent to call it correctly.

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

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

The tool has zero parameters, so there is nothing to explain. The schema description coverage is 100% (no parameters), and the description does not need to add parameter details. The baseline for 0 parameters is 4, which is appropriate here.

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 server status, listing specific components (listener, capture/PII configuration, counts). This distinguishes it from sibling tools like list_devices or get_activity, which target different domains (devices, activities). The verb is implied but the resource and scope are specific and unambiguous.

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

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

The description implies this tool is for checking server status, but it does not explicitly state when to use it versus alternatives or provide any conditions or exclusions. An agent can infer the usage from the purpose, but no explicit guidance is given.

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

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

No hay anotaciones, así que la descripción debe cubrir el comportamiento. Solo dice que las notificaciones son activas y 'redactadas', sin aclarar si la operación es de solo lectura, qué datos se incluyen o cómo afecta al backend. El término 'redactadas' es ambiguo (en español suele significar 'escritas/redactadas', no necesariamente 'redacted'), por lo que el agente no puede confiar en él.

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

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

La descripción es breve y no tiene relleno innecesario, pero la cláusula entre paréntesis no está estructurada ni es claramente útil; 'backend configurado' no aporta información accionable. Es concisa en longitud, pero sacrifica claridad en el mensaje central.

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?

Existe un output schema, por lo que el formato de retorno está cubierto, pero faltan elementos esenciales: cuándo usar la herramienta, qué hace device_id y si las notificaciones están redactadas o filtradas. Para una herramienta con un parámetro opcional y hermanos similares, la descripción es insuficiente.

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

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

El esquema solo define device_id opcional sin descripción, y la descripción de la herramienta no menciona este parámetro ni explica el comportamiento del valor null. El nombre 'Device Id' da una pista, pero no compensa la cobertura del 0%. El agente no sabe si debe pasar el id para filtrar o si null significa 'todos los dispositivos'.

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 identifica el recurso ('notificaciones activas') y el marco temporal ('ahora mismo'), lo que permite distinguirla de herramientas de eventos, llamadas o conversaciones. Sin embargo, no incluye un verbo explícito y el paréntesis '(backend configurado, redactadas)' añade ambigüedad. Aun así, el propósito central es reconocible.

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 se indica cuándo usar esta herramienta frente a get_events, get_activity o wait_for_events. Tampoco hay exclusiones ni alternativas; el único indicio es 'ahora mismo', que sugiere una consulta de estado actual. Un agente no puede decidir entre los siblings basándose en esta descripción.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add meaningful context: devices are 'seen by the listener' and come 'from the database', implying a read-only, persisted view rather than a live scan. However, it doesn't disclose ordering, freshness, or any response behavior beyond what the output schema already provides.

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 filler. It front-loads the core resource ('mobile devices') and immediately clarifies the data source and passive nature, making it easy to parse.

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-parameter, read-only listing tool with an output schema, this description is nearly complete. It gives the essential selection cue ('from the database') that separates it from active scanning siblings. Explicitly naming the alternative scan_devices would make it 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 tool has zero parameters and an empty input schema, so there are no parameter semantics for the description to add. The baseline of 4 applies because there is nothing missing at invocation time.

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

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

The description clearly identifies the resource ('mobile devices') and the data source ('from the database'), and the verb 'list' is effectively carried by the tool name. However, it is a noun phrase rather than an explicit action statement, and it doesn't explicitly differentiate itself from the sibling scan_devices.

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

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

Usage is implied: this tool lists devices already seen by the listener from the database, likely as opposed to actively scanning. But there is no explicit when-to-use guidance, no mention of alternatives, and no stated distinction from scan_devices, leaving some selection reasoning to the agent.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions a backend requirement but does not describe side effects, whether the pairing is removed, or any permissions needed. This is a state-changing operation with no behavior 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?

The description is a single sentence, which is concise and front-loaded with purpose. However, it is under-specified, lacking any structured sections or additional context.

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 one required parameter and no schema description, the description is inadequate. It does not explain the output, the meaning of device_id, or how it relates to sibling tools like list_devices. The 'Requiere backend kcd' note adds little operational context.

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 mention the device_id parameter at all. The agent has no clue what device_id refers to or how to obtain 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 clearly states the action: rejecting an incoming pairing request, which is a specific verb+resource. It distinguishes from siblings like accept_pairing by the 'reject' verb, though it does not explicitly name the alternative.

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

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

No guidance is provided on when to use this tool versus accept_pairing or request_pair. The only additional note, 'Requiere backend kcd', is a technical prerequisite rather than a usage condition.

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

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

With no annotations, the description carries the full burden. It does disclose that this is a pairing request and that user confirmation on the paired mobile is required, which is meaningful behavioral context. However, it omits details such as whether the device must be discoverable, whether the request expires, or any permission 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 a single, upfront sentence with no filler. It communicates the core action and the key confirmation step efficiently. Every word earns its place.

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

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

The tool is simple (one required parameter) and an output schema exists, so the description need not explain return values. However, for an unannotated mutation-like tool, there is not enough guidance on how to obtain a valid device_id or what happens after the request is made. It is minimally viable but has clear gaps.

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

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

Schema description coverage is 0%, and the description does not explain what device_id should be, where to obtain it, or whether it must come from scan_devices or list_devices. The word 'dispositivo' only weakly maps to the parameter. The schema provides the parameter name, but the description adds little semantic 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 action ('Pide emparejar un dispositivo') and the resource (a device). It also adds the distinctive detail that confirmation must happen on the mobile device. However, it does not explicitly differentiate itself from siblings like accept_pairing or reject_pairing, so it falls 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?

The description implies the tool is used to initiate pairing, but it gives no explicit guidance on when to use this tool versus accept_pairing, reject_pairing, or scan_devices. There is no when-to-use or when-not-to-use information, leaving the agent to infer context.

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

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

No annotations are provided, so the description carries the full burden. It says the tool scans devices but does not disclose whether the operation is read-only, whether it triggers pairing, or any side effects or permissions needed. The phrase 'include_unpaired para emparejar nuevos' hints at purpose but does not clarify behavioral impact.

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 and front-loaded, stating the main purpose first. It includes only two sentences and no filler. However, it is perhaps too terse to convey sufficient 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 description is minimal for a tool with one optional parameter and a rich sibling set. It doesn't differentiate from list_devices or explain prerequisites or behavior. The output schema exists, so return value details are covered, but usage context is lacking. Given the tool's simplicity, it's adequate but has clear gaps.

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

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

The schema has 0% description coverage, so the description must explain the parameter. It states that include_unpaired is for pairing new devices, which adds meaning beyond the schema's title. However, the explanation is terse and doesn't clearly state that unpaired devices are included in the scan results or what false means.

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 scans KDE Connect devices, using a specific verb and resource. It also mentions the include_unpaired parameter's purpose, which adds context. However, it does not explicitly differentiate this from the sibling list_devices, so it is clear but lacks sibling differentiation.

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 on when to use scan_devices versus list_devices or any other siblings. The description only implies that include_unpaired is for pairing new devices, but doesn't state when to choose this tool over 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, so the description carries the full burden of behavioral disclosure. It indicates a read-like search over selected fields but does not explain matching behavior, result ordering, pagination, or what 'ya redactado' means operationally. This leaves important behavioral ambiguity.

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

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

The description is a single concise sentence that front-loads the core action and scope. It wastes no words, though the phrase 'sobre lo ya redactado' is ambiguous and slightly undermines the clarity.

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 the output schema exists, return values do not need to be explained, but the description still fails to clarify parameter usage and scope. For a search tool with three parameters and zero schema descriptions, this is not enough for an agent to select and invoke it correctly without guessing.

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 the `kind` or `limit` parameters at all. It adds context about searchable fields, but an agent still cannot determine how `kind` constrains the search or how `limit` affects results.

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

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

The description states a specific action ('Busca texto') and names the searched fields: title, body, app, and contact. However, the resource being searched ('lo ya redactado') is vague, and the description does not explicitly differentiate it from siblings like get_activity or get_events.

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 about when to use this tool instead of alternatives such as get_activity, get_events, or get_conversation. The description implies a text-search use case but never states when it is appropriate or not.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that the data comes from the mobile cache and is redacted before ingestion, but it does not state whether ingestion mutates local storage, whether an active pairing is required, or what effects repeated calls have.

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 one short sentence with no filler, and the core action is up front. It loses a point only for the slightly awkward grammar and for not using the available space to clarify the parameter.

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?

Although the tool is simple and has an output schema, the description omits usage guidance, side effects, and the meaning of wait_seconds. An agent can identify the operation but not confidently pick or invoke it among the 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?

Schema description coverage is 0% and the description never mentions wait_seconds. The only parameter's meaning must be inferred from its name and default, and the description adds no clarification about what waiting applies to.

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 concrete action: it asks the phone for cached conversations and ingests them redacted. This clearly maps to the tool name and distinguishes it from generic getters, though it does not explicitly contrast it with sibling tools like get_conversation.

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 on when to call this tool versus siblings such as get_conversation or list_active_notifications, and no mention of pairing or prerequisites. The intended use is only weakly implied by the tool name.

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

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

With no annotations, the description must carry the safety and behavior burden. It discloses the long-polling blocking behavior and the timeout_seconds parameter, which is helpful. However, it does not explicitly state that this is a read-only operation, what happens on timeout, or any rate-limit or side-effect profile, leaving some inference required.

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 remarkably concise: two lines, front-loaded with the core behavior, then the usage tip. Every word adds value, with no repetition of schema details.

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

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

For a polling tool, the description covers the essential loop and timeout, and the output schema defines return shape. But it misses the kind filter and does not explicitly describe timeout behavior or empty-result handling, which an agent would need for robust usage given no annotations.

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 after_id ('id > after_id') and timeout_seconds ('hasta timeout_seconds'), adding meaning beyond the schema. However, the 'kind' parameter is entirely omitted, and schema description coverage is 0%, so the description does not fully compensate for the undocumented parameter.

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

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

The description states a specific behavior: a long-poll that waits for events with id > after_id, up to timeout_seconds. This clearly identifies the resource and condition, distinguishing it from siblings like get_events by its blocking, incremental nature, though it does not explicitly name an alternative.

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 recommendation 'guarda next_after_id y vuelvelo a pasar' gives an explicit usage pattern for live consumption. It provides clear context on how to use the tool repeatedly, but it does not mention when not to use it or point to alternatives such as get_events.

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