Skip to main content
Glama
Sign In

Boletín Claro

by es.boletinclaro
OverviewDiscussionsAdmin

Borrar alerta

borrar_alerta
Destructive

Borra una de tus alertas de forma PERMANENTE, junto con las entradas que no se hayan archivado (y sus notas y documentos); lo archivado bajo un cliente, con sus notas, se queda, igual que lo que también encontró otra alerta. Indica el 'nombre' de la alerta tal como aparece en listar_mis_alertas. Es IRREVERSIBLE: llama primero con confirmar=false (por defecto) para avisar al usuario de qué se va a borrar, y solo con su visto bueno vuelve a llamar con confirmar=true. Si solo quiere dejar de recibir avisos sin perder el histórico, páusala con editar_alerta (activa=false). Requiere iniciar sesión. Coste: 0.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "nombre": "<nombre>"
    },
    "name": "borrar_alerta"
  }
}

Input Schema

NameRequiredDescriptionDefault
nombreYesNombre de la alerta a borrar, tal como aparece en listar_mis_alertas.
confirmarNoDéjalo en false (por defecto) para ver primero qué alerta se va a borrar; el borrado es permanente, así que vuelve a llamar con true para confirmarlo.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only supply destructiveHint=true, and the description goes well beyond that: it enumerates exactly what is destroyed (unarchived entries, their notes and documents), what survives (client-archived items, entries also found by another alert), states irreversibility explicitly, requires login, and notes cost 0. This is unusually rich disclosure of consequences for a destructive mutation.

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

Conciseness4/5

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

The permanent-deletion consequence is front-loaded and the safety protocol follows in priority order; nearly every clause carries non-redundant information. It is a dense single block with nested parentheticals, which slightly hurts scannability, but there is little wasted wording.

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

Completeness5/5

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

For a 2-parameter destructive tool with only destructiveHint coverage and no output schema, the description covers consequences, reversibility, auth and cost requirements, and the required call sequence. Nothing an agent needs to invoke it safely is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-tool meaning by tying 'nombre' to the value shown in listar_mis_alertas and frames 'confirmar' as a safety workflow rather than a plain boolean. It stops short of restating the schema's parameter details, which is appropriate.

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

Purpose5/5

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

The description opens with a specific verb and resource ('Borra una de tus alertas de forma PERMANENTE') and immediately scopes what is removed versus retained (unarchived entries with notes/documents go; client-archived items and entries also found by another alert stay). It is clearly distinguishable from siblings editar_alerta (pausing) and listar_mis_alertas (source of the name).

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

Usage Guidelines5/5

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

It gives an explicit two-step protocol (call with confirmar=false first, then confirmar=true only after user approval) and names the alternative for a different intent: if the user only wants to stop notifications without losing history, use editar_alerta with activa=false. When-to-use and when-not-to-use are both stated.

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

All Boletín Claro toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources