askacharge.com — EV charging network

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

Beyond the annotations (destructiveHint=true, openWorldHint=true), the description adds crucial behavioral context: 'CUIDADO: entrega energía real y genera un cobro', explaining exactly what the destructive effect is. It also mentions the OCPP RemoteStartTransaction protocol. No contradiction with annotations.

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

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

The description is two concise sentences, front-loading the action and protocol, then stating prerequisites and a prominent warning. Every sentence adds value with no redundancy.

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

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

For a 3-parameter tool with fully described schema and rich annotations, the description is complete: it covers the action, preconditions, and consequences. No output schema exists, so return values need not be documented. Minor gap: it does not mention what a successful response looks like, but that is not essential here.

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% – all three parameters have detailed descriptions, including the optional id_tag and its default. The tool description itself does not add extra parameter-level meaning beyond what the schema already provides, 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?

The description clearly states the verb and resource: 'Arranca una carga en remoto (OCPP RemoteStartTransaction)'. It specifies the action, the protocol, and is easily distinguished from the sibling tool 'askacharge_parar_carga' by the opposite verb.

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 provides clear usage prerequisites: 'El cargador debe estar conectado y el id_tag autorizado en la marca' and a strong caution about real energy delivery and billing. It implies when not to use (e.g., if charger is disconnected), though it does not explicitly name the alternative stopping tool.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutating nature is known. The description adds useful context: it changes availability via OCPP and does not physically disconnect the charger. However, it does not disclose possible side effects on active charging sessions or any authorization 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 two short sentences with no filler. The core action is front-loaded, the protocol is named parenthetically, and the usage guidance is packed into the second sentence.

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

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

For a low-complexity tool with two fully described required parameters and annotations covering the destructive/mutating behavior, the description is largely sufficient. The main gap is the lack of information about the expected response or outcome of the OCPP call, but this is minor.

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 both parameters are already well documented. The description reinforces the availability statuses but does not add meaningful parameter syntax or format details beyond what the schema provides.

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

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

The description opens with a concrete action, 'Pone un cargador operativo o fuera de servicio', and names the OCPP ChangeAvailability operation. This makes the tool's purpose unmistakable and clearly distinguishes it from siblings like reiniciar_cargador or arrancar_carga, which target different behaviors.

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 second sentence gives an explicit use case: 'Úsalo para retirar de servicio un punto averiado sin desconectarlo.' This tells the agent when to invoke the tool, though it does not mention alternatives or situations where the tool should not be used.

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 annotations only declaring non-readonly, non-idempotent, non-destructive (all consistent with a creation operation), the description carries valuable extra behavior: OCPP connection under a minute, periodic self-charging, full command response including a realistic 20-second disconnection on Reset, bundled RFID cards, a 409 response at the cap, and a teardown endpoint. This substantially enriches the agent's mental model of what the sandbox chargers will do. No contradiction with annotations.

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

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

The description is longer than average (roughly 90 words) but every clause is information-dense and earns its place: purpose, connection behavior, command/reset semantics, RFID naming, quota with error code, teardown route, and intended use. It is front-loaded with the primary purpose and the behavioral details follow logically. It could be trimmed slightly, but there is no filler.

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

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

For a tool with behavioral side effects (self-charging, reset behavior) and no output schema, the description is notably complete: it explains creation behavior, the quota failure case (409), how to remove the chargers, and when to use it. Minor gaps remain (no explicit mention of the success response shape or of the location_name influencing anything), but an agent can correctly invoke and interpret this tool with the information given.

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%: both parameters (count 1–10 default 5, location_name with a Spanish default) are already fully documented in the input schema. The description adds only the 'Máximo 10 por marca' constraint, which slightly reinforces the count upper bound but introduces no fundamentally new parameter semantics. Baseline 3 is appropriate because the schema already does the heavy lifting.

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

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

The description opens with a specific verb-resource pair ('Da de alta cargadores simulados en la marca') and immediately frames the purpose as testing without hardware. It is cleanly distinguishable from the sibling askacharge_crear_cargador (real chargers), because the 'simulados' qualifier and 'sin hardware' context make the sandbox scope explicit. The resource, brand scope, and what the chargers do are all stated.

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 ends with an explicit directive: 'Úsalo para ensayar comandos y webhooks antes de tocar un cargador real', which tells the agent exactly when this tool is the right choice. It also mentions the removal path via DELETE /api/brand/sandbox and the 10-per-brand cap, giving operational context. It does not explicitly name a sibling to avoid (e.g., crear_cargador for real hardware), but the sandbox framing makes the intended use unambiguous.

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 provide only readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description must carry the behavioral burden. It adds valuable non-obvious behavior: charge_point_id must be unique only within the brand, and after creation the charger must point its OCPP connection to the specified wss URL. This goes beyond what the schema or annotations state, though it does not address duplicate-creation behavior or return details.

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

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

The description is two sentences with no fluff. The action is front-loaded, and the second sentence provides the most operationally important detail: the required OCPP endpoint format. 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?

For a simple create tool with a single required parameter, complete schema coverage, and useful post-creation instructions, the description is mostly sufficient. It lacks explicit information about what the tool returns or what happens on duplicate charge_point_id, but the provided OCPP endpoint guidance is highly valuable and not obvious. Given no output schema exists, a little more detail about the success result would improve completeness.

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 schema already documents all five parameters. The description mostly repeats the charge_point_id meaning already present in the schema ('único dentro de la marca'), adding little new semantic value. The OCPP URL is a useful related detail but does not clarify the other 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 uses a specific verb and resource: 'Da de alta un cargador' clearly means registering a new charger. It also adds the defining context that charge_point_id is the factory identifier, unique within the brand, which makes the tool's scope unmistakable. This distinguishes it from sibling tools like listar_cargadores or ver_cargador.

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 is the tool for creating/registering a charger and even gives the required post-creation OCPP endpoint, which is useful. However, it does not explicitly state when to prefer this tool over siblings, nor does it mention when not to use it, such as for existing chargers or different resources like clients or tariffs. The usage context is clear enough from the name but not explicitly contrasted 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?

Annotations already show readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds valuable behavioral context: it does NOT check duplicates, so repeated calls create multiple clients; it inherits default tariff if tariff_group_id is omitted. This goes beyond the annotations and prevents serious misuse. No contradiction between description and annotations; in fact it reinforces non-idempotency.

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 sentences, each with a distinct purpose: core behavior, duplicate warning, and follow-up routing. Information is front-loaded (creation + return id first), warnings and alternatives follow logically. No fluff or redundancy.

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

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

For a creation tool with no output schema, the description explains the return value (created client with id), covers the key side effect (duplicates possible), and provides sibling routing. It also covers the tariff inheritance corner case. Given the tool's complexity (6 params, 1 required) and 100% schema coverage, this is 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 100%, so the schema already documents all six parameters. The description adds semantic value for tariff_group_id by explaining the inheritance behavior, but other parameters (name, email, phone, company, client_type) are already well-described in the schema. Baseline 3 is appropriate because the description complements but does not heavily expand on schema documentation.

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

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

The description states a specific verb and resource: 'Da de alta un cliente' (creates a customer) and explicitly mentions returning the created client with its id. It distinguishes from sibling askacharge_crear_tag_rfid (for authorizing cards) and askacharge_crear_cargador/crear_tarifa by focusing solely on client creation. The title reinforces this, and the non-duplicate warning adds a clear behavioral signature.

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 explicit when-to-use guidance: use it to create a client, but first check askacharge_listar_clientes to avoid duplicates, and follow up with askacharge_crear_tag_rfid if card authorization is needed. It also explains when to pass tariff_group_id (to inherit default tariff if omitted). This directly tells an agent when to use this tool vs 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?

Annotations already indicate this is a write operation (readOnlyHint=false) and not idempotent. The description adds the useful constraint that id_tag is unique within the brand, hinting that duplicate authorization may fail. However, it does not disclose effects of repeated calls, whether authorization can be removed, or any error behavior beyond uniqueness.

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

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

The description is two sentences with no fluff. It front-loads the main action, then explains the practical need and a key constraint. 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?

For a tool with a simple, well-documented schema, the description covers the operation's purpose and prerequisite clearly. It does not describe the output or duplicate-handling behavior, but given the lack of an output schema and the simplicity of the action, the definition is largely 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 100%, and the schema already documents id_tag, client_id, and user_name with meaningful descriptions. The description reinforces id_tag uniqueness but adds no extra meaning for client_id or user_name beyond what the schema provides.

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 ('Autoriza un tag RFID en la marca') and clearly explains the consequence of not doing it ('Sin esto, la tarjeta no puede arrancar cargas'). This distinguishes the tool from siblings like askacharge_arrancar_carga and askacharge_crear_cliente by framing it as the prerequisite authorization step.

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 provides clear context for when the tool is needed: before a card can start charging, it must have an authorized RFID tag. It does not explicitly name alternatives or exclusions, but the prerequisite framing makes the usage scenario evident.

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

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

The description adds important behavioral context beyond annotations by warning that setting is_default to true displaces the previous default tariff. It also states that the tool returns the created group with its id. While it does not cover authentication, rate limits, or rollback, no annotation contradiction exists and the key side effect is disclosed.

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 dense but efficiently organized: main action and return value first, mode-to-price mapping second, and the cautionary side effect last. Every sentence earns its place, and there is no redundant or filler content.

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 7 parameters and no output schema, the description is complete enough for correct invocation. It covers the purpose, return contract, per-mode parameter selection, the default-tariff side effect, and directs the agent to the relevant listing tool. No critical usage detail appears to be 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?

Although schema coverage is 100%, the description adds decisive value by mapping each billing_mode to its relevant price field and by explaining combined, pvpc_margin, and free behavior. The instruction to fill only the price of the chosen mode prevents invalid combinations. This goes well beyond the schema's enum descriptions.

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

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

The description opens with 'Crea un grupo de tarifa y devuelve el grupo creado con su id', stating a clear verb, resource, and return value. It distinguishes the tool from siblings such as askacharge_listar_tarifas and the other crear_* tools by specifying exactly what entity is created.

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

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

It gives concrete usage guidance: 'Rellena solo el precio del modo elegido' and enumerates which price parameter belongs to each billing_mode. It also points to askacharge_listar_tarifas for viewing existing tariffs. It lacks an explicit 'when not to use' statement, but the intended use is unambiguous.

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

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

The description goes beyond the annotations by revealing important runtime behavior: an ongoing session will be stopped first, and the possible returned statuses are listed. This gives the agent a clear model of what happens when the tool is invoked.

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 dense sentences with no filler. The primary action is front-loaded, usage context follows immediately, and the alternative route is placed at the end where it belongs.

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 tool with no output schema, the description covers invocation context, side effects, return values, and the relevant alternative. Nothing essential is missing for correct 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 already covers both parameters completely with descriptions, including the default for connector_id. The tool description adds no extra parameter-level detail, but with 100% schema coverage the baseline of 3 is appropriate.

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

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

The description clearly identifies the action ('Libera el bloqueo del cable en un conector') and the OCPP operation (UnlockConnector). It also distinguishes itself from the sibling askacharge_reiniciar_cargador by specifying when that tool should be used instead.

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

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

It explicitly states when to use the tool: when a driver cannot remove the cable after finishing. It also provides the alternative for a connector stuck in Faulted state, making the decision boundaries clear.

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

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

Annotations already indicate idempotence, non-read-only behavior, and non-destructiveness. The description adds real context by explaining that the tool sends an OCPP GetDiagnostics request and causes the charger to upload a diagnostic file. It does not mention asynchronous behavior or acknowledgments, but it does not contradict the annotations.

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

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

The description is two short sentences: the first states the action and protocol, the second provides the practical trigger scenario. It is concise, front-loaded, and 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?

For a one-parameter, well-annotated command tool, the description provides sufficient operational context: what the tool does, the protocol involved, and when it should be used. It lacks only explicit detail about the response or asynchronous nature, which is a minor 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?

Schema coverage is 100% and the single charge_point_id parameter already has a clear description in the input schema with an example value. The tool description adds no extra parameter-level meaning, so the baseline score of 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?

The description states the specific action: 'Pide al cargador que suba su fichero de diagnóstico' and names the underlying protocol (OCPP GetDiagnostics). This clearly distinguishes the tool from siblings like reiniciar_cargador or estado_en_vivo by its diagnostic purpose.

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

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

The description gives clear context for when to use the tool: 'Es el primer paso razonable ante un cargador que falla y no dice por qué.' It does not explicitly name alternative sibling tools or when not to use them, so it stops short of full 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?

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses the full state machine (acked, confirmed, timeout, rejected, failed), the timeout window (5-10 minutes), and the meaning of expected_event. This is critical behavioral context that an agent needs to interpret results correctly and is not present in the annotations alone.

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 dense but every sentence contributes: it front-loads the purpose, then explains the states and usage guidance. There is no redundant or filler text; it is appropriately sized for the complexity of the 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?

Given the absence of an output schema, the description thoroughly explains what the tool returns (states, events, and the two-phase nature). It also covers the optional behavior without job_id and the rationale for using it instead of re-sending commands, making it complete for an agent to call and interpret the result 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 description adds significant meaning to job_id by explaining it is returned by every command tool and that omitting it lists recent commands. It also clarifies the concept of expected_event. While charge_point_id is not explicitly mentioned in the description, the schema already covers it, and the description goes beyond the schema's simple parameter documentation.

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

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

The description clearly states the tool's purpose: checking the status of an OCPP command by job_id, and explains the two-phase nature of command execution. It differentiates itself from sibling command-issuing tools (e.g., arrancar_carga, reiniciar_cargador) by focusing on status retrieval rather than sending a command. The title 'Ver cómo va un comando lanzado' reinforces the specific verb and resource.

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

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

The description provides explicit usage guidance: 'Úsala en vez de repetir el comando' (use it instead of repeating the command) and warns that repeating would start two charges or restart twice. It also explains when to omit job_id (to list recent commands), giving clear conditions for invocation versus 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?

Las anotaciones ya declaran readOnlyHint e idempotentHint, por lo que la descripción solo añade el carácter de instantánea en tiempo real y el contenido observado. No contradice las anotaciones ni detalla efectos adicionales, lo cual es suficiente a este nivel.

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

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

Dos oraciones breves: la primera define el contenido de forma directa y la segunda añade una guía de uso sin redundancia. Todo el texto aporta valor.

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

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

Para una herramienta sin parámetros ni esquema de salida, la descripción explica qué datos devuelve y cuándo resulta preferible. Un agente puede invocarla correctamente sin ambigüedad.

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?

No hay parámetros; el esquema está vacío y la cobertura es 100%. La descripción no necesita documentar parámetros, y el baseline para 0 params es 4.

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 claramente el recurso y el alcance ('cargadores conectados, sesiones activas y potencia... ahora mismo') y lo diferencia de lo histórico, pero no incluye un verbo explícito como 'obtener' o '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?

'Para diagnosticar, mejor esto que el histórico' ofrece una condición de uso clara y una preferencia frente a herramientas históricas, aunque no nombra alternativas concretas ni dice cuándo no usarlo.

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

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

The annotations already declare readOnlyHint=true and idempotentHint=true, so the non-mutating nature is covered. The description adds context about what the result covers (location and distribution strategy), but does not disclose other behavioral traits such as data freshness, authorization needs, or return format. This is acceptable given the strong annotation coverage.

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

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

The description is two short sentences with no filler. It front-loads the core meaning ('Límite de kW por ubicación y estrategia de reparto') and then provides the key usage context. 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?

For a read-only, zero-parameter tool, the description is complete: it states what the tool returns, in what granularity it returns it, and when an agent should call it. There is no output schema, but the described result is simple enough that the phrase 'Límite de kW por ubicación y estrategia de reparto' gives adequate expectation of the response.

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 is empty, so there are no parameters to document. Per the calibration baseline for a zero-parameter tool, the description is not required to explain parameter semantics, and it correctly focuses on the meaning of the result rather than invocation details.

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 the exact object of the tool: 'Límite de kW por ubicación y estrategia de reparto' (kW limit by location and distribution strategy), and uses the imperative 'Consúltalo' to make the query action explicit. It is clearly distinct from the listed siblings, which mostly concern creating, starting, stopping, or listing other entities.

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 an explicit when-to-use instruction: consult this before starting loads at sites with tight contracted power ('antes de arrancar cargas en sitio con potencia contratada justa'). This maps directly to the sibling 'askacharge_arrancar_carga'. It does not explicitly state when not to use it or name an alternative tool, so it falls just short of a full 5.

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

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

Annotations already establish read-only and idempotent behavior, so the description only needs to add beyond that. It meaningfully adds that the tool returns OCPP state, location, and last heartbeat, and implies the list can reveal which chargers are down. This is useful context, though it could have been richer about staleness or scope.

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

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

The description is two short sentences and every word earns its place. The main action and output fields are front-loaded, followed by a practical usage recommendation. There is no filler or repetition of the title.

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 parameterless, read-only listing tool with no output schema, the description is complete: it names the resource, the fields returned, and the intended first-step use case. Nothing an agent needs to call or interpret the tool 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?

The tool has zero parameters and the schema is empty, so there are no parameter descriptions to clarify. Baseline for zero-parameter tools is 4, and the description's mention of 'de la marca' helps define the implicit scope of what is listed.

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

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

The description uses a specific verb ('Lista') and resource ('cargadores de la marca'), and specifies the exact information returned: OCPP status, location, and last heartbeat. It also frames itself as the initial triage step, making its role distinct from more specialized sibling tools like ver_cargador or estado_en_vivo.

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

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

The phrase 'Empieza por aquí para saber qué hay y qué está caído' clearly tells the agent when to use this tool: as the first step to discover chargers and identify outages. However, it does not explicitly mention alternatives or say when not to use it, so it falls short of a 5.

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

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

The read-only and idempotent hints already cover safety, and the description adds useful behavior beyond annotations: no filter/pagination, all results returned at once, and deactivated clients excluded. It stops short of detailing the exact response shape, but for a parameterless list this is a strong disclosure.

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 sentences put the core purpose first, then behavioral constraints, then sibling routing. Every sentence earns its place and there is no filler or restatement of the tool name.

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

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

For a simple, parameterless, read-only listing tool, the description covers what it returns, what it excludes, that it has no filtering/pagination, and which sibling tools handle adjacent cases. With no output schema, it compensates by naming the returned data fields sufficiently.

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 is empty and schema coverage is 100%, so there are no parameter semantics for the description to explain. With zero parameters the baseline is 4, and the description does not attempt to invent parameter detail.

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 the exact operation ('Lista los clientes activos') and the data returned (assigned rate and monthly consumption), and it explicitly routes to askacharge_crear_cliente and askacharge_listar_sesiones for adjacent cases, so it is easily told apart from the sibling tools.

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 states the tool returns all active clients at once with no filters or pagination, and gives explicit alternatives for related actions: creating a new client and listing its charging sessions. This tells an agent when this tool is the right choice and what to use instead for neighboring tasks.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful scope (only open incidents, scoped by charger, reported faults) but does not describe output, pagination, or empty-result behavior; it does not contradict the annotations.

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

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

The description is one compact sentence with an explanatory parenthetical. Every word contributes and there is no redundant or filler content.

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 tool, the description provides enough context to invoke it successfully. It does not specify return fields, but there is no output schema and the tool is simple enough that this is a minor gap.

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

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

The input schema has no parameters, so there is nothing for the description to document about arguments. The description compensates by clarifying what the no-argument call returns: open incidents associated with a charger.

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 identifies the resource ('incidencias') and scope ('abiertas por cargador', 'averías reportadas'), so an agent can distinguish it from listing chargers or sessions. It lacks an explicit verb in the description, though the title 'Listar incidencias' supplies that.

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 use case is implied: call when you need open/reported incidents per charger. It gives no explicit when-not-to-use or alternatives such as askacharge_diagnosticos or askacharge_estado_en_vivo, so guidance is only inferred.

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, idempotentHint, and openWorldHint=false, which cover side-effect safety. The description adds what the history contains (energy, revenue, cost) but says nothing about ordering, date filtering, or pagination behavior beyond the schema's limit parameter.

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

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

Two short sentences with no filler. The first sentence states the resource and contents; the second gives usage purposes. 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?

For a simple read-only list tool with one optional parameter and no output schema, the description gives enough to select and invoke it: the resource, the returned data fields, and intended use cases. It could be slightly stronger with an explicit statement of ordering, but this is not a critical gap.

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

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

Schema coverage is 100%: the single optional 'limit' parameter is described with its default value of 50. The description adds no extra meaning about this parameter, 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?

The description clearly identifies the resource ('sesiones de carga') and the returned data ('energía, ingresos y coste'), and the use cases help distinguish it from sibling list tools such as listar_cargadores or listar_clientes. However, it uses the noun 'Historial' rather than an explicit verb like 'Lista' or 'Devuelve', so the action is only implied.

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?

'Úsalo para analizar consumo, facturación o detectar cargas anómalas' provides explicit contexts for when to use the tool. It does not mention exclusions or alternative tools, so it falls short of the top score.

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 carry readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is known. The description adds behavioral context beyond annotations: output ordering ('la tarifa por defecto en primer lugar'), the fact that prices are included, and the scope ('de la marca'). It does not disclose rate limits or failure modes, but the read-only nature makes these less critical.

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 that each earn their place: what is listed, the read-only guarantee, and explicit routing to alternatives. The most important information (resource and default ordering) is front-loaded in the first sentence.

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

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

For a zero-parameter read-only list, the description fully covers what the agent needs to select and invoke it: it returns all brand tariff groups of the listed types, includes price, puts the default first, and is safe. With no parameters and simple annotations, no further detail is necessary.

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 is empty (0 parameters), so there are no parameter semantics to explain. The description's mention of pricing-model categories is domain context rather than parameter documentation; with no parameters, this is effectively complete.

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 action ('Lista') on a specific resource ('grupos de tarifa de la marca'), enumerates the pricing-model variants (kWh, hora, sesión, combinado, margen sobre PVPC, gratis), and notes the default tariff is listed first. It also names sibling tools for related operations, so it is clearly distinguishable from crear_tarifa and precio_pvpc_hoy.

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?

Explicitly tells when not to use it: to create a tariff use askacharge_crear_tarifa, and for hourly market pricing use askacharge_precio_pvpc_hoy. The read-only note ('Solo lee, no cambia nada') reinforces that this is the safe lookup among the tariff-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?

Annotations already flag destructiveHint=true and idempotentHint=false; the description adds useful behavior beyond that: permissions are checked like other tools, the key needs the resource scope, and the full 456-operation contract is available at a URL. It does not contradict the annotations.

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

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

Three dense sentences with front-loaded purpose, then URL, permissions, and constraints. No wasted words, and every sentence carries operational information.

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

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

For a catch-all tool without an output schema, this is complete: it cannot enumerate 456 operations, so linking the full OpenAPI contract is the right approach; it also states scope requirements and allowed route prefixes. An agent has everything needed to decide and invoke 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?

All three parameters are described in the schema, so the baseline is 3. The description adds value by whitelisting valid route prefixes and pointing to the contract, which tells an agent which routes are legal and where to find valid values for method and body.

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?

It uses a clear verb and resource: 'Llama a cualquier endpoint de la API de la marca' and explicitly positions itself as the catch-all for operations not covered by sibling tools. The route restriction and contract URL further define what the tool does and differentiate it from the 22 specialized siblings.

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

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

It states the usage condition directly: use it 'para lo que no cubran las herramientas anteriores', implying siblings have priority and this tool is the fallback. It also gives a negative constraint: only routes under /api/brand and /api/ext are valid, which helps prevent invalid calls.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds a valuable warning that this action cuts a driver's charge, which is behavioral context beyond the annotations. It also names the OCPP RemoteStopTransaction protocol, giving technical transparency.

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

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

Two sentences with zero waste. The core action is front-loaded, the protocol is named, and the warning is placed immediately after. 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?

For a destructive action with no output schema, the description covers the key behavioral risk (cutting a driver's charge) and the protocol. It doesn't describe the response format, but with no output schema and a simple action, this is a minor gap. The warning compensates for the lack of annotation detail.

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 schema already documents both parameters. The description adds no extra parameter-level meaning beyond what the schema provides, but it does clarify the optionality of transaction_id by saying 'si se omite, se para la sesión activa del cargador' — though that's already in the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Para una carga en curso') and the resource (a charging session via OCPP RemoteStopTransaction). It clearly distinguishes this from sibling tools like askacharge_arrancar_carga (start charging) and askacharge_desbloquear_conector (unlock connector).

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 stop an ongoing charge. It doesn't explicitly name alternatives or exclusions, but the sibling list and the verb 'para' make the context clear. The warning about cutting a driver's charge adds practical usage 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?

The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful context about the temporal scope ('hoy'), granularity ('hora a hora'), and market ('mercado regulado español'). It does not disclose data source, update frequency, or exact return format, which keeps it at a mid-range score.

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

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

The description is two sentences with no filler. The first sentence states exactly what the tool returns, and the second sentence gives practical usage guidance. It is front-loaded and 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?

For a no-parameter, read-only price lookup, the description is complete enough: it specifies the resource, time scope, granularity, market, and use case. No output schema exists, but the phrase 'hora a hora' makes the expected return shape clear. There are no missing details that would prevent an agent from invoking 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 the description does not need to explain parameter semantics. The baseline for zero-parameter tools is 4, and the description adds relevant context about what the returned data represents. There is no schema information to compensate for, making this appropriate.

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

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

The description clearly states the resource: 'Precio PVPC hora a hora de hoy (mercado regulado español).' It uses a specific verb and scope, and the use case helps an agent understand exactly what data this tool provides. There is no sibling with a similar purpose, so confusion is unlikely.

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 explicitly says when to use it: 'Úsalo para decidir cuándo conviene cargar o para fijar un margen sobre el precio real.' It provides clear practical context, though it does not mention alternatives or when not to use it. Given the sibling list contains no other price lookup tool, this is sufficient.

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 idempotentHint=true and destructiveHint=false, and the description adds that it 'No cambia nada en el cargador' and explains the result arrives via webhook connector.status, viewable in another tool. This goes beyond the annotations by describing the actual effect and follow-up, which is valuable for an agent.

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 slightly long but every sentence adds value: it explains the mechanism, provides usage timing, confirms non-destructiveness, and points to the output channel. It is front-loaded with the core action and then details. Not overly verbose, though it 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?

Given the tool has no output schema, the description compensates by explaining what happens after the request (state arrives via webhook, viewable in askacharge_ver_cargador) and how it fits into a workflow (after a command). It is complete for an agent to use 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 100%, so all three parameters are documented in the schema. The description adds meaning by explaining the purpose of each requested_message type (e.g., 'Heartbeat para comprobar que responde') and clarifies connector_id behavior ('si se omite, el cargador entero'), enriching the schema.

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

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

The description clearly states the verb ('Pide al cargador que envíe ya un mensaje concreto'), the resource (the charger), and the specific OCPP messages it can request (StatusNotification, Heartbeat, MeterValues). It also distinguishes itself from the sibling askacharge_ver_cargador by noting the new state is visible there, making the purpose 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?

Explicit guidance: 'Úsalo tras un comando para verificar el resultado sin esperar al siguiente latido' tells when to use it, and it clarifies the alternative for viewing the result (askacharge_ver_cargador). It also states it does not change anything, which sets expectations clearly.

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?

Adds concrete consequences beyond the annotations: 'Deja el punto fuera de servicio unos minutos y aborta las sesiones en curso' (leaves the point out of service for a few minutes and aborts ongoing sessions). It also defines the behavioral difference between Soft and Hard resets. Consistent with destructiveHint=true; no contradiction.

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 dense sentences with zero filler: the verb+resource is front-loaded, the mode semantics are given, and the safety warning closes the description. 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?

Covers purpose, both modes, full impact (out of service, aborted sessions), and the precondition check — strong for a destructive command with only two parameters. It does not describe the expected response or confirmation, but the absence of an output schema makes this a minor gap.

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

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

Schema coverage is 100% and the description adds value by explaining what the reset_type values actually do ('Soft reinicia el software y Hard es un corte completo'), which the schema does not. This goes beyond the schema's bare default note.

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: 'Reinicia el cargador (OCPP Reset)', and explains the two reset modes (Soft vs Hard). The operation is clearly distinct from siblings like parar_carga (stops a session) and cambiar_disponibilidad (changes availability), so an agent can tell them apart.

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 a clear precondition: 'comprueba antes que no haya ninguna activa' (check no active sessions before resetting), which tells the agent when it is safe to invoke the tool. It stops short of naming the specific sibling tool to use for that check (e.g., listar_sesiones or estado_en_vivo), so no explicit alternatives are 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?

The description adds behavioral context beyond the annotations by explaining that it only reads and changes nothing, and by indicating it returns both KPI aggregates and variation versus the previous period. Since annotations already cover readOnlyHint and idempotentHint, the description's extra value is moderate but meaningful; no contradiction is present.

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 front-loaded: it states the returned data first, then the read-only guarantee, then the routing to alternatives. Every sentence earns its place, and there is no redundant or vague filler.

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

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

For a read-only summary tool with one optional parameter and no output schema, the description is complete: it defines what is returned, the period concept, the safety profile, and how to choose related tools. An agent has enough information to select and invoke 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 100% for the single parameter, and the parameter has an enum with a clear description of each period option. The description refers to 'periodo' but does not add details beyond the schema, which is acceptable because the schema already carries the burden fully.

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

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

The description uses a specific verb ('Devuelve') and names the exact resource: aggregated KPIs for a period, listing the metrics (energía, facturado, margen neto, sesiones, clientes) and the variation versus the previous period. It clearly distinguishes itself from sibling tools by naming what it is not, such as session-level detail and real-time status.

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

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

The description explicitly states when to use this tool versus alternatives: use askacharge_listar_sesiones for session-by-session detail and askacharge_estado_en_vivo for current activity. It also signals this tool is read-only, reinforcing it as a safe periodic-summary choice.

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?

Aunque las anotaciones ya declaran readOnlyHint=true e idempotentHint=true, la descripción añade contexto valioso: qué operaciones se registran, cuáles se omiten, orden temporal, retención de 90 días y los campos devueltos. Esto va más allá de lo que las anotaciones estructuradas proporcionan y no contradice ninguna de ellas.

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

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

Tres oraciones que aportan toda la información relevante sin redundancia. La acción principal está al inicio, seguida de los matices de comportamiento, la naturaleza de solo lectura y la alternativa para el caso distinto. Cada frase cumple una función.

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

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

Para una herramienta de consulta con tres parámetros opcionales y sin esquema de salida, la descripción cubre lo esencial: qué devuelve, en qué orden, qué queda excluido, por cuánto tiempo se conservan los datos y cuándo recurrir a otra herramienta. No falta información crítica para invocarla correctamente.

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

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

La cobertura del esquema es del 100%, por lo que el esquema ya documenta los tres parámetros. La descripción añade contexto sobre el contenido de la traza y la exclusión de lecturas correctas, pero no aporta detalles nuevos esenciales sobre limit, key_id o solo_errores más allá del esquema.

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 usa un verbo específico ('Lista'), identifica claramente el recurso (traza de las API keys) y detalla qué información incluye (escrituras e intentos rechazados con método, ruta, código, IP y duración). Además, se diferencia explícitamente de askacharge_listar_sesiones al señalar que esa es la herramienta para actividad de carga.

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?

Indica con claridad para qué sirve ('herramienta de auditoría de credenciales') y cuándo NO usarla: para ver actividad de carga indica explícitamente askacharge_listar_sesiones. También aclara que las lecturas correctas no se registran, evitando que el agente espere eventos que no estarán en la traza.

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 idempotentHint=true, so the safety profile is established without description help. The description adds value by disclosing the specific attributes returned (connectors, power, access mode, status), going beyond the annotations. No failure or side-effect behavior is described, but for a read-only, idempotent tool the annotations carry the main burden.

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 zero filler; it states the resource and its content compactly and every word earns its place. It reads as a noun phrase rather than a full behavioral statement, which is a minor stylistic shortfall.

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 low-complexity read tool (one required parameter, no output schema, no nested objects), the description names the returned content, partially compensating for the missing output schema. It does not mention error behavior for an unknown charge_point_id, but that is a minor gap for a read-only lookup whose annotations already confirm safety.

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%, with charge_point_id fully documented as 'Identificador de fábrica, p. ej. CP001'. The description adds no parameter-level semantics beyond what the schema already provides, 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?

The description 'Detalle de un cargador concreto: conectores, potencia, modo de acceso y estado' clearly states the resource (a specific charger) and the returned content (connectors, power, access mode, status), making the purpose unambiguous. It is implicitly distinguished from 'listar_cargadores' by the word 'concreto', though no explicit differentiation is made against the overlapping-sounding sibling 'estado_en_vivo'.

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 when-to-use or when-not-to-use guidance is given, and no alternative tools are named. The word 'concreto' implies this tool is for fetching a single charger's detail rather than listing all chargers, but the agent must infer this; nothing routes the agent between this tool and 'estado_en_vivo', which also deals with charger status.

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