kite-connect-mcp

Delete alerts (dry run by default)

delete_alerts

Destructive

Delete up to 50 Kite alerts in one call by UUID, with a dry-run preview by default. Deleting an ato alert also removes the orders it would have placed.

Instructions

Delete one or more alerts in a single call (a deleted alert shows status 'deleted'). Deleting an ato alert also removes the orders it would have placed. DRY RUN BY DEFAULT, confirmed like create_alert. No caps or allow-lists apply to a deletion. The dry run lists the alerts that will be deleted. Kite answers with no data when it is sent.

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": {
      "uuids": "<uuids>"
    },
    "name": "delete_alerts"
  }
}

Input Schema

Name	Required	Description
`uuids`	Yes	uuids of the alerts to delete (see get_alerts), up to 50
`dry_run`	No	true (default): validate and preview only, nothing is sent. false: send it live, which needs live trading enabled on the server and the confirmation_token from a dry run
`confirmation_token`	No	the confirmation_token returned by a dry run of this exact call (single use)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description goes well beyond them: cascade behavior ('deleting an ato alert also removes the orders it would have placed'), soft-delete result state, the two-step dry-run/confirmation-token flow, the absence of caps or allow-lists, and an empty response body. These are exactly the side effects an agent needs before a destructive call.

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 dry-run warning is front-loaded in caps and the cascade warning follows immediately, which is the right ordering. A few phrases are terse to the point of ambiguity ('confirmed like create_alert', 'Kite answers with no data when it is sent') and require knowledge of a sibling tool.

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

Completeness4/5

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

For a destructive, open-world mutation with no output schema, the description covers safety (dry run), authorization (live trading enabled, confirmation token), cascading effects and the empty response. It leaves open behavior on partial failure (e.g., one invalid uuid among 50) and whether deletion is reversible.

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

Parameters3/5

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

With 100% schema description coverage, the schema already documents uuids (up to 50, format, see get_alerts), dry_run default and confirmation_token single-use semantics. The description only restates the dry-run preview behavior, adding little parameter-level meaning beyond the schema.

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?

States a specific verb ('Delete') and resource ('one or more alerts in a single call'), plus the batch scope and result state ('a deleted alert shows status 'deleted''). It is trivially distinguishable from get_alerts, create_alert and modify_alert in the sibling list.

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

Usage Guidelines4/5

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

Makes the operating mode explicit: dry run is the default, live execution requires live trading enabled plus the confirmation_token from that dry run, and it points to create_alert for the same confirmation pattern. It does not explicitly route to modify_alert for non-destructive edits, but the context is otherwise clear.

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