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

With no annotations, the description carries the full burden; it does contribute that the call is read-only and free on all tiers, which is genuinely useful cost/safety context. However, it omits that orders are capped (maxItems 50), that nothing is actually placed, and how the result is shaped (breakdown vs compact total).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences with the core purpose front-loaded and no filler; the free-tier note is short and attached to the safety claim rather than padding.

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

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

For a tool with a complex array-of-objects parameter, no annotations, and no output schema, the description explains the concept but leaves out the result shape (margin breakdown vs total-only under compact) and the 50-order ceiling. It is adequate to understand intent, not to call confidently.

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

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

Schema coverage is 67%, but the description says nothing about any of the three parameters: the nested order object's required fields, the 'compact' toggle, or the default-true 'consider_positions' behavior. 'Accounting for hedges/offsets' hints at consider_positions at best, which is too indirect to compensate for the coverage gap.

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

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

States a specific verb (calculate) and resource (combined margin for a basket of orders), with the distinguishing concept of hedges/offsets across legs (e.g. a spread). This implicitly separates it from the single-order sibling calculate_order_margins, but it never names that sibling or get_margins, so the routing signal 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.

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

The phrase 'hypothetical orders' and the spread example imply the pre-trade what-if scenario, but there is no explicit when-to-use, no when-not-to-use, and no named alternative (e.g. 'for a single order use calculate_order_margins'). An agent must infer its niche from context.

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

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

With no annotations present, the description carries the disclosure burden and does so well: it declares the operation is hypothetical ('without placing them'), read-only, and costless ('free on all tiers'), covering the safety and rate/credit profile an agent needs. It omits the batch-size cap (max 50) and whether unknown symbols cause per-order errors, but the core behavioral traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three compact clauses, front-loaded with the verb and resource, then the usage timing, then the cost/safety note. No filler, no restatement of the name.

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

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

No output schema exists, and the description does not say what is returned (per-order margin breakdown vs totals) – though the 'compact' schema field implies it. It fully covers purpose, timing, and safety/cost, which is enough for a 2-parameter read-only tool, but the missing return-shape hint and the unexplained overlap with calculate_basket_margins keep it from a 5.

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

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

Schema description coverage is 50% – the 'compact' flag is documented inline, while the 'orders' array and its nested fields carry no descriptions, only required lists and enums. The description helps only marginally by saying 'one or more hypothetical orders', which maps to the array cardinality; it adds no semantics for the nested order fields or for what 'compact' changes in the output. Baseline 3 is appropriate since the nested schema is largely self-explanatory via required/enum constraints.

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

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

States a specific verb and resource ('Calculate the margin required') plus a distinguishing scope qualifier ('for one or more hypothetical orders, without placing them'). It separates itself from place_order but never mentions the sibling calculate_basket_margins, which computes a very similar thing for a basket, so an agent cannot fully discriminate the two from the description alone.

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

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

Gives explicit timing ('Use this before place_order to check affordability/leverage'), which tells the agent both when to call it and which sibling it complements. There are no explicit exclusions (e.g., when to prefer calculate_basket_margins or get_margins), so it stops short of a full when/when-not statement.

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

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

With no annotations, the description carries the full burden and does disclose the single most important behavioral trait: the call is a dry-run unless KITE_MCP_ENABLE_TRADING=true, preventing an agent from mistaking a no-op for a real cancellation. It does not cover error behavior for already-executed orders, reversibility, or how the response signals dry-run vs. real execution.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, zero filler, with the operation front-loaded and the safety gate immediately after. Nothing could be removed without losing information.

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

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

For a one-parameter cancel with no output schema, the description covers the critical execution gate but leaves order_id provenance and post-call state (what happens on success vs. failure, how to confirm) undocumented. Adequate to attempt the call, not adequate to predict its outcome.

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

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

Schema coverage is 0% and the description says nothing about order_id — no format, no provenance (e.g., obtainable from get_mf_orders), no constraint that it must reference a pending MF order. For a single-param tool where the schema is bare, the description should compensate and does not.

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

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

States a specific verb and resource ('Cancel a pending mutual fund order') plus a qualifier ('pending') that bounds the operation. It is implicitly distinguishable from cancel_order and cancel_mf_sip by the 'mf'/'order' naming, but the description never names those siblings to make the distinction explicit.

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

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

Usage is implied by the tool name and the 'pending' qualifier, but there is no explicit guidance on when to use this versus cancel_mf_sip or the equity cancel_order, nor any advice to check get_mf_orders first for the order_id. The dry-run sentence is a condition of execution rather than guidance on tool selection.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that execution is a dry-run unless KITE_MCP_ENABLE_TRADING=true is set, which is important safety context. However, it does not explain whether a real cancellation is irreversible, what side effects occur, or what authentication or confirmation behavior applies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two short sentences with no wasted text. The action is front-loaded, and the dry-run condition follows immediately as the most important operational caveat.

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

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

The tool is simple, with one required parameter and no output schema. The description covers the core action and the key dry-run gate, but for an unannotated cancellation mutation it still omits important context about irreversibility, return behavior, and parameter provenance.

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

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

Schema description coverage is 0%, and the description adds no information about sip_id beyond the schema's own name. It does not explain the expected format, where to obtain the SIP identifier, or whether it comes from get_mf_sips.

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

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

The description states a specific verb and resource: 'Cancel an SIP.' This clearly distinguishes it from sibling order-cancellation tools such as cancel_order and cancel_mf_order. It does not explicitly spell out the mutual-fund context or name the closest SIP siblings, but the purpose is still clear.

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

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

The description gives no guidance on when to use this tool versus modify_mf_sip, place_mf_sip, or cancel_mf_order. It only states the cancellation action and the dry-run condition; it does not say which situations require this tool or which prerequisites must be met.

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

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

With no annotations, the description carries the full burden, and it discloses the single most important behavior: execution is a dry-run unless KITE_MCP_ENABLE_TRADING=true. That is real value an agent cannot get from the schema. Gaps remain — irreversibility of a real cancellation and error behavior on non-pending or partially filled orders are not mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, zero waste, and the dry-run gating — the thing an agent most needs to know before calling — is stated up front rather than buried.

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

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

For a three-parameter mutation tool with no annotations and no output schema, the description covers the critical execution-gating behavior. It leaves open what a dry-run returns and what happens on failure, but the essentials for safe invocation are present.

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

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

Schema coverage is 67%, with order_id undocumented and variety described only as "Order variety" despite a five-value enum. The description adds no parameter-level detail beyond implying order_id must reference a pending order; parent_order_id's CO-leg requirement lives entirely in the schema.

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

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

"Cancel a pending order" gives a specific verb and resource with a scope qualifier (pending) that rules out cancelling executed orders. It does not differentiate from the close siblings cancel_mf_order or modify_order, so the agent must infer that this is for equity/derivative orders rather than mutual fund orders.

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

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

The word "pending" implicitly states a precondition for use, and the dry-run note gives context about what invoking it actually does. It never names alternatives (modify_order to change rather than cancel, cancel_mf_order for fund orders) or states what to do if the order is not pending, so routing guidance is only implied.

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

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

With zero annotations, the description carries the full burden, and it does disclose one critical trait: the call is a dry-run unless KITE_MCP_ENABLE_TRADING=true. That is genuinely valuable and non-obvious. However, it omits auth/permission requirements, whether an executed conversion is reversible, and what the dry-run response looks like, leaving significant behavioral gaps for a trading mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences with the core action and its example first, followed by the safety gate. Nothing is redundant and the critical dry-run warning is not buried.

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

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

For a 7-required-parameter mutation with no annotations and no output schema, the description is thin. It never clarifies how the fields relate (position_type vs old_product), what the dry-run returns, or what state changes on a real execution, so an agent could construct a call without understanding its effect.

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

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

Schema description coverage is 0% across 7 required parameters, so the description must compensate, and it largely does not. The MIS/CNC example hints at old_product and new_product, but position_type (overnight/day), transaction_type, quantity, exchange, and tradingsymbol are unexplained, and the overlap between position_type and old_product is left ambiguous.

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

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

States a specific verb and resource (convert an open position's product type) and disambiguates the jargon with a concrete example, moving an intraday MIS position to CNC overnight delivery. No sibling tool performs this action, and the example makes the concept unmistakable.

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

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

The 'open position' qualifier implies the precondition, and the MIS/CNC example implies the scenario, but there is no explicit when-to-use guidance or routing versus alternatives such as modify_order or cancel-and-replace. An agent must infer that this is the correct tool for product-type changes only.

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

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

With no annotations, the description carries the full disclosure burden, and it does surface the most important trait for a destructive tool: it is a no-op dry-run unless KITE_MCP_ENABLE_TRADING=true. It omits what a dry-run response looks like, whether deletion is reversible, and what happens if the trigger_id does not exist, so it stops short of full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences with the core action first and the safety gate second. No filler and nothing buried.

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

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

For a destructive, annotation-free mutation tool with no output schema, purpose and the trading-enable gate are covered, but irreversibility, failure behavior, and the meaning of the required trigger_id are not. An agent can call it, but with residual uncertainty about side effects.

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

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

The single parameter trigger_id has 0% schema description coverage and is never mentioned in the description. The agent must infer from the name alone that it is the GTT trigger identifier, and nothing explains its format or provenance (e.g. from get_gtts).

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

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

"Delete (cancel) a GTT order" gives a specific verb plus resource and clarifies that delete means cancel here. The GTT qualifier implicitly separates it from cancel_order/cancel_mf_order, though no sibling is named explicitly.

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

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

The dry-run/enable-flag sentence tells the agent the real precondition for an actual deletion, which is useful usage context. It never states when to use this versus modify_gtt or cancel_order, so the choice between GTT management tools is left to inference.

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

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

No annotations are provided, so the description carries full disclosure burden. The verb 'Get' correctly signals a read-only operation and the description clarifies the scope (auction session) and business purpose, but it says nothing about permissions, session prerequisites, or whether the result is empty when no auction is active. Reasonable but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single front-loaded sentence that states the action, the scope, and the business purpose with no filler. Every clause earns its place.

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

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

For a no-parameter, no-output-schema read tool this is close to sufficient: the agent knows what it retrieves and why. A brief note on what happens outside an auction session or what fields each instrument entry carries would close the remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to explain and the baseline of 4 applies. Nothing in the description misleads about inputs.

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

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

States a specific verb and resource (get instruments) scoped to an auction session, which is distinctive enough to separate it from search_instruments or get_quote. It doesn't explicitly name a sibling or contrast behavior, so it stops short of the top score.

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

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

The parenthetical 'used to cover short-delivery obligations' implies the situation in which an agent should reach for this tool, which is more than nothing. But there is no explicit when-not guidance and no named alternative for the broader instrument lookup case (e.g., search_instruments).

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

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

No annotations exist, so the description carries the full disclosure burden. 'Get' implies a non-mutating read, but nothing is said about error behavior for an invalid or expired trigger id, what fields are returned, or whether the GTT must be in a particular state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One short sentence, front-loaded with the verb and resource, with no filler. It is efficient, though its brevity comes partly from omitting useful detail rather than from tight editing.

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

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

With no annotations and no output schema, the description would need to say what 'details' comprises and how an agent obtains a valid trigger_id. As written, an agent knows the intent but not the contract.

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

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

The schema has zero description coverage for trigger_id, and the description only restates that the lookup is 'by trigger id' without clarifying the format or that the value originates from get_gtts/place_gtt. It confirms the identifier's role but adds little operational detail.

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

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

States a specific verb and resource ('Get details of a single GTT order') and the 'single' qualifier implicitly separates it from the sibling get_gtts list tool. It doesn't explicitly name get_gtts as the alternative, so an agent must infer the split.

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

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

Usage is only implied: 'single GTT order by trigger id' suggests you call it on a known trigger_id rather than enumerating, which contrasts with get_gtts, but no explicit when-to-use or when-not-to-use guidance is given.

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

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

No annotations are provided, so the description carries the full behavioral burden. Saying 'List all active' implies a read-only listing scoped to active orders, but it does not disclose pagination, return shape, authorization needs, or what happens with inactive orders.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single front-loaded sentence with no wasted words. It states the action, scope, and acronym expansion efficiently.

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

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

For a simple zero-parameter listing tool, the description is enough to know the broad operation. However, with no annotations and no output schema, it leaves gaps around return format, pagination, and differentiation from the singular get_gtt sibling.

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

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

The tool has zero parameters, and the schema is an empty object, so there are no parameter semantics to explain. The baseline for a parameterless tool applies, and the description does not introduce confusing parameter-like language.

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

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

The description gives a specific verb and resource: 'List all active GTT (Good Till Triggered) orders.' It also defines scope as active orders, but it does not explicitly distinguish this list operation from the sibling get_gtt tool, so it stops short of a 5.

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

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

The description implies that the tool is for listing active GTT orders, but it gives no explicit guidance on when to use it instead of get_gtt, get_orders, or other order-related siblings. There are no exclusions, prerequisites, or alternative-selection hints.

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

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

With no annotations, the description carries the full burden and does well: it discloses the paid-tier gate, the exchange-imposed lookback cap on minute intervals versus day candles, and the practical consequence of large ranges. It omits error behavior and whether the call is pure read-only, and never describes the shape of the returned candle series.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Four short sentences, each doing distinct work: purpose, prerequisite, access gate, and granularity limit. The purpose is front-loaded and nothing is redundant.

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

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

For a 7-parameter read tool with no annotations and no output schema, the description covers the essentials an agent needs before calling: token sourcing, entitlement, and range caps. The main gap is return shape, which with no output schema must be inferred.

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

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

Schema coverage is 71%, so the schema documents most fields including limit, oi, and continuous. The description adds real value on the interval parameter by tying minute granularity to a ~60-day lookback limit, but it says nothing about oi, continuous, or the date-format relationship between from_date and to_date.

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

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

States a specific verb and resource: fetch historical OHLC candles for an instrument. 'Historical' implicitly separates it from get_ohlc/get_quote siblings, but it never names them explicitly, so the differentiation has to be inferred.

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

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

Gives an explicit prerequisite chain: run search_instruments first to obtain the instrument_token, and note that a paid Kite Connect subscription is required. It does not address when to choose this over get_ohlc for current data, so it stops short of full alternative routing.

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

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

No annotations exist, so the description carries the burden; it does signal a read-only retrieval and clarifies that intraday positions are excluded, which is useful scope context. It does not cover return shape, whether holdings are empty for new accounts, or any auth/permission requirements — moderate gaps for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single sentence with the key scope distinction front-loaded in the parenthetical. Nothing is redundant or padded.

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

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

Given zero parameters, no annotations, and no output schema, the definition covers what an agent needs to decide to call it and roughly what comes back. It stops short of describing the holdings record fields, which leaves a small residual gap since no output schema documents them.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate at the argument level. Baseline 4 applies for a parameterless tool.

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

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

Names a specific verb and resource ('Get long-term equity holdings') and adds a scope qualifier ('stocks held in demat, not intraday positions') that separates it from get_positions. The word 'equity' also implicitly excludes get_mf_holdings, so an agent can pick the right sibling 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.

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

The parenthetical implies when this tool applies (portfolio holdings) versus intraday positions, but it never names get_positions or get_mf_holdings as alternatives or states an explicit selection rule. Usage is inferable rather than spelled out.

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

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

With no annotations, the description must carry the behavioral load, and it does disclose a real prerequisite: a paid Kite Connect subscription with market data access, which rules out free-tier callers. It says nothing about whether prices are real-time vs delayed, rate limits, or what happens when an instrument is invalid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, no waste, with the capability front-loaded and the access restriction following immediately. Nothing needs trimming or reordering.

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

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

For a one-parameter read tool this is close to adequate, and the subscription caveat is a meaningful addition. However, with no output schema and no annotations, the description leaves the return shape (one price per instrument? ordered? keyed by symbol?) and freshness semantics unstated.

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

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

Schema description coverage is 100% and the schema already documents the 'EXCHANGE:TRADINGSYMBOL' format and the 50-item max. The description's 'up to 50 instruments' merely restates maxItems, adding no format, batching, or error-handling detail beyond the schema.

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

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

States a specific verb+resource ('Get last traded price') and the scope ('up to 50 instruments'), so an agent knows exactly what data comes back. It does not differentiate itself from siblings like get_quote or get_ohlc, which return related market data.

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

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

Usage is only implied by naming the result (LTP). Nothing says when to prefer this over get_quote or get_ohlc, or that this is the lightweight option for bulk price checks versus full quote retrieval.

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

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

With no annotations, the description carries the full burden. "Get" signals a non-mutating lookup and "available" hints the values returned are currently usable margins rather than computed requirements, but there is no mention of account scoping, permissions, rate limits, or freshness of the margin values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences with zero filler, and the core action is front-loaded before the optional scoping detail.

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

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

For a one-parameter, zero-required read tool with full schema coverage and no output schema, the description covers enough to invoke it correctly. The one gap is disambiguation from the two calculate_* margin siblings, which the description leaves unaddressed.

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

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

Schema description coverage is 100% and the single enum parameter is fully documented in the schema. The description only restates that the filter is optional and repeats the two enum values, adding no semantics beyond the structured field.

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

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

States a specific verb and resource ("Get available trading margins") and adds a scope qualifier. It does not distinguish itself from the adjacent calculate_order_margins / calculate_basket_margins siblings, so an agent must infer whether "available" means a lookup of existing margin balances versus a computed requirement.

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

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

There is no statement of when to use this tool versus calculate_order_margins or calculate_basket_margins, which appear in the sibling list and share the margins domain. The only guidance is that the segment filter is optional, which is usage of a parameter, not of the tool.

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

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

With no annotations, the description carries the full behavioral burden and delivers almost nothing: "Get" implies read-only, but there is no statement about permissions, whether holdings are live or end-of-day, whether the response can be empty when no MF folio exists, or what the payload looks like (no output schema).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single short sentence, front-loaded with the core intent and free of filler. Brevity is fine for a zero-argument tool, though the sentence is so terse that it borders on under-specification.

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

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

No annotations, no output schema, and no parameters means the description is the only source of context, and it says nothing about the shape of the result, empty-state behavior, or how this differs from the other holdings/positions tools. For a tool an agent will call to reconcile portfolio data, that is insufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The absence of parameters is also consistent with the description, which implies a no-argument account-scoped read.

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

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

States a specific verb and resource ("Get mutual fund holdings"), which is enough to separate it from generic get_holdings or get_positions at a glance. It doesn't explicitly contrast itself with those siblings or clarify scope (folio vs demat, current vs historical), so it stops short of 5.

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

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

There is no when-to-use guidance, no prerequisite or auth note, and no pointer to alternatives such as get_holdings or get_positions. The agent is left to infer selection from the tool name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the default behavior of listing today's orders when order_id is omitted, but it does not mention permissions, pagination, or return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences with no wasted words. The core action is front-loaded and the parameter guidance follows immediately.

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

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

For a simple read tool with one optional parameter and no output schema, the description covers the essential calling behavior. It could be slightly more complete by clarifying what happens when order_id is supplied, but it is adequate.

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

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

Schema coverage is 0%, so the description must compensate. It does so by explaining that omitting order_id returns all of today's orders, implying that providing order_id fetches a specific order. It does not document order_id format, but the core semantics are clear.

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

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

The description states a specific verb and resource: 'Get mutual fund orders.' The 'mutual fund' qualifier distinguishes it from the sibling get_orders tool, though it does not explicitly name that sibling.

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

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

It gives clear guidance for the optional parameter: omit order_id to list all of today's orders. However, it does not explain when to use this tool instead of get_orders or other order-related siblings.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that omitting sip_id returns all active SIPs, but does not describe whether inactive SIPs can be retrieved, what happens for an invalid sip_id, pagination, or return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences with no redundant content. The core purpose and the optional-parameter behavior are front-loaded.

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

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

For a simple read tool with one optional parameter and no output schema, the description covers the essential action and listing behavior. A little more context on return scope or invalid-ID handling would make it complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the key semantic of omitting sip_id, but does not explicitly state that providing sip_id retrieves a specific SIP or describe the expected identifier format.

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

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

The description uses a specific verb ("Get") and resource ("mutual fund SIPs") and explains the listing behavior when sip_id is omitted. It does not explicitly name the sibling tools that modify, cancel, or place SIPs, so it is clear but not fully differentiated.

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

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

It gives an invocation hint: omit sip_id to list all active SIPs. However, it does not explicitly say when to use this tool versus modify_mf_sip, cancel_mf_sip, or place_mf_sip, leaving that routing to inference from the tool name.

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

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

No annotations exist, so the description carries the full load; it does disclose the key access prerequisite (paid Kite Connect subscription with market data, not free Personal tier) and the read-only nature implied by "Get." It omits real-time vs delayed data, rate limits, and any failure behavior when the subscription is missing, which are the remaining behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, no waste: the capability and its scope come first, and the access prerequisite follows. Every sentence earns its place.

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

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

For a one-parameter read with no output schema, the description covers what is returned (OHLC fields) and the access gate. It would be stronger if it clarified snapshot freshness/real-time semantics or how it differs from get_quote and get_ltp, which is the main ambiguity an agent faces.

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

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

Schema coverage is 100% — the single `instruments` parameter already documents the "EXCHANGE:TRADINGSYMBOL" format with examples and the maxItems/minItems bounds. The description's "up to 50 instruments" merely restates the schema's maxItems, adding no new semantics.

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

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

States a specific verb and resource ("Get OHLC ... snapshot") plus the scope limit of 50 instruments, so an agent knows exactly what data comes back. It implicitly contrasts with get_historical_data via "snapshot," but never names a sibling to differentiate against quote/LTP tools.

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

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

Usage is only implied by the word "snapshot" and the subscription prerequisite; there is no explicit statement of when to prefer this over get_ltp, get_quote, or get_historical_data, all of which return overlapping price data. The one concrete gate it does give — paid market-data subscription required — is genuinely useful for deciding whether the call will succeed.

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

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

No annotations are provided, so the description carries the full burden, yet it only implies read-only access through the verb 'Get'. It says nothing about permissions, whether history is paginated or time-ordered, how far back it goes, or what happens if the order ID is invalid.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One short, front-loaded sentence with no filler. It is efficient, though the brevity contributes to the missing detail noted in other dimensions.

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

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

With no annotations, no output schema, and an undocumented parameter, the description leaves key questions open: what the returned history entries contain, their ordering, and whether pagination applies. For a history-retrieval tool this is a substantial gap.

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

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

Schema description coverage is 0% for the single required parameter, and the description only implies that order_id identifies 'a single order'. It adds no format, source, or validity detail that would help an agent construct or validate the ID.

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

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

The description gives a specific verb and resource ('Get the full status history of a single order') and implicitly separates this tool from list-style siblings like get_orders and get_order_trades by emphasizing one order's status timeline. It never names those siblings explicitly, so an agent must infer the boundary rather than read it.

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

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

Usage is only implied: you call it when you want the status progression of a specific order. There is no guidance on when to prefer it over get_orders or get_order_trades, and no prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full load; it does disclose the key behavioral trait that only today's orders are returned and that status is included. It omits sorting, pagination, and what happens if no orders exist, which matters for a list-style read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single front-loaded sentence with the scope and return content packed into the parenthetical. No wasted words.

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

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

For a zero-parameter read tool with no output schema, the description covers what is returned and the time scope, which is enough to call it correctly. Only minor gaps remain around result size, pagination, and empty-result behavior.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description correctly implies a no-argument call that returns the whole day's book.

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

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

States a specific verb ('Get') and resource ('the day's order book') and scopes it to today's orders with their status. It implicitly distinguishes itself from get_order_history and get_mf_orders, but never names those siblings explicitly.

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

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

The phrase 'the day's order book' implies the intended use case (checking today's activity), but there is no explicit when-to-use guidance, no exclusion criteria, and no pointer to get_order_history or get_mf_orders as alternatives for other scopes.

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

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

With no annotations, the description carries the full behavioral burden and does little: it implies a read via 'get' and clarifies 'trades' as 'fills', but says nothing about pagination, whether empty results occur for unfilled orders, historical vs live, or what a fill record contains. Usable but thin for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One short sentence, front-loaded with the verb and the key scoping constraint. Nothing is wasted and nothing important is buried.

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

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

The tool is simple (one required param, no nested objects, no output schema), so an agent can call it correctly. Still missing is any hint about result shape, empty-result behavior, or how it relates to the sibling trade/order-history tools.

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

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

Schema coverage is 0%, so the description must compensate for the single undocumented order_id. Saying the trades are 'generated by a single order' does establish that order_id is an order identifier, not a trade or instrument ID, which is meaningful; but no format, exchange-prefix, or validity rules are given.

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

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

The description gives a specific verb (get) and resource (trades/fills) and narrows the scope to a single order, which separates it from the broader get_trades sibling. It does not name get_trades or get_order_history explicitly, so the differentiation is implied 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.

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

There is no explicit statement of when to use this over get_trades or get_order_history; the agent must infer that this tool is the per-order variant. No prerequisites (e.g. order must exist or be filled) are mentioned.

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

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

With no annotations, the description carries the full behavioral burden. The word 'Get' implies a read-only operation, and the parenthetical '(intraday + carry-forward F&O etc)' adds useful context about what position types are returned. However, it omits any mention of permissions, rate limits, or response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single, front-loaded sentence with no wasted words. The only minor weakness is the vague trailing 'etc', which slightly reduces precision.

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

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

For a simple zero-parameter read tool this is adequate, but it is not fully complete: it lacks any indication of return shape, and it does not distinguish the tool from closely related siblings like get_holdings or get_margins. Without an output schema, a little more detail would help.

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

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

The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter semantics, and it appropriately stays focused on the data retrieved.

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

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

The description names a specific verb and resource ('Get ... positions') and clarifies the scope as current-day plus net/carry-forward positions, which helps distinguish it from related tools like get_holdings. It does not explicitly differentiate itself from sibling tools such as get_holdings or convert_position, so it falls short of a 5.

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

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

Usage is implied by the phrase 'Get current day's and net trading positions', suggesting the tool should be used when position data is needed. However, it gives no explicit guidance on when to use this versus get_holdings, get_margins, or convert_position, and no exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description says nothing about session/auth requirements, whether the call is idempotent, or what the profile actually contains (user id, broker, enabled exchanges/products), all of which matter for a zero-parameter account call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single front-loaded sentence that identifies the resource immediately, with no filler, hedging, or redundant restatement of the name. Nothing in it could be cut.

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

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

For a no-param, no-annotation, no-output-schema tool, the definition is minimally adequate: an agent knows what it fetches but not what fields come back or what auth state is needed. A brief note on the returned profile shape would close the gap that annotations and the output schema would otherwise fill.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no schema surface for the description to compensate for. The description does correctly signal that no user identifier is accepted by specifying the 'logged-in' user.

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

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

The description names a specific verb ('Get') and resource ('profile') and scopes it to the authenticated Kite user via 'logged-in'. No sibling tool returns account/profile data, so it is distinguishable in practice, though the description never explicitly contrasts itself with siblings like get_holdings or get_margins.

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

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

There is no statement of when to call this tool versus alternatives, no prerequisites, and no note that it must be called after authentication. The 'logged-in' phrase only weakly implies that a valid session is required; everything else is left to inference.

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

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

No annotations exist, so the description carries the burden. It usefully discloses a hard prerequisite (paid Kite Connect subscription with market data access, excluded from free Personal tier) and the batch cap. It says nothing about read-only nature, rate limits, or failure behavior for invalid/expired instruments, which matter for this endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, both earning their place: the first defines scope and payload, the second flags the access prerequisite. Front-loaded with the value proposition before the caveat.

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

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

For a single-parameter read tool with no output schema, the description covers what data comes back, the batch limit, and the subscription gate — the key thing an agent must check before calling. Only rate-limit and error semantics are absent.

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

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

Schema description coverage is 100% and the schema already documents the instruments array, its format ("EXCHANGE:TRADINGSYMBOL"), and the 50-item maximum. The description restates the cap but adds no new meaning about format or constraints, so baseline 3 applies.

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

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

States a specific verb+resource ('Get full market quote') and enumerates the returned fields (price, depth, OHLC, volume), which implicitly separates it from siblings like get_ltp and get_ohlc. It stops short of naming those alternatives, so the differentiation is inferred rather than explicit.

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

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

Usage is only implied: the 'full quote' framing plus the field list suggests this is the richer alternative to get_ltp/get_ohlc, but no when-to-use or when-not-to-use guidance is given. With 35 siblings, an explicit contrast would have been valuable.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the temporal scope ('for the day') and aggregation scope ('across all orders'), but does not clarify read-only behavior, pagination, rate limits, permissions, or the response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

A single efficient sentence with no wasted language. The scope constraints are front-loaded and immediately useful.

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

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

For a zero-parameter list tool, the description gives the essential scope. It is somewhat incomplete in not describing return shape or any limits, but the tool's simplicity and lack of parameters reduce the need for more detail.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. Baseline for zero parameters is 4, and the description does not misrepresent any inputs.

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

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

The description states a specific verb and resource ('Get all trades (fills)') plus scope ('for the day across all orders'). This distinguishes it from the sibling 'get_order_trades' by clarifying that it is not order-specific, though it does not name that sibling explicitly.

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

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

Usage is implied by the scope: use it to retrieve the day's fills across all orders. However, there is no explicit guidance on when to prefer it over 'get_order_trades' or other trade-related tools, and no exclusions or prerequisites are stated.

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

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

With zero annotations, the description carries the full burden, and it does disclose a genuine behavioral constraint: a paid Kite Connect subscription with market data access is required and the free Personal tier is excluded. That entitlement caveat is valuable. However, it says nothing about the response shape (per-instrument min/max bounds), error behavior for ineligible instruments, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two tight sentences: purpose first, entitlement caveat second, zero filler. The only marginal content is the explicit 'not included in the free Personal tier' clarification, which is nonetheless actionable for an agent diagnosing a failure.

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

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

For a simple two-parameter tool with no output schema, the description should at minimum indicate what comes back (a min/max trigger price per requested instrument) and that the call presupposes Cover Order eligibility. Purpose and entitlement are covered; the return contract and the effect of transaction_type are not.

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

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

Schema coverage is 50%: `instruments` is documented in the schema, but `transaction_type` has only the enum with no explanation of how BUY vs SELL changes the trigger range — a non-obvious semantic. The description never mentions either parameter or the 50-item array limit, so it does not compensate for the coverage gap.

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

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

States a specific verb and resource — the valid stop-loss trigger price range — scoped to Cover Order instruments. That is far more informative than the bare name, but it doesn't position the tool against related siblings such as calculate_order_margins or place_order (e.g., 'call this before placing a CO order').

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

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

Usage is only implied: the agent can infer this is validation data needed when constructing a Cover Order, but the description never says when to call it, whether it is a prerequisite to place_order, or what to do if the instrument isn't CO-eligible. No alternatives are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the tool defaults to dry-run unless KITE_MCP_ENABLE_TRADING=true, which is important safety context, but it omits permissions, reversibility, mutation semantics, and what dry-run actually returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is two short sentences, front-loads the purpose, and includes the critical dry-run caveat. Every sentence earns its place.

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

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

For a seven-parameter, all-required GTT mutation tool with no annotations and no output schema, the description is too thin. It explains the dry-run gate but does not clarify required order structure, trigger semantics, or expected results.

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

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

Schema description coverage is only 43%, covering last_price, trigger_type, and trigger_values. The description adds no parameter semantics for trigger_id, tradingsymbol, exchange, or the nested orders structure, leaving several required fields unexplained beyond schema types and enums.

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

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

The description clearly states a specific verb and resource: "Modify an existing GTT order." This distinguishes it from sibling tools such as place_gtt, delete_gtt, and get_gtt, though it does not explicitly name alternatives.

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

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

The description does not explain when to use modify_gtt versus place_gtt, delete_gtt, or modify_order. The dry-run note is a behavioral condition, not usage guidance or an alternative-selection rule.

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

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

With no annotations at all, the description does carry one genuinely important disclosure: the call is a dry-run unless KITE_MCP_ENABLE_TRADING=true, so the agent knows a mutation will not actually take effect by default. It says nothing about partial-update semantics (are omitted fields preserved?), validation failures, or what the dry-run response contains — big gaps for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two compact sentences with the operation front-loaded and the safety gate immediately after. Nothing is wasted or buried.

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

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

The dry-run gate is the single most important piece of context and it is present, but for a five-parameter mutation tool with no annotations, no output schema, and no parameter documentation, an agent still cannot tell what happens to unspecified fields or how failures surface.

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

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

Schema description coverage is 0% and all five parameters are bare. The description only faintly maps 'pause or unpause' onto the status enum; the meaning of frequency, instalments, and instalment_day, and whether they are optional partial updates, is never addressed.

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

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

Uses specific verbs (modify, pause, unpause) on a named resource (an existing SIP), which cleanly separates it from place_mf_sip and cancel_mf_sip. It does not explicitly name the siblings it is not, so it stops short of a 5.

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

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

There is no guidance on when to choose modify_mf_sip over cancel_mf_sip plus place_mf_sip, nor on prerequisites such as the SIP having to exist and be in a modifiable state. Usage is only implied by the verb list.

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

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

With no annotations, the description carries the behavioral burden and does disclose the highest-risk trait: a dry-run default unless an environment flag enables real trading. It omits other behaviors such as what happens to unspecified fields, partial-modification semantics, and error/permission conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two sentences, both earning their place: the first names the operation and modifiable fields, the second front-loads the critical dry-run safety gate. No filler.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the safety gate and field enumeration but is silent on how the two required parameters (variety, order_id) are used and how partial modifications are applied. Adequate but with clear gaps.

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

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

Schema description coverage is only 13%, so the description must compensate. It enumerates six modifiable fields (price, quantity, order_type, trigger_price, validity, disclosed_quantity) but leaves 'variety' and 'order_id' with no semantic explanation, and adds no format, unit, or mutual-exclusion details.

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

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

States a specific verb and resource ('Modify a pending order') plus the exact set of modifiable fields, which distinguishes it from place_order/cancel_order siblings. It does not explicitly name a sibling alternative, so it stops short of a 5.

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

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

Gives a strong usage condition: only pending orders, and a dry-run default gated by KITE_MCP_ENABLE_TRADING=true. It stops short of explicit when-not guidance (e.g. for executed or cancelled orders) or naming alternatives.

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

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

With no annotations, the description carries the full burden and discloses the single most important behavior: it is a dry-run unless KITE_MCP_ENABLE_TRADING=true, so the agent knows the call may not place a real order. It still omits what a dry-run returns, whether validation errors surface, and the margin/permission requirements, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences, front-loaded with the action and immediately followed by the safety caveat. The parenthetical example costs a few words but earns its place by grounding the term 'GTT'.

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

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

For a mutation tool with no annotations and no output schema, the dry-run disclosure covers the safety gap, but the description leaves the agent without any model of the orders array or what success/failure looks like. Adequate to avoid a dangerous call, not adequate to call it correctly on the first try.

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

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

Schema coverage is only 50%, so the description should compensate but gives no parameter guidance at all. The relationship between trigger_type values and the orders array (e.g. that 'two-leg' OCO needs matching trigger pairs and up to two child orders) is undocumented in both places.

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

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

Specific verb plus resource ('Create a GTT order') with an illustrative example (standing stop-loss/target) that separates it from a plain place_order. It stops short of naming sibling tools like modify_gtt or place_order, but the GTT concept is distinctive enough that an agent can tell them apart.

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

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

The example implies the use case (standing stop-loss or target) and the dry-run condition gives a key operational gate, but there is no explicit when-to-use guidance versus place_order/modify_gtt, and no statement of prerequisites such as margin or enabled GTT on the account.

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

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

With no annotations, the description carries the full load and does disclose the most important trait: the call is a dry run unless KITE_MCP_ENABLE_TRADING=true, which tells the agent this is not an always-live mutation. It stops short of covering permission/auth requirements, irreversibility of a live order, or what a dry run returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences with zero waste; the buy/sell distinction and the trading-enable gate are both front-loaded and immediately actionable.

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

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

For an unannotated mutation tool with no output schema, the dry-run gate is the crucial piece and it is present. However, nothing is said about what happens on a live order, failure modes, or the purpose of 'tag', leaving the agent with clear gaps before invoking it in production.

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

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

Schema coverage is 60%, and the amount-for-BUY / quantity-for-SELL mapping in the description largely restates the schema's own parameter descriptions. The 'tag' parameter is undocumented in both places, so the description does not compensate for the remaining gap.

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

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

States a specific verb and resource (place a mutual fund buy or sell order) and encodes the amount-vs-quantity branch, which cleanly separates it from the equity place_order and the recurring-place_mf_sip siblings.

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

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

'Mutual fund' implies the context in which this is the right tool, but the description never explicitly says to use it instead of place_order or place_mf_sip, and gives no preconditions such as having an available balance or an ISIN in hand.

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

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

With no annotations, the description carries the full burden, and it does disclose a genuinely important non-obvious trait: execution is a dry-run unless KITE_MCP_ENABLE_TRADING=true. However, it omits what a dry-run returns, whether margin must be available (calculate_order_margins exists as a sibling), and whether the SIP auto-activates after creation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short sentences, purpose front-loaded followed by the execution-mode caveat. Nothing wasted and nothing buried.

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

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

For a mutation tool with no annotations and no output schema, the dry-run disclosure is essential but insufficient: return shape of a dry-run, margin prerequisites, and post-creation state are all unaddressed for a 7-parameter trading tool.

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

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

Schema coverage is only 57%, and the description adds no parameter meaning at all. Parameters like tag, amount, and frequency are left to the schema alone, and instalment_day/initial_amount semantics come solely from the schema descriptions; the description does nothing to compensate for the coverage gap.

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

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

States a specific verb+resource ('Start a mutual fund SIP') and glosses the acronym as 'recurring investment', which makes the purpose unambiguous. The verb 'Start' contrasts implicitly with modify_mf_sip and cancel_mf_sip siblings, but no sibling is named explicitly.

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

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

Usage context is implied by 'Start a ... SIP', but there is no explicit when-to-use guidance, no pointer to modify_mf_sip/cancel_mf_sip for changes, and no mention of prerequisites such as funds or margin checks. The dry-run note is a useful guardrail but is behavioral rather than usage-guiding.

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

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

With no annotations, the description does the essential job: it discloses that this sends a real order to the exchange with real money and that the default behavior is a dry-run preview gated by an environment variable. That is exactly the safety-critical context an agent needs before calling. What it does not cover is what happens on rejection, whether margin is validated, or the response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Two short clauses with no filler. The most important fact, that this spends real money unless gated by an environment variable, is front-loaded in the first sentence.

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

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

For a 13-parameter, unannotated, no-output-schema trading tool, the description covers the critical safety gate but leaves the bulk of parameter usage, conditional field requirements, and failure behavior unaddressed. It is adequate for deciding whether it is safe to call, not for calling it correctly.

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

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

There are 13 parameters and only 31% schema description coverage, yet the description adds no parameter semantics at all. It says nothing about the conditional requirements the schema only partially documents, such as price for LIMIT/SL and trigger_price for SL/SL-M, or the meaning of the variety and product values.

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

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

"Place a new order on Kite" gives a specific verb and resource, and the description makes clear it is a live order-entry path. It does not explicitly distinguish itself from siblings like place_gtt, place_mf_order, or place_mf_sip, so the agent must infer that "order" means a regular exchange order rather than a GTT or mutual-fund order.

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

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

The description implies the operative condition: a dry-run preview by default, a real order only when KITE_MCP_ENABLE_TRADING=true. However, there is no guidance on when to reach for this tool over place_gtt or place_mf_order, and no prerequisites such as checking margins or holdings first.

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

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

With no annotations, the description carries the full burden and does well: it discloses case-insensitive matching, that the master list is tens of thousands of rows so results are capped, and that the endpoint is free on all Kite Connect tiers. It stops short of stating the actual cap/default limit or the authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Four short sentences, front-loaded with the action and matching semantics, then purpose, then the practical narrowing advice. Nothing is redundant; every sentence adds information.

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

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

Covers what the tool returns conceptually (instrument_token / tradingsymbol), why results may be truncated, and how to narrow. With no output schema, a brief note on returned fields or the result cap value would make it fully complete, but nothing essential for correct invocation is missing.

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

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

Schema coverage is 75% and documents query, exchange and instrument_type well; the description reinforces exchange/query as the narrowing levers and explains why (capped results). The limit parameter has no description in either place, which is the only semantic gap.

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

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

States a specific verb (search) and resource (instrument master list) with the matching mode (symbol or name substring, case-insensitive). It does not explicitly name the sibling search_mf_instruments, so an agent must infer that mutual funds are handled elsewhere, but the scope is otherwise unambiguous.

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

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

Explicitly says to use it to obtain instrument_token / exact tradingsymbol values for quote, historical-data and tick-watching tools, which gives clear downstream context. It also advises narrowing with exchange and query. The only gap is not naming search_mf_instruments as the alternative for fund instruments.

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

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

No annotations are provided, so the description carries the full burden. 'Search' implies a safe read, but nothing is said about result ordering, default result count, pagination, or truncation behavior, which matter for a lookup tool with a limit parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

One compact sentence with the searchable fields and an example front-loaded. No wasted text.

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

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

For a simple two-param read lookup with no output schema, the description covers the primary input but omits the limit behavior and any hint of what the results look like. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the query parameter well (ISIN or name substring) and gives a concrete example, but the limit parameter is never mentioned in the description or schema, leaving it undocumented.

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

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

States a specific verb ('Search') and resource ('mutual fund instrument list') plus the two lookup keys (ISIN, name substring). An agent can tell it apart from the generic search_instruments by the 'mf' scoping, though the description never explicitly contrasts the two siblings.

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

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

No when-to-use or when-not-to-use guidance, and no reference to the sibling search_instruments which covers non-MF instruments. The usage context is only implied by the tool name and the 'mutual fund' phrasing.

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

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

With no annotations, the description carries the burden well: it discloses the live WebSocket mechanism, a bounded collection window, the returned payload (latest price plus full history), and the paid market-data subscription requirement. It omits connection lifecycle, error, and rate-limit details, so it is not fully complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

Three focused sentences, front-loaded with what happens and then prerequisites. Every sentence contributes useful information with no wasted text.

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

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

For a streaming tool with no annotations or output schema and 0% schema descriptions, it covers the return payload and subscription prerequisite but leaves critical parameter semantics and some operational behavior unspecified. It is enough to start, but not fully complete.

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

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

Schema coverage is 0%, so the description must explain all 3 parameters. It explains instrument_token via search_instruments but says nothing about mode's ltp/quote/full enum or duration_seconds' range and default; 'short window' is too vague.

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

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

The description states a specific verb and resource: open a live WebSocket connection to Kite and collect ticks for a short window, returning latest price plus history. This clearly distinguishes it from snapshot siblings like get_ltp/get_quote and from get_historical_data.

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

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

It gives a concrete prerequisite (use search_instruments first) and a paid subscription requirement, establishing clear context. It does not explicitly name when to use this rather than get_ltp/get_quote, but the live-window framing implies the alternative.

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