Kite MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between get_orders, get_order_history, and get_order_trades, which could cause confusion in selecting the right one for order-related queries. Additionally, get_ltp and get_quotes both provide price data, though they differ in scope (latest trading prices vs. market data quotes).
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as cancel_order, get_holdings, and place_gtt_order. There are no deviations in naming conventions, making the set predictable and easy to parse.
Tool Count3/5
With 24 tools, the count is borderline high for a trading API server, potentially overwhelming for agents. While it covers many functionalities, it might benefit from consolidation or better scoping to reduce complexity.
Completeness5/5
The tool set provides comprehensive coverage for a trading domain, including authentication (generate_session, login), account management (list_accounts, get_profile), order handling (place, modify, cancel), market data (get_historical_data, get_quotes), and holdings/positions. No obvious gaps are present for core trading workflows.
Average 3/5 across 24 of 24 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Get margins' doesn't indicate whether this is a read-only operation, whether it requires authentication, what format the data returns in, whether there are rate limits, or any other behavioral characteristics. The description is essentially non-functional for behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this is under-specification rather than effective conciseness. The description doesn't contain enough information to be useful, so its brevity is a liability. There's no structure or front-loading of important information - it's just a minimal restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial data tool with no annotations and no output schema, the description 'Get margins' is completely inadequate. It doesn't explain what margins are in this context, what data format to expect, when this tool should be used versus other financial data tools, or any operational considerations. The context signals show this is a simple tool with one optional parameter, but the description fails to provide even basic contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for its single parameter (client_id), so the baseline is 3. The description doesn't mention parameters at all, which is acceptable given the schema's complete coverage. However, since there's only one optional parameter, the description could have mentioned the account context but isn't penalized for not doing so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get margins' is a tautology that merely restates the tool name without adding any meaningful context. It doesn't specify what type of margins (trading, profit, formatting?), what resource they're associated with, or what the operation actually does. While it uses a clear verb ('Get'), the object 'margins' is too vague to understand the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. Given the sibling tools include many financial/trading operations (get_holdings, get_positions, get_quotes, etc.), there's no indication of when 'margins' would be relevant versus other financial data tools. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the action ('Place an order') without mentioning any behavioral traits. It doesn't indicate whether this is a read-only or destructive operation, what permissions are required, whether it's idempotent, what happens on failure, or any rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise with just two words. While this represents under-specification rather than ideal conciseness, it contains zero wasted words and is perfectly front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial trading tool with 15 parameters, 7 required parameters, no annotations, and no output schema, the two-word description is completely inadequate. It doesn't explain what happens after order placement, what the response contains, error conditions, or any context about the trading system it interacts with.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds no parameter information beyond what's already documented in the comprehensive schema, which includes detailed descriptions for all 15 parameters including enums, defaults, and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Place an order' is a tautology that merely restates the tool name without adding specificity. It doesn't explain what type of order (financial/trading order), what resource it acts upon, or how it differs from sibling tools like modify_order or cancel_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With sibling tools like modify_order, cancel_order, and get_orders available, there's no indication of when this creation tool is appropriate versus modification or query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions pagination support, which is useful behavioral context. However, it doesn't disclose important traits like rate limits, authentication requirements, response format, error conditions, or whether this is a read-only operation. For a search tool with no annotation coverage, this leaves significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two sentences. The first sentence states the core function, and the second adds important behavioral context about pagination. There's no wasted language, though some might argue it's too brief given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'instruments' are, what fields are searched by default, how results are ranked, what the response structure looks like, or any error handling. The pagination mention is helpful but doesn't compensate for other missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation via the schema alone, with no additional value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool searches instruments, which is a clear verb+resource combination. However, it doesn't distinguish this search functionality from other potential search tools or explain what 'instruments' means in this context (financial instruments, musical instruments, etc.). The purpose is understandable but lacks specificity and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions pagination support but provides no guidance on when to use this tool versus alternatives. With 22 sibling tools including various data retrieval functions (get_historical_data, get_quotes, get_orders), there's no indication of when search_instruments is the appropriate choice versus other data access methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't reveal if this is a read-only operation, requires authentication, has rate limits, returns paginated data, or what the output format might be. This is a significant gap for a tool with potential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a tool fetching history, which implies temporal data), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'history' includes, return values, or behavioral aspects, leaving gaps that could hinder correct tool invocation by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 100% coverage and fully documents the single parameter 'order_id'. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get order history for a specific order' clearly states the verb ('Get') and resource ('order history'), but it's vague about what 'history' entails (e.g., status changes, timestamps) and doesn't distinguish it from sibling tools like 'get_orders' (which might list orders) or 'get_order_trades' (which might focus on trade details). It avoids tautology by not just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an order ID), exclusions, or comparisons to siblings like 'get_orders' or 'get_order_trades', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Modify an existing order' implies a write/mutation operation, but it doesn't disclose important behavioral traits like authentication requirements, rate limits, whether modifications are reversible, what happens on failure, or typical response patterns. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex order modification tool with 8 parameters (including conditional requirements like price for LIMIT orders) and no annotations or output schema, the description is inadequate. It doesn't explain what successful modification entails, what values can be changed, or how the system responds. The agent must rely entirely on the schema for operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly with descriptions, enums, defaults, and constraints. The description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Modify an existing order' which clearly indicates the verb (modify) and resource (order). However, it doesn't differentiate from sibling tools like 'cancel_order' or 'modify_gtt_order', leaving ambiguity about when to use this specific modification tool versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'cancel_order' or 'modify_gtt_order'. The description doesn't mention prerequisites, constraints, or typical scenarios for order modification, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Cancel') but doesn't explain effects (e.g., irreversible, refunds, status changes), permissions needed, or error conditions. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 description is inadequate. It lacks details on behavior, outcomes, error handling, and how it differs from siblings. Given the complexity of order cancellation, more context is needed to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('variety' with enum and 'order_id'). The description adds no additional meaning beyond implying these are needed to identify the order, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel') and target ('an existing order'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'delete_gtt_order' or 'modify_order', which also deal with order modifications, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'modify_order' or 'delete_gtt_order', nor does it mention prerequisites like order status or authentication. It's a basic statement with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a deletion, implying a destructive operation, but doesn't clarify if this is permanent, requires specific permissions, has side effects, or what the response looks like. This is inadequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that states the tool's purpose without any unnecessary words. It's front-loaded and efficiently communicates the core function, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no annotations and no output schema, the description is insufficient. It doesn't explain what happens upon deletion (e.g., confirmation, error handling), nor does it cover behavioral aspects like permissions or irreversible effects, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'trigger_id' clearly documented as 'The ID of the GTT order to delete'. The description doesn't add any additional meaning beyond this, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the target resource ('an existing GTT order'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'cancel_order' or 'modify_gtt_order', which could also involve order modifications, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'cancel_order' or 'modify_gtt_order', nor does it mention prerequisites (e.g., needing an existing GTT order ID). It's a basic statement of function without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It states 'Get historical price data' but doesn't mention if this is a read-only operation, potential rate limits, authentication needs, data format, or pagination. For a tool with 6 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return values, data structure, or behavioral aspects like error handling. For a data retrieval tool with multiple parameters, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters well-documented in the input schema (e.g., date formats, interval enums, defaults). The description adds no additional parameter semantics beyond the schema, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'historical price data for an instrument', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_ohlc' or 'get_quotes', which might also retrieve price-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_ohlc' or 'get_quotes'. It lacks context about prerequisites (e.g., needing an instrument token from 'search_instruments') or exclusions, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'returns the latest price' but doesn't cover aspects like rate limits, authentication needs, error handling, or whether it's a read-only operation. This leaves significant gaps for a tool that interacts with financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any unnecessary words. It's front-loaded and appropriately sized for its purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits like whether it requires authentication or has usage limits. For a financial data tool with potential complexity, this leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'instruments' parameter well-documented in the schema itself (including examples and format). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'latest trading prices for a list of instruments', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_quotes' or 'get_ohlc', which might offer similar price-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_quotes' or 'get_historical_data'. It lacks context on prerequisites, timing, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It states what the tool does but lacks details on permissions, rate limits, response format, or any side effects. For a data retrieval tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the OHLC data includes (e.g., timeframes, aggregation), how results are returned, or any limitations. For a financial data tool with potential complexity, more context is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'instruments' parameter well-documented in the schema, including an example. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline for adequate coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'OHLC data for a list of instruments', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from similar siblings like 'get_historical_data' or 'get_quotes', which might also provide financial data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_historical_data' and 'get_quotes' that might overlap in functionality, there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination support, which is useful, but doesn't address important behavioral aspects like whether this requires authentication, rate limits, what format orders are returned in, or whether this is a real-time or historical view of orders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with two sentences that each serve a purpose: stating the core function and mentioning pagination support. It's front-loaded with the primary purpose and avoids unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'orders' means in this context, what data fields are returned, whether this includes open/closed/both orders, or how the pagination metadata is structured. Given the complexity implied by having sibling order-related tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters ('limit' and 'from') well-documented in the schema. The description adds minimal value beyond what's already in the schema, only mentioning pagination support without providing additional parameter context or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('orders'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_order_history' or 'get_order_trades', which appear to be related order retrieval functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_order_history' or 'get_order_trades'. It mentions pagination support but doesn't explain when pagination should be used or what distinguishes this tool from other order-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It states the tool 'Get trades' but doesn't describe what 'trades' entails (e.g., format, pagination, error handling), whether it's read-only or has side effects, or any constraints like rate limits or authentication needs. This leaves significant gaps for a tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a read operation with one parameter) and the absence of annotations and output schema, the description is incomplete. It doesn't explain what 'trades' returns, potential errors, or behavioral traits, leaving the agent with insufficient context to use the tool effectively beyond the basic parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'order_id' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or usage context. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get trades') and the target resource ('for a specific order'), which is a specific verb+resource combination. However, it doesn't distinguish this tool from the sibling 'get_trades' tool, which appears to be a more general trades retrieval tool, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when-not scenarios or explicit alternatives like 'get_trades' (a sibling tool) or 'get_order_history' (another sibling that might overlap). The context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination support, which is useful, but fails to cover critical aspects such as whether this is a read-only operation, potential rate limits, authentication requirements, or what the response format looks like. For a tool with financial data access, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly convey the core functionality and a key feature (pagination). Every word serves a purpose, and it's front-loaded with the main action, making it efficient and easy to parse without any wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data tools, no annotations, and no output schema, the description is insufficient. It lacks details on return values, error handling, security implications, and how it differs from siblings. While concise, it doesn't provide enough context for an agent to use the tool effectively in a real-world scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema fully documents the three parameters (client_id, limit, from). The description adds no additional semantic information about these parameters beyond what's in the schema, such as usage examples or constraints. This meets the baseline for high schema coverage but doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('current positions'), making the tool's purpose evident. It distinguishes itself from siblings like 'get_holdings' by focusing specifically on positions rather than holdings or other financial data. However, it doesn't explicitly differentiate from all similar tools like 'get_orders' or 'get_trades', which slightly limits its specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Supports pagination for large datasets,' which implies usage in data-heavy contexts but doesn't provide explicit guidance on when to use this tool versus alternatives. No context, exclusions, or comparisons to siblings like 'get_holdings' or 'get_orders' are given, leaving the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Modify' implies a mutation operation, but the description doesn't disclose critical behavioral traits: whether this requires specific permissions, if modifications are reversible, what happens to partially filled orders, rate limits, error conditions, or confirmation requirements. For a financial trading tool with 15 parameters, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a tool with a clear name and comprehensive schema documentation. Every word earns its place by conveying the essential action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (financial trading tool with 15 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain what 'modify' entails operationally, what values can be changed, whether modifications affect order status, what the response looks like, or error scenarios. For a mutation tool in a sensitive domain with many sibling tools, this minimal description leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 15 parameters thoroughly with descriptions and enums. The description adds no parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('modify') and resource ('existing GTT order'), making the purpose immediately understandable. It distinguishes this tool from 'place_gtt_order' (creation) and 'delete_gtt_order' (deletion), though it doesn't explicitly contrast with 'modify_order' (which likely modifies regular orders). The description is specific but could be more precise about what distinguishes GTT order modification from regular order modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing GTT order ID), when modification is allowed versus when cancellation might be needed, or how this differs from 'modify_order' for non-GTT orders. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool places an order but doesn't mention whether this is a read-only or destructive operation, what permissions are required, potential side effects, rate limits, or what the response looks like. For a financial order placement tool, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does without any wasted words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial order placement tool with 15 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a GTT order is, how it differs from regular orders, what happens after placement, error conditions, or return values. The agent would struggle to use this tool correctly without significant external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 15 parameters thoroughly with descriptions and enums. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Place') and resource ('GTT order'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'place_order' or 'modify_gtt_order', which would require more specific context about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'place_order' or 'modify_gtt_order'. There's no mention of prerequisites, context, or comparison with sibling tools, leaving the agent to infer usage 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.
Behavior2/5
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 mentions retrieving data, implying a read-only operation, but fails to disclose critical behavioral traits such as authentication requirements, rate limits, error handling, or response format. This is inadequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded: the first specifies the tool's purpose and data fields, and the second provides usage guidance. There's minimal redundancy, though it could be slightly more structured (e.g., separating data fields from usage).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It covers the basic purpose but omits essential context like authentication needs, rate limits, error scenarios, and response structure. For a tool with no structured data support, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the optional client_id parameter. The description adds no parameter-specific information beyond implying it retrieves user profile data, which aligns with the schema but doesn't provide additional semantics like usage examples or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieve') and resource ('user's profile information'), listing key data fields like user ID, name, email, and account details. It distinguishes from siblings by focusing on user profile data rather than orders, holdings, or market data, though it doesn't 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance with 'Use this to get basic user details,' suggesting it's for general user information. However, it lacks explicit when-to-use vs. when-not-to-use criteria or named alternatives (e.g., compared to list_accounts for account-level details), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by mentioning pagination support, which is useful context beyond the input schema. However, it lacks details on authentication needs, rate limits, or error handling, leaving gaps in behavioral understanding for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a key behavioral note on pagination. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a read tool with pagination. It covers the basic operation and pagination support but lacks details on return format, error cases, or integration with sibling tools, which could hinder agent effectiveness in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all three parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining interactions between parameters or default behaviors. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'mutual fund holdings', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_holdings' or 'get_positions', which might retrieve similar financial data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_holdings' or 'get_positions'. The description mentions pagination for large datasets, which is a usage hint but not explicit about context or exclusions. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the 500-instrument limit, included data fields (quantity, OHLC, Open Interest, bid/ask depth), and handling of missing data. However, it doesn't mention rate limits, authentication requirements, or response format details, leaving gaps for a tool with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality. All additional behavioral details are appropriately placed in the schema parameter description rather than cluttering the main description, making it well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides adequate basic context about what data is returned and instrument limits. However, it doesn't explain the return structure, error conditions, or how to interpret the 'complete market data snapshot,' leaving the agent to infer these from the parameter description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'instruments' thoroughly documented in the schema itself (including format examples, limits, and response behavior). The description adds no additional parameter information beyond what's already in the schema, meeting the baseline expectation but not providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get market data quotes') and resource ('for a list of instruments'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_ltp' or 'get_ohlc' which also retrieve market data, leaving some ambiguity about when to choose this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_ltp' (likely for last traded price) or 'get_ohlc' (for open-high-low-close data). The description mentions it returns 'complete market data snapshot' but doesn't clarify if this is the preferred tool for comprehensive quotes versus more specialized siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses pagination support, which is useful behavioral context beyond the basic read operation. However, it doesn't mention other important traits like rate limits, authentication requirements, or what format the trading history returns (e.g., structured data vs. raw).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, the second adds important behavioral context about pagination. No wasted words, well-structured, and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and pagination context but lacks details about authentication, rate limits, response format, or error handling. For a read operation with 2 parameters, this is minimally adequate but leaves gaps in understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (limit and from). The description mentions pagination support but doesn't add any semantic details about parameters beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'trading history', making the purpose unambiguous. However, it doesn't differentiate this tool from sibling tools like 'get_order_history' or 'get_order_trades', which also retrieve historical trading data, so it doesn't achieve full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_order_history' and 'get_order_trades' that might overlap in functionality, there's no indication of what distinguishes 'get_trades' from these other history-retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the authentication purpose but doesn't describe what the tool actually returns (session token, user data, etc.), error conditions, rate limits, or security implications. For an authentication tool with zero annotation coverage, this leaves significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each earn their place. The first sentence states the purpose, and the second provides crucial usage context. There's zero wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (critical for session generation), error handling, or how the generated session should be used. The description focuses only on the input side, leaving the output behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description mentions 'request_token' but doesn't add any additional semantic context beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate session') and the mechanism ('using request token'), specifying it's for completing authentication after user authorization. It distinguishes from most siblings by focusing on authentication rather than trading operations, though it doesn't explicitly differentiate from 'login' which might be related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'After user authorizes, call this with the request_token from the redirect URL to complete authentication.' This gives a specific sequence and prerequisite. However, it doesn't explicitly mention when NOT to use it or alternatives like the 'login' sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about pagination for large datasets, which is useful beyond the input schema. However, it lacks details on authentication needs, rate limits, error handling, or the format of returned data, leaving gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by additional context on pagination. It is efficient with zero waste, making it easy to parse and understand quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and pagination but lacks details on authentication, error cases, or return format, which are important for a tool that retrieves data. With no output schema, more guidance on responses would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema fully documents the 'limit' and 'from' parameters. The description mentions pagination support but does not add meaningful semantic details beyond what the schema provides, such as default behaviors or practical usage examples, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all active GTT orders'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_orders' or 'get_order_history', which might also retrieve order-related data, leaving some ambiguity about uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving active GTT orders, particularly with large datasets due to pagination support. It does not provide explicit guidance on when to use this tool versus alternatives like 'get_orders' or 'get_order_history', nor does it specify exclusions or prerequisites, leaving usage context somewhat inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about pagination support for large datasets, which isn't in the schema, but lacks details on authentication needs, rate limits, error handling, or response format. For a read operation with no annotations, this provides basic behavioral insight but misses important operational aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that are front-loaded and waste-free. The first sentence states the core purpose, and the second adds critical behavioral context about pagination. Every word earns its place, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and pagination behavior but lacks details on authentication, error cases, response structure, or sibling tool differentiation. For a read operation with full schema coverage, it's complete enough to be functional but leaves gaps in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no parameter-specific information beyond what's in the schema, such as clarifying 'client_id' usage or pagination mechanics. With high schema coverage, the baseline is 3, and the description doesn't compensate with additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'holdings for the current user', making the purpose unambiguous. It distinguishes from siblings like 'get_mf_holdings' by specifying it's for general holdings, though it doesn't explicitly contrast with other holding-related tools. The description is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving holdings with pagination support, but provides no explicit guidance on when to use this tool versus alternatives like 'get_mf_holdings' or 'get_positions'. It mentions pagination context but doesn't specify prerequisites, exclusions, or clear alternatives, leaving usage somewhat inferred rather than explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: returns an authorization link for user interaction, suggests markdown presentation for clickability, and mentions optional parameters if configured in env. However, it lacks details on error handling, rate limits, or what happens after authorization. For an authentication tool with no annotations, this is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized (three sentences) and front-loaded with core purpose. Every sentence adds value: first states purpose, second gives usage guidelines, third explains return behavior. It could be slightly more structured but is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters with full schema coverage, the description is reasonably complete. It covers purpose, usage context, and return behavior. For an authentication tool, it adequately guides an agent, though adding output details (e.g., session persistence) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional parameter semantics beyond implying 'client_id' identifies accounts (e.g., 'father', 'mother') and noting optionality for api_key/secret if env-configured, which is already in schema descriptions. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Login to Kite API for a specific account' with the verb 'login' and resource 'Kite API'. It distinguishes from siblings by being the only authentication tool, though it doesn't explicitly contrast with 'generate_session' which might be related. The purpose is specific but could better differentiate from potential alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'If you are starting off a new conversation call this tool before hand. Call this if you get a session error.' It clearly states when to use the tool (initial setup, session errors) and implies when not to use it (when already authenticated). This is comprehensive and actionable for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('account IDs and display names') and implies a read-only operation, but lacks details on behavioral traits like authentication requirements, rate limits, or error handling. The description does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by output details and usage guidance in the second. Both sentences earn their place by adding essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose, output, and usage context. However, it could improve by mentioning authentication needs or error scenarios, which are relevant for a system configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the tool's purpose and output, which compensates for the lack of parameters. It does not need to detail parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all available Kite accounts'), resource ('configured in the system'), and output ('account IDs and display names'). It distinguishes this from siblings like 'get_holdings' or 'get_profile' by focusing on account enumeration rather than financial data or user details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('to show available accounts to the user'), which implies this tool is for discovery or selection purposes. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as 'get_profile' for detailed account information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kite-mcp MCP server](https://glama.ai/mcp/servers/chandantherefore/kite-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chandantherefore/kite-mcp)

Score Badge

Copy to your README.md:

[![kite-mcp MCP server](https://glama.ai/mcp/servers/chandantherefore/kite-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chandantherefore/kite-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chandantherefore/kite-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server