kite-connect-mcp

When an alert triggered

get_alert_history

Read-onlyIdempotent

Retrieve an alert's trigger history, newest first, including the evaluated condition, IST timestamp, instrument market data, and any orders placed for ATO alerts.

Instructions

Every time the alert triggered, newest first: the condition as evaluated, created_at (IST), the market data of the instrument at that moment (last_price, ohlc, volume, oi, ...) and, for an ato alert, the orders it placed (order_meta).

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": {
      "uuid": "<uuid>"
    },
    "name": "get_alert_history"
  }
}

Input Schema

Name	Required	Description
`uuid`	Yes	the alert's uuid (see get_alerts)
`limit`	No
`offset`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare this a read-only, idempotent, non-destructive, open-world read. The description goes beyond them by disclosing ordering (newest first), the timezone of created_at (IST), the exact market-data fields captured per trigger, and the conditional order_meta payload for ato alerts. It does not mention volume of results beyond the implicit pagination, but the substantive behavioral context 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.

Conciseness4/5

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

A single dense sentence that front-loads the key framing ("Every time the alert triggered, newest first") before enumerating the returned fields. The parenthetical field list is efficient, though the sentence is long enough to verge on a run-on.

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

Completeness3/5

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

With no output schema, the description carries the burden of explaining return values, and it does so reasonably by naming the condition, timestamp, market-data fields, and order_meta. However, it says nothing about pagination behavior, result-size limits, or what an empty history looks like — gaps that matter for a history endpoint.

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

Parameters2/5

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

Schema coverage is only 33%: uuid is documented, while limit and offset carry no description. The description never addresses pagination at all — no default of 50, no 500 cap, no guidance on paging through a long trigger history. Only the "newest first" ordering indirectly informs how offset behaves.

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

Purpose4/5

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

The description precisely frames the resource as the trigger history of one alert ("Every time the alert triggered"), which implicitly separates it from get_alert and get_alerts. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can reason that this tool yields past triggers while get_alert returns the alert definition. There is no explicit when-to-use, when-not-to-use, or alternative named (e.g., "to inspect or edit the alert itself, use get_alert/modify_alert").

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