kite-connect-mcp

Session status

session_status

Read-onlyIdempotent

Check whether the Kite session is logged in and when its token expires; optionally verify with Kite that the token is still accepted, so you can reauthenticate before trading.

Instructions

Whether this server is logged in to Kite, and what to do if it is not. Call this first: Kite sessions end every day at 06:00 IST.

Returns logged_in, the token's expires_at and minutes_left, auth_mode (managed: this server does the daily login; external: another program keeps the token file and this server only reads it), login_managed_here, the token file path, minutes_to_token_reset (to the next 06:00 IST), and a one-line safety summary (trading mode, read-only). The token itself is never shown.

verify=true also makes one live call to Kite and adds verify with the user id or Kite's error. Use it when a token that looks valid might have been ended elsewhere (logging in again with the same API key, or a master logout on the Kite web, ends the earlier token).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "session_status"
  }
}

Input Schema

Name	Required	Description	Default
`verify`	No	also ask Kite once (GET /user/profile) whether it still accepts the token, and report the account's user id or Kite's error

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, and the description adds substantial context beyond them: the daily 06:00 IST session expiry, the managed-vs-external auth mode distinction, the fact that the token is never returned, and that verify=true causes exactly one live GET /user/profile call. The only gap is that the cost of that live call (latency/failure modes) is not framed as such.

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?

Key facts are front-loaded: the yes/no question first, then the daily 06:00 IST reset, then the return fields, then the optional verify path. The field enumeration is dense but earns its place because no output schema exists, though the parenthetical auth-mode gloss is somewhat longer than needed.

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?

With no output schema, the description carries the return contract itself and does so thoroughly: every field is named (logged_in, expires_at, minutes_left, auth_mode, login_managed_here, token path, minutes_to_token_reset, safety) and the verify-only addition is separated. An agent has everything it needs to call this correctly and interpret the result.

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?

The single parameter is already documented at 100% schema coverage, including the exact endpoint used. The description goes further by explaining the real-world situations that justify setting verify=true, which the schema does not convey, and by specifying what extra output appears.

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 opening sentence states a specific subject and question: whether this server is logged in to Kite, plus what to do otherwise. That is unambiguous, but it never names the session-related siblings (login, complete_login, logout) it sits beside, so differentiation is inferred from ordering ('Call this first') 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 Guidelines4/5

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

It gives a clear default trigger ('Call this first') and a precise conditional trigger for verify=true (a token that looks valid may have been ended elsewhere, e.g. re-login with the same API key or a master logout). It stops short of naming the fallback tool to call when logged_in is false, leaving that step implicit.

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