kite-connect-mcp

Mutual fund orders

get_mf_orders

Read-onlyIdempotent

Retrieve mutual fund orders from the last 7 days or fetch any single order by its order_id, optionally filtered by status. Use it to track lump sum and SIP instalments with amounts, NAV, and folio details.

Instructions

Mutual fund orders. With order_id: that one order, however old. Without: every order of the last 7 days (open and executed, lump sums and SIP instalments), newest first, optionally filtered by status, with status_counts over the whole window. Each order has order_id, status, status_message, tradingsymbol (ISIN), fund, transaction_type, amount (INR), quantity (units allotted or sold), average_price (the NAV used), last_price (latest NAV), variety (regular, sip, amc_sip), folio and tag.

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

Input Schema

Name	Required	Description
`limit`	No	items per page
`offset`	No	items to skip
`status`	No	list only: keep orders in this status, case-insensitive (COMPLETE, REJECTED, CANCELLED, OPEN...; status_counts shows which exist)
`order_id`	No	one order, whatever its age (the list only goes back 7 days)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the bar is lower. The description still earns credit by disclosing the 7-day list window, newest-first ordering, and that status_counts covers the whole window rather than the page. It does not describe pagination limits or the response envelope beyond the field list.

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 resource and the mode split before the detail, and the long second sentence is dense but purposeful. The trailing field enumeration is long yet justified because no output schema exists.

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?

With no output schema, the description compensates well by enumerating returned fields and their meanings (status, tradingsymbol as ISIN, amount in INR, variety types). What remains thin is pagination behavior and the exact shape of status_counts, though the schema covers limit/offset.

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 would be 3, but the description adds genuine meaning: order_id bypasses the 7-day restriction, status filters only the list, and the field names (quantity as units allotted or sold, average_price as the NAV used) are clarified. Only limit/offset get no added semantics, which the schema already covers.

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?

States a specific resource (mutual fund orders) and explicitly splits the two operating modes: a single order via order_id versus a 7-day list. An agent can distinguish it from the equity-oriented get_orders by the 'Mutual fund' qualifier, though it never names get_mf_sips as the sibling for SIP-level data even while mentioning SIP instalments.

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?

Gives clear when-to-use conditions for both modes: pass order_id for an order of any age, omit it to get the last 7 days of open and executed orders. It also states that status only applies to the list mode. It stops short of explicitly pointing at alternative tools for other flavors of order data.

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