kite-connect-mcp

Log in to Kite

login

Starts the daily Kite authentication flow and returns a one-time link so the user can sign in themselves; never asks for credentials.

Instructions

Start the daily Kite login (managed auth mode): returns a one-time login link for the person to open. Show them the warning and the link. They log in at Kite themselves (user id, password, 2FA); never ask for their credentials and never try to log in for them.

Kite then redirects to the app's registered redirect URL (redirect_url). This server completes the login when that redirect reaches it; if the redirect page cannot be reached, the person can copy the request_token from the browser's address bar (or the whole URL) and you call complete_login with it.

If a valid token already exists nothing is issued, unless force=true; a new login ends the old token at Kite. In external auth mode another program owns the login: this only explains and shows the status.

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": "login"
  }
}

Input Schema

Name	Required	Description	Default
`force`	No	issue a new link even though a valid token exists (the new login ends the old token)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, non-idempotent and open-world, but the description goes further: a new login ends the old token at Kite, and nothing is issued when a valid token exists unless force=true. It also imposes an important safety norm (never ask for credentials, never log in on the user's behalf) and warns the agent to surface the `warning` field. It does not describe the shape of the returned link/warning payload or its lifetime, which is the remaining gap.

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?

Front-loaded with the action and the artifact, then the fallback and edge cases in descending priority. It is dense across several sentences and could be tightened, but no sentence is filler — each adds a rule the agent must follow.

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?

Covers the whole flow an agent needs: issuing the link, what the user does, the redirect-completion path, the manual request_token fallback with the sibling to call, force semantics, and the external-auth mode that disables the whole flow. With only one well-documented parameter and no output schema, nothing material 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 baseline is 3; the description earns an extra point by explaining the default behavior the schema only implies — that no link is issued at all when a valid token exists, so `force` is the switch that changes the outcome rather than a cosmetic flag.

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 and resource ("Start the daily Kite login") plus the concrete artifact returned (a one-time login link), and scopes it to managed auth mode. An agent can tell it apart from `complete_login`, `session_status`, and `logout` without opening any schema.

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?

Explicitly routes the agent: call this to get a link, and if the redirect page cannot be reached, call `complete_login` with the request_token instead. It also names the exclusion case (external auth mode, where another program owns the login and this tool only reports status).

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