Angel One Mcp

by ameernoufil

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.10
Disambiguation3/5
Some tools have overlapping purposes, such as get_holdings vs get_all_holdings and get_ltp vs get_market_quote, which could confuse an agent. However, the descriptions provide sufficient detail to differentiate them, so the ambiguity is moderate.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern with underscores (e.g., get_positions, place_order, cancel_gtt_rule). Minor deviations like 'login' and 'logout' as bare verbs, and the mixed noun phrases in get_gtt_rule_details, do not disrupt overall predictability.
Tool Count2/5
With 32 tools, the set is heavy and some tools could be merged (e.g., get_all_holdings into get_holdings, or consolidating the intraday movers). While the scope is broad, the count exceeds the typical threshold and feels bloated.
Completeness5/5
The tool set covers the full trading lifecycle: authentication, profile, holdings, order management, market data, derivatives analysis, GTT rules, and cost estimation. There are no obvious missing operations for a trading platform.
Average 3.7/5 across 32 of 32 tools scored. Lowest: 2.9/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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint, which doesn't convey safety or mutability. The verb 'Get' implies a read-only operation, but the description doesn't disclose rate limits, data volume, error behavior, or authentication needs. It adds little beyond the verb itself.
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?
Two concise sentences that front-load the purpose and efficiently enumerate the valid intervals. No filler or redundant information.
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?
With 5 required parameters and no output schema, the description is minimal. It doesn't describe the return structure, pagination/limits, date handling specifics, or the relationship of symboltoken to other tools like search_scrip. An agent would find it difficult to use effectively without supplementary information.
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 provides 100% parameter descriptions, so the baseline is 3. The description repeats interval values that already exist in the enum, adding no new semantic meaning. It doesn't clarify how to source symboltoken or format dates beyond what the schema states.
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 'Get historical OHLCV candle data for a symbol' with a specific verb and resource, and lists intervals. However, it doesn't explicitly distinguish this from sibling tools like get_ltp or get_market_quote, so it falls short of a perfect 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?
No explicit guidance on when to use this tool versus alternatives. It only states what the tool does, without mentioning when-not-to-use or naming alternative tools. The 'historical' qualifier implies a use case but no clear direction is given.
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?
The only annotation is openWorldHint, which is vague and provides no concrete behavioral context. The description adds no details about side effects, data sources, rate limits, or whether the tool is safe/read-only. For an analysis tool, this lack of transparency is a 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, direct sentence that communicates the core purpose without any filler or redundant information. It earns its place with zero waste.
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?
The tool lacks an output schema, and the description does not explain what the response contains (e.g., symbols, values, formats). Given the tool likely returns analytical data, the description is too sparse to be complete for an agent to fully anticipate the tool's 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%, with both parameters fully described via enums and short descriptions. The tool description repeats the enum values but doesn't add new semantic meaning beyond the schema, so the baseline of 3 applies.
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 function: 'Get OI Buildup analysis' and enumerates the four categories (Long Buildup, Short Buildup, Short Covering, Long Unwinding). This is a specific verb+resource that distinguishes it from broader tools like get_oi_data, though it doesn't explicitly mention 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 on when to use this tool versus alternatives. The description only states what it does, with no mention of use cases, prerequisites, or exclusions, making it difficult for an agent to choose it appropriately among sibling 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?
Annotations only include openWorldHint, which provides minimal safety context. The description does not disclose behavioral traits such as authentication requirements, result sorting, or whether this is a read-only operation. It adds no context beyond the basic action, leaving the agent to infer behavior.
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, concise sentence with no extraneous words. It is appropriately sized for a zero-parameter tool, earning full marks for efficiency.
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?
While the tool is simple with no parameters and no output schema, the description leaves ambiguity around what 'intraday movers' entails (e.g., top gainers, losers, volume). It is minimally sufficient but lacks detail to fully set expectations for the returned data.
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 tool has zero parameters, so the schema fully covers parameter semantics by default. The baseline for 0 params is 4, and there is no need for the description to compensate for missing parameter details.
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 uses the specific verb 'Get' and a clear resource 'top BSE intraday movers data', effectively communicating the tool's core function. It distinguishes from sibling tool get_nse_intraday by specifying BSE, though it could be clearer about what qualifies as 'movers' (e.g., gainers, losers, volume).
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 such as get_nse_intraday or get_gainers_losers. The description simply states the functionality without any contextual cues about appropriate use cases, exclusions, or prerequisites.
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?
The description adds pagination behavior, which is useful beyond the openWorldHint annotation. However, it does not mention authentication, rate limits, or output structure, so it provides moderate rather than rich behavioral 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 concise sentence that front-loads the primary action ('List GTT rules') and includes the key qualifier (filtered by status) and a behavioral note (paginated results). Every word contributes value with zero redundancy.
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?
For a simple list tool with all parameters documented, the description is adequate: it covers the core purpose and pagination. It does not detail the return structure, but the absence of an output schema is partially mitigated by the clear 'List GTT rules' phrasing and the pagination note.
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 coverage is 100% with each parameter described. The description only ties 'filtered by status' and 'paginated results' to existing schema concepts, adding no new semantic meaning beyond what the schema already provides.
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 lists GTT rules with status filtering, using a specific verb and resource. It distinguishes from mutation siblings (create/modify/cancel) but does not explicitly compare to get_gtt_rule_details, so it loses a point for not ensuring 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?
No guidance is provided on when to use this tool versus alternatives like get_gtt_rule_details. The description only states what it does, not when it should be chosen over other GTT tools, leaving the agent to infer appropriate usage.
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?
The only annotation is openWorldHint, and the description adds the list of returned content but does not explicitly state read-only safety, prerequisites like authentication, or response format. The 'Get' verb implies a safe read, but more behavioral context would be beneficial.
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, front-loaded sentence with a colon-separated list of contents. Every word earns its place, with no redundancy or unnecessary detail.
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 zero-parameter read tool, the description lists core data fields but omits return shape and does not distinguish it from get_all_holdings, which could lead to incorrect tool selection. With no output schema, additional detail about the response structure would improve completeness.
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 tool has zero parameters, so the schema provides 100% coverage. The baseline for zero-parameter tools is 4, and the description does not need to add parameter-level detail.
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?
Description uses specific verb 'Get' with resource 'portfolio holdings' and enumerates returned fields (stocks, quantities, average prices, P&L, LTP). It is clear but does not explicitly differentiate from sibling tools like get_all_holdings or get_positions, 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.
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. There is no mention of login requirements, no exclusions, and no reference to sibling tools such as get_all_holdings or get_positions.
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?
The annotations include only openWorldHint: true, which is minimal. The description adds value by disclosing that the tool returns OHLC data in addition to LTP, but it does not disclose any other behavioral traits such as latency, error handling, or whether it requires a valid token. There is no contradiction with annotations, and the description gives some context beyond the annotation.
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, consisting of two short sentences that are front-loaded with the primary purpose. Every word earns its place, and there is no redundant information. This is an example of efficient, targeted writing.
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 simplicity, the description is mostly complete. It explains the core return values (LTP and OHLC) even though there is no output schema. However, it does not mention possible limitations (e.g., exchange availability for certain symbols) or how it differs from other market data endpoints, which would be helpful. Despite this, the basic context is sufficient.
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 covers 100% of the parameters with descriptions, so the baseline is 3. The description does not add additional meaning beyond the schema; it simply repeats 'for a symbol' and mentions OHLC, which does not clarify parameter semantics further. The schema already explains the parameters 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 tool's function: 'Get last traded price for a symbol' and adds that it also returns open, high, low, and close. This is a specific verb+resource with clear scope, but it does not explicitly distinguish itself from sibling tools like get_market_quote or get_candle_data, so it does not fully meet the criteria for a 5.
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 does not mention prerequisites (e.g., needing a symbol token from search_scrip) or scenarios where this tool is preferred over get_market_quote or get_candle_data. There is no explicit when-to-use or when-not-to-use 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?
The description adds no behavioral context beyond what annotations already convey. It does not explain what 'movers' means, whether data is real-time, or any limitations. With only openWorldHint provided, the description carries little additional transparency.
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 a single, focused sentence with no filler words. It is concise, though it could be enriched with more detail without harming clarity.
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 parameters and no output schema, this is a minimal viable description. It clearly states the core function but omits details about what 'movers' includes or the response structure. Given the low complexity, this is adequate yet open to improvement.
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 zero parameters, making schema coverage complete. With no parameters to describe, the description naturally adds nothing, and the baseline of 4 is appropriate.
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 tool retrieves top NSE intraday movers data. The verb 'get' and resource are specific, and the NSE qualifier effectively distinguishes it from the BSE sibling (get_bse_intraday).
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 for when to use this tool versus alternatives like get_bse_intraday or get_gainers_losers. The description is purely declarative with no contextual 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?
The description adds no behavioral context beyond the openWorldHint annotation. It does not disclose what happens for invalid IDs, whether partial/full details are returned, or any authorization requirements. The burden is not met.
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?
A single, front-loaded sentence communicates the core purpose without any filler. Every word earns its place, making it highly concise.
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?
The tool is low-complexity with one well-documented parameter and no output schema. The description specifies the operation but doesn't define what 'details' encompasses, which is a minor gap for agent expectation management.
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 coverage is 100% with the parameter 'id' described as 'GTT rule ID'. The description merely restates 'by ID' without adding new semantic meaning, so the baseline of 3 applies.
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 uses the specific verb 'Get' and clearly identifies the resource as 'details of a specific GTT rule' with an ID qualifier. This precisely distinguishes it from sibling tools like get_gtt_rule_list (which lists rules) and create/modify/cancel GTT tools.
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 when you have a specific GTT rule ID and need its details, contrasting with get_gtt_rule_list for listing all rules. However, it does not explicitly mention alternatives or when not to use this tool.
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?
The annotation openWorldHint: true is present, and the description adds no additional behavioral disclosure. It doesn't mention authentication needs, data freshness, potential large response size, or any side effects. The verb 'Get' implies a read, but the description does not elaborate on the open-world implications.
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, focused sentence that names the data and scope. It has no redundant information, making it highly concise 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?
The tool has 2 parameters and a well-described schema, but lacks an output schema. The description names the Greek fields but doesn't specify the return structure (e.g., a list per strike). It also doesn't mention any prerequisites or limitations. This leaves some ambiguity about the response format.
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 provides 100% coverage with descriptive parameter descriptions (e.g., 'Symbol name (e.g. NIFTY, BANKNIFTY, SBIN)'). The description uses 'underlying' and 'expiry' but adds no additional meaning beyond the schema.
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 uses the specific verb 'Get' and names the precise resource: option Greeks (Delta, Gamma, Theta, Vega, IV) for all strikes of a given underlying and expiry. This clearly differentiates from sibling tools like get_market_quote or get_oi_data.
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 a clear use case (retrieving option Greeks) but does not explicitly state when to prefer this over alternatives such as get_market_quote or get_oi_data. No exclusions or alternative tool names are mentioned.
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?
Annotations already declare destructiveHint=true, so the agent is aware of the destructive nature. The description adds no additional behavioral context such as side effects, reversibility, or required permissions, but it does not contradict the annotations. With annotations covering the safety profile, a baseline 3 is appropriate.
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 concise sentence of eight words. It is front-loaded with the verb and resource, and there is no fluff or redundant phrasing.
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?
For a simple destructive action with full schema coverage and a destructiveHint annotation, the description is adequate. It does not explain return values, but no output schema exists and the operation is straightforward. A slight gap is the lack of context about what happens after cancellation or whether any prerequisites exist, but this is not essential for a cancel operation.
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?
All three parameters (id, symboltoken, exchange) have descriptions in the schema, and schema coverage is 100%. The description's reference to 'by ID' is redundant with the schema's 'GTT rule ID to cancel'. The schema handles the parameter semantics, so the description adds no extra value.
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 uses the specific verb 'Cancel' with the resource 'existing GTT rule' and the identifier 'by ID', clearly distinguishing it from sibling tools like create_gtt_rule, modify_gtt_rule, and get_gtt_rule_details. It is unambiguous and action-oriented.
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 usage guidance is provided beyond the action statement. It does not state when to use this tool versus alternatives such as modify_gtt_rule, nor does it mention prerequisites like first retrieving the GTT ID or listing existing rules. This matches the 'Update shared drive settings' example which scored 2 for the same reason.
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?
Annotations include openWorldHint: true, indicating a safe read operation. The description adds the mode behavior and input requirements but does not disclose additional details like rate limits, error handling, or response format. With annotations covering the safety profile, a 3 is appropriate—the description adds some value but not rich behavioral 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 two sentences long, directly states the tool's purpose, and lists the modes and required inputs with no filler words. Every sentence earns its place, and the structure is front-loaded with the primary verb and resource.
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?
For a tool with three required parameters, all explicitly described in the schema, and no output schema, the description covers the essential aspects: what it does, the modes, and the input requirements. However, it does not describe the return values or any special behavior (e.g., pagination, sort order), which would be helpful given no output schema. It remains adequate for a straightforward quote tool.
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 three parameters. The description merely restates 'Pass exchange and token list' without adding new semantic meaning beyond the schema. It does not compensate with extra details such as token format or value restrictions not already present.
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 'Get market quote data' with a specific verb and resource, and enumerates the available modes (FULL, OHLC, LTP). It distinguishes from many siblings by focusing on quotes, but does not explicitly differentiate from get_ltp, which overlaps with the LTP mode.
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 by describing modes and required inputs ('Pass exchange and token list'), but it does not explicitly state when to use this tool versus alternatives like get_ltp. The context signals show a sibling get_ltp, and no exclusions or alternative guidance is provided.
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?
The description adds no behavioral context beyond the openWorldHint annotation. It doesn't explain what 'data' includes (e.g., current value, historical series, calculation methods), nor does it set expectations about response structure or latency.
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?
A single sentence, 10 words, directly states the tool's purpose with no filler.
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?
For a zero-parameter tool with an openWorldHint annotation, the description is sufficient to convey the basic purpose. However, it leaves ambiguity about market-wide vs. instrument-specific data, which a small clarification could resolve.
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?
There are no parameters, so the schema provides no information. The description adds meaning by identifying the domain as put-call ratio data, but doesn't need to elaborate further since there is nothing to configure.
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 uses a specific verb ('Get') and resource ('Put-Call Ratio data') with a scope ('derivatives market'). It clearly distinguishes from sibling tools like get_oi_data and get_option_greeks, as no other tool mentions put-call ratio.
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, such as whether to use it for market-wide sentiment vs. other market data tools. It doesn't mention exclusions or prerequisites.
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?
The description discloses that it returns symbol tokens, which is a meaningful behavioral trait. However, it does not mention any search semantics like partial matches, case sensitivity, or rate limits. With only openWorldHint annotation (which is vague), the description carries the transparency burden, and while adequate, it could provide more behavior detail.
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?
A single, front-loaded sentence conveys the purpose and key output. No filler words or redundant phrases. Every word earns its place.
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?
For a simple 2-parameter search tool with no output schema, the description adequately covers the purpose, the search field (name), and the output (symbol tokens). It is complete enough for an agent to understand when and how to use it, given the schema provides parameter 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 coverage is 100%, with descriptions for both exchange and searchscrip. The description adds the context that the search is 'by name' and that results are symbol tokens, but these don't deeply enrich the parameter semantics beyond the schema. Baseline 3 is appropriate.
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 'Search' and resource 'trading instruments by name'. While it doesn't explicitly name sibling tools, the search action is distinct from get_ltp, get_candle_data, etc., which are retrieval tools. Could be improved by explicitly mentioning the tool returns instrument tokens, which it does.
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 phrase 'Returns symbol tokens needed for other tools' implies use when you need tokens for downstream calls, but it does not explicitly state when not to use or provide alternatives. Context is clear but not exhaustive.
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 only openWorldHint annotation and no readOnlyHint or destructiveHint, the description carries the burden of disclosing behaviors such as authentication requirements, side effects, or constraints. The description only lists return metrics and does not mention that the tool is read-only, requires login, or has any rate limits. This lack of behavioral context is a significant gap for a tool that likely accesses sensitive portfolio 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, front-loaded sentence that clearly states the tool's function and the specific metrics returned. There is no redundant information, and every word contributes to understanding the tool's purpose. It is concise 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?
The description is adequate for a simple, parameterless retrieval tool, but it lacks a note about why this tool is different from get_holdings (e.g., 'use this for extended P&L data, get_holdings for basic holdings'). It also does not mention any prerequisites like authentication or the output format, given that no output schema is provided. The tool is relatively simple, but the description could be more complete.
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 tool has zero parameters, and the schema is empty. The baseline for no parameters is 4 because there is nothing to document. The description adds no parameter information, but none is needed. This score reflects the absence of parameter documentation requirements.
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 tool's purpose: 'Get extended portfolio holdings' with specific metrics (total holding value, total investment, total P&L, P&L percentage). This distinguishes it from sibling tools like get_holdings by highlighting the 'extended' prefix and the additional computed values, making the purpose specific and unambiguous.
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 when a user needs extended portfolio data with P&L summaries, but it does not explicitly state when to use this tool over alternatives like get_holdings or get_positions. There are no exclusions or comparisons to siblings, so the guidance is implied rather than explicit.
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?
The description adds useful context beyond annotations by clarifying this is historical data and that intervals match candle data. However, it does not disclose output format, pagination, rate limits, or permission requirements. The openWorldHint annotation is present but does not cover read-only behavior, and the description does not contradict it.
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 short sentences, front-loaded with the primary purpose and followed by a clarifying note. Every word earns its place; there is no redundancy or filler.
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?
With 5 required parameters and no output schema, the description is adequate but incomplete. It covers the tool's core purpose and interval semantics but does not describe what the response looks like (e.g., an array of timestamp-OI pairs). This gap is notable for a tool without an output schema.
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 descriptions cover 100% of the parameters, providing baseline semantics. The description adds slight value by stating 'Same intervals as candle data,' which helps clarify the interval parameter's alignment with another tool, but does not go beyond what the schema already offers (e.g., enums for interval and exchange).
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 tool's function: 'Get historical Open Interest data for derivatives.' This specifies the verb (Get), the resource (historical Open Interest data), and the domain (derivatives), distinguishing it from siblings like get_oi_buildup (current buildup) and get_candle_data (price candles). The added note 'Same intervals as candle data' further ties it to the candle data tool without confusion.
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 historical OI queries but provides no explicit when-to-use or alternatives. It does not mention that get_oi_buildup should be used for current OI buildup, nor does it exclude any scenarios. The phrase 'Same intervals as candle data' indirectly references a sibling but stops short of guiding 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?
Annotations already declare destructiveHint=true, so the agent knows this is a mutating operation. The description adds useful context by mentioning supported varieties and the return of an order ID, but it does not disclose additional behavioral traits like margin requirements, failure modes, or exchange-specific restrictions. No contradiction exists.
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 short sentences, immediately front-loading the core purpose. Every word contributes meaning, with no fluff or repetition of schema content. It is appropriately concise given the rich schema.
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?
The schema is detailed and annotations cover the destructive nature, but the description omits critical contextual info such as the need for prior login and the conditional parameter requirements (e.g., triggerprice for SL orders, price for LIMIT orders). The tool has 14 parameters and 9 required fields, and the description does not clarify any interdependencies, leaving a completeness gap for 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?
Schema description coverage is 100%, so the baseline is 3. The description only restates the variety enum (which the schema already documents) and adds no deeper parameter semantics, such as conditional dependencies between order types and trigger prices. It does not significantly go beyond the schema.
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 states a specific verb and resource: 'Place a buy/sell order on Angel One.' This clearly distinguishes it from sibling tools like modify_order and cancel_order, and it explicitly mentions supported order varieties. A clear, non-tautological purpose is provided.
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 its use for placing new orders, but it does not explicitly state when to use this tool versus alternatives such as modify_order or cancel_order. No exclusions or conditions are given, leaving the guidance at an implied level.
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?
Annotations already mark the tool as destructive and open-world. The description adds the key constraint that only 'pending' orders can be cancelled, which is useful behavioral context. It doesn't disclose further consequences like irreversibility or broker-side effects, but the annotations cover the main risk.
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?
A single, front-loaded sentence with no wasted words. It immediately states the action, target, and required inputs, making it highly scannable.
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?
For a simple two-parameter destructive tool, the description is sufficient: it states the purpose, the pending-order restriction, and relies on schema/annotations for parameter and safety details. The absence of an output schema and the tool's simple nature mean nothing critical is missing.
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 coverage is 100%, with both parameters clearly described. The description's phrase 'by order ID and variety' simply restates the schema without adding deeper meaning or explaining the enum semantics. Baseline 3 is appropriate.
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 uses a specific verb 'Cancel' and resource 'pending order', clearly distinguishing it from sibling tools like cancel_gtt_rule and modify_order. The action and target are unambiguous.
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 when you need to cancel a regular pending order, but it doesn't explicitly mention alternatives like cancel_gtt_rule or provide exclusionary guidance. There is no 'when not to use' or comparison to other order-management 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?
Annotations only include openWorldHint:true, with no readOnlyHint or destructiveHint. The description labels the operation as 'Get', implying read-only, but it does not disclose behavioral traits such as result limits, pagination, data freshness, or any side effects. Since annotations do not cover safety, the description should compensate, but it provides minimal extra 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, compact sentence that is front-loaded with the core action and resource. It contains no filler, repetition, or extraneous details, making it highly efficient for an agent to parse.
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?
For a two-parameter tool with no output schema, the description adequately conveys the tool's purpose and the key selection criteria. It does not describe the exact response shape or result count, but given the simplicity and strong schema coverage, the description is sufficiently complete. A slightly richer note on return format would elevate it further, but this is a minor gap.
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 provides 100% description coverage with simple one-line labels ('Data type filter', 'Expiry type'). The description adds meaningful context by explaining that the datatype parameter selects between OI-based or price-change-based gainers/losers, which directly aligns with the enum values (e.g., PercOIGainers, PercPriceLosers). This goes beyond the bare schema labels, improving parameter understanding.
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 'Get top gainers or losers by OI or price change percentage for derivatives' clearly identifies a specific verb ('Get'), a concrete resource ('top gainers or losers'), and the distinguishing criteria ('by OI or price change percentage'), which separates it from sibling tools like get_oi_data or get_market_quote that provide raw data rather than ranked lists.
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 when to use the tool (when you need top gainers/losers for derivatives), but it does not explicitly state alternatives or exclusions. Sibling tools such as get_oi_data or get_oi_buildup could partially overlap, yet no direct comparison or 'use instead' guidance is provided, leaving the agent to infer the appropriate context.
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?
The annotation openWorldHint=true indicates the tool may return results influenced by external state. The description is consistent with that, but adds no additional behavioral context such as error handling, data freshness, or side effects. It does not contradict the annotation.
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, focused sentence that front-loads the action and purpose. No wasted words or redundant detail.
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?
For a single-parameter read operation, the description is sufficient when combined with the schema. However, it does not specify what 'detailed information' includes or any error behavior, which could be helpful given no output schema exists.
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 already covers the single parameter 'orderid' with a clear description. The tool description merely restates 'by its order ID' without adding format, validation, or example. Since schema coverage is 100%, the description adds minimal value.
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 action (get), the resource (specific order), and the identifier (order ID). This distinguishes it from sibling tools like get_order_book, which list orders, by focusing on a single order lookup.
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 the tool is for single-order lookup when you have an order ID, but it does not explicitly contrast with list endpoints like get_order_book or mention any prerequisites. Usage context is implied rather than clearly stated with exclusions.
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?
Annotations already declare destructiveHint=true, and the description adds the constraint that only pending orders can be modified. It does not disclose potential side effects such as whether the modification is atomic, what happens to the original order, or any permission requirements. Minimal value beyond 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?
Two short sentences, front-loaded with the action and immediately followed by the specific changeable fields. No redundant or filler content.
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?
Despite having 12 parameters (10 required) and no output schema, the description does not explain that the full set of order fields must be supplied, nor what the response will look like. It omits preconditions beyond 'pending order' and gives no guidance on error scenarios or special cases like trigger price for stop-loss orders.
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 parameters. The description repeats some param names (price, quantity, order type, trigger price) but adds no additional meaning or relationships beyond what the schema already 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 action ('Modify an existing pending order') and specifies the exact resources and fields affected (price, quantity, order type, trigger price). This distinguishes it from sibling tools like place_order and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing pending order' provides clear context that this tool is for modifying already-placed orders, not for creating new ones. However, it offers no explicit exclusions (e.g., not for filled or cancelled orders) or alternative tool names, so it stops short of a 5.
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?
Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds 'existing position' indicating a mutation of an existing entity, but does not provide additional context such as irreversibility or exchange-side effects. No contradiction.
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?
A single, front-loaded sentence that is entirely informative with no filler. The example adds clarity without wasting words.
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?
Despite having 9 parameters, the schema is fully described and annotations cover destructive/open-world behavior. The description adds a concrete example. It doesn't explain return values or error scenarios, but given the structured data, it is reasonably complete for an agent to select and invoke correctly.
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 descriptions for all parameters including enums. The tool description adds only an example of product type conversion, which slightly illustrates the parameter usage but does not significantly enhance meaning beyond the schema.
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?
Clearly states the action ('Convert') and the resource ('existing position'), with an explicit example of product type change (INTRADAY to DELIVERY). This differentiates it from sibling tools like place_order or modify_order.
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 clearly implies this tool is for converting product types of existing positions, which is distinct from placing/modifying orders. However, it does not explicitly state when not to use it or name alternatives.
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?
The description implies a non-executing estimation role, but beyond that it adds little behavioral context. The openWorldHint annotation is present but the description doesn't clarify whether external calls are made or if results are deterministic. No contradiction, but also no rich disclosure of side effects or computation behavior.
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, front-loaded sentence that immediately communicates the tool's purpose. It enumerates charge types efficiently without any redundant fluff. Every word adds value.
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?
For a one-parameter tool with no output schema, the description covers the core function well. It might benefit from mentioning whether the result is per-order or aggregated, but the simple scope and clear list of charges make it mostly complete. The absence of an output schema increases reliance on description, but the current description is adequate.
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 already documents the 'orders' parameter with a detailed JSON example, achieving 100% schema description coverage. The tool description lists charge types but doesn't add further meaning to the parameter itself beyond what the schema provides. Baseline 3 is appropriate.
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 uses a specific verb 'Estimate' and clearly identifies the resource: 'brokerage, STT, transaction charges, GST, SEBI charges, and stamp duty for proposed trades.' It distinguishes from the sibling tool 'estimate_margin' by listing specific charge types, making its scope unambiguous.
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 phrase 'for proposed trades' provides clear context that this tool is for pre-trade planning. However, it does not explicitly mention alternatives or exclusion cases, such as when to use 'estimate_margin' instead. No misleading guidance, but no explicit when-not-to-use either.
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?
The description conveys that this is a calculation/estimation tool and implies it does not place orders, which is useful. However, with only openWorldHint annotation, the burden is on the description to disclose side effects, auth requirements, or return behavior, none of which are addressed beyond the basic calculation intent.
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, clear sentence with no redundant words. It is front-loaded with the key action ('Calculate margin requirements') and immediately provides context ('before placing them').
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?
For a simple one-parameter tool with a well-documented schema, the description is sufficiently complete for basic usage. It lacks detail about the exact nature of the margin (e.g., span vs exposure) or the return format, but since there is no output schema requirement, the description covers the essential function adequately.
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 for the 'positions' parameter is comprehensive (100% coverage), providing JSON structure and field details. The tool description adds no additional parameter-level meaning beyond what the schema already supplies, so the baseline of 3 is appropriate.
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 states a specific verb ('calculate') and resource ('margin requirements') with a clear scope ('for a batch of potential orders before placing them'). It effectively distinguishes from siblings like estimate_charges and order-related tools.
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 phrase 'before placing them' provides clear context for when to use this tool, distinguishing it from order placement tools. However, it does not explicitly mention alternatives or exclusion criteria, such as when to use estimate_charges instead, which would make it fully explicit.
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?
The description does not contradict the openWorldHint annotation. It adds context about the specific data returned (cash, collateral, utilised margins, net value), but does not disclose additional behavioral aspects such as login requirements, rate limits, or potential side effects. With the annotation present, this is acceptable but not rich.
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 clearly states the purpose and enumerates the key components. No unnecessary words or repetition.
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 simplicity of the tool (no params, no output schema), the description adequately covers the return categories. It could add details like currency or account type, but the description is sufficient for an agent to understand the tool's scope.
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 tool has zero parameters, so there is no parameter information for the description to add. The baseline of 4 is appropriate since there is no ambiguity or missing parameter documentation.
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 uses the specific verb 'Get' and identifies the resource as 'available funds and margins', listing key components. This clearly distinguishes it from sibling tools like get_positions and get_holdings, which deal with securities rather than cash/margins.
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 intended use is implied by the resource name and component list, but there is no explicit guidance on when to use this tool over siblings. It does not mention alternatives or exclusions, making the guidance adequate but not explicit.
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?
The description adds useful context about what the response contains (intraday/carryforward, quantities, prices, P&L) but does not disclose any potential side effects, authentication requirements, or data freshness. The 'Get' verb implies read-only behavior, but the openWorldHint annotation does not fully cover safety, and the description does not explicitly state that it is a safe 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 a single sentence, front-loaded with the main purpose, and every phrase adds value. There is no fluff or redundancy, making it highly concise and well-structured.
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?
For a simple zero-parameter tool, the description adequately lists the response contents (open positions with intraday/carryforward, quantities, prices, and P&L). It does not mention pagination or precise response format, but given the simplicity and lack of output schema, the description is sufficiently complete.
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 tool has zero parameters, so there are no parameter semantics to explain. According to the scoring guide, a tool with no parameters receives a baseline score of 4, and the description does not need to compensate for any schema gaps.
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 uses a specific verb 'Get' and a specific resource 'open positions', and enumerates the returned details (intraday/carryforward, buy/sell qty, avg prices, unrealised P&L). This clearly distinguishes it from sibling tools like get_holdings or get_funds.
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 the tool is for retrieving open positions by its name and content, but it does not explicitly state when to use it or how it compares to alternatives like get_holdings or get_all_holdings. There is no 'use this when' guidance, though the content list makes the purpose self-evident.
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?
The annotation openWorldHint is present but not explained, and the description adds context about return content (fill prices, quantities, timestamps). However, it does not disclose any additional behavioral traits such as side effects, authentication needs, or rate limits. Since the tool is a read operation, the lack of such disclosures is acceptable but not rich.
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 concise sentence that efficiently communicates the purpose and return fields. Every word earns its place, with no filler or redundancy.
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 low complexity (no parameters, no output schema), the description covers the essential return information: fill prices, quantities, timestamps, and the time bound 'today'. It does not detail the output structure, but for a simple list tool this is reasonably complete. Sibling tools provide enough context for differentiation.
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?
There are zero parameters, so the description does not need to explain any. The baseline for 0 params is 4, and the description adds no parameter information beyond the schema, which is already fully covering (vacuously).
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 uses a specific verb 'Get' and identifies the resource as 'executed trades for today', with details on fill prices, quantities, and timestamps. This clearly distinguishes it from sibling tools like get_order_book (orders) or get_positions (positions).
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 context by specifying 'executed trades for today', which suggests this tool is for retrieving today's fills. However, it does not explicitly state when to use it over alternatives or provide any exclusions. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, and the description aligns by stating 'Modify'. It adds the context of changing specific fields but does not disclose side effects like whether all required parameters must be sent or if unmentioned fields are reset. This is acceptable given annotation coverage, so a middle score is appropriate.
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?
Two short sentences, front-loaded with the primary action. No redundant content or filler, making it highly efficient.
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 rich schema with 100% coverage and annotations indicating destructive behavior, the description is sufficient for an agent to select and invoke the tool. It does not explain return values, but no output schema exists and this is not required for a modify operation.
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 all 12 parameters are described in the input schema. The description merely restates that price, quantity, and trigger price can be changed, adding no new format or syntax details beyond the schema. Baseline of 3 is warranted.
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 uses a specific verb ('Modify') and resource ('existing GTT rule'), and lists concrete changeable fields (price, quantity, trigger price). This clearly distinguishes it from sibling tools like create_gtt_rule, cancel_gtt_rule, and get_gtt_rule_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 phrase 'existing GTT rule' implies this tool is for modifications rather than creation or cancellation, providing clear context. It does not explicitly name alternatives or exclusion criteria, but the sibling tool names make the use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a key behavioral detail beyond the annotations: 'When trigger price is hit, the order is automatically placed.' This is important side-effect information not captured by the destructiveHint and openWorldHint annotations. It does not mention other behaviors like persistence but provides enough context for safe invocation.
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 concise sentences, with the core purpose and trigger behavior front-loaded. There is no redundancy or filler; every word contributes to understanding.
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?
For a tool with 11 parameters and no output schema, the schema fully documents the inputs, and the description covers the essential behavior. It could mention return values or post-trigger actions, but the current description is reasonably complete for an agent to select and invoke the tool correctly.
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 for all 11 parameters, each with meaningful descriptions (e.g., 'Price at which the order triggers'). The tool description itself adds no parameter-specific insights, so the baseline score of 3 is appropriate.
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 tool's function: 'Create a GTT (Good Till Triggered) rule.' It also explains the trigger behavior, which distinguishes it from sibling tools like modify_gtt_rule, cancel_gtt_rule, and get_gtt_rule_list. This is a specific verb+resource combination with additional context.
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?
While it does not explicitly state when to use it vs. alternatives, the tool's name and the presence of sibling tools like modify_gtt_rule and cancel_gtt_rule make the intended use case clear. The description implies it is for creating new GTT rules, which is sufficient guidance for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation openWorldHint is present, but the description adds valuable behavioral scoping: it returns only today's orders and includes specific statuses and data fields. It doesn't disclose potential side effects, but the 'get' verb implies a read-only operation, which is consistent.
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, front-loaded sentence that efficiently conveys the tool's purpose, scope, and output. Every word adds value, with no unnecessary elaboration.
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?
For a simple, parameterless tool, the description covers all essential aspects: time range, order statuses, and displayed fields. It doesn't specify return format or pagination, but given the absence of an output schema, this is adequate.
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?
With zero parameters, the baseline is 4. The description doesn't need to explain parameter details because there are none, and it remains clear what the tool does.
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 uses the verb 'Get' with a specific resource 'all orders for today' and lists the statuses (pending, executed, rejected) and fields (status, prices, quantities). This clearly differentiates it from sibling tools like get_positions or get_trade_book.
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 temporal scope 'for today' provides some usage context, but the description does not explicitly state when to prefer this tool over alternatives like get_order_details or get_trade_book. No exclusion or alternative conditions are mentioned.
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?
The description lists the specific data fields returned, which adds transparency beyond the annotation (openWorldHint). However, it does not disclose whether authentication is required, whether this is a read-only operation, or any potential side effects. Given the minimal annotation coverage, the description provides some but not rich behavioral 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 lists the exact information returned. There is no wasted verbiage, and the most important information (what the tool does) is front-loaded.
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?
The description lists the return fields, which substitutes for a missing output schema. It is complete enough for a simple, low-complexity getter tool. It could explicitly mention that the profile is for the currently authenticated user, but this is strongly implied and not a significant gap.
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 tool has zero parameters, and the schema coverage is 100% (empty properties object). The description adds no parameter details, but none are needed. A baseline of 4 is appropriate for a no-parameter tool.
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 'Get Angel One user profile' followed by a concise list of returned fields (name, email, mobile, exchanges, products, broker info). It uses a specific verb+resource structure and is easily distinguished from sibling tools like get_holdings or get_positions.
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 clearly implies when to use this tool: when you need the user's profile information. There are no explicit exclusions or alternative tool mentions, but the context is unambiguous given the tool name and description. A 4 is appropriate because it gives clear context without formal 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation openWorldHint=true already indicates external side effects, and the description adds useful behavioral context: auto-generates TOTP and stores session internally. It does not contradict the annotation, but does not disclose failure handling or credential requirements, which would be helpful.
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 three short sentences, each providing distinct information: the action, the TOTP auto-generation, and the session storage. It is perfectly sized, front-loaded with the main purpose, and contains no redundant wording.
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 simplicity (no parameters, no output schema), the description covers the core behavior. It could be more complete by explicitly stating that this must be called before other tools, but the session storage mention implies this, and the annotation covers external effects.
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?
With zero parameters, the description's note about auto-generating TOTP explains why no TOTP parameter is needed, adding semantic value beyond the empty schema. This fits the baseline of 4 for zero-parameter tools and slightly enhances it.
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 it authenticates with Angel One SmartAPI, using a specific verb and resource. It also adds distinguishing details about TOTP generation and internal session storage, separating it from related tools like logout or get_profile.
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 that authentication is a prerequisite for other API calls by noting it stores the session internally, but it does not explicitly state when to use it or mention alternatives like logout. The usage context is inferable but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral effect: invalidating tokens. With only openWorldHint annotation (which does not cover side effects), the description takes the burden and informs about session termination. It does not detail that tokens become unusable or that subsequent calls fail, but 'invalidate' implies this.
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, concise sentence that conveys the complete action without any filler. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides sufficient context. It clearly states the purpose and side effect, so an agent can select and invoke it correctly without additional information.
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 tool has zero parameters, and schema description coverage is 100% (vacuously true). The baseline score of 4 applies since there is no parameter information needed; the description adds no parameter semantics because there are none to explain.
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 action: ending the Angel One SmartAPI session and invalidating tokens. It uses a specific verb ('End') and resource ('session') and distinguishes itself from sibling tools like login.
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 purpose implicitly conveys when to use it — when you need to terminate the session. However, it does not explicitly mention that this should be used after completing all API operations or that it will require re-authentication, but the context is clear.
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:

[![angel-one-mcp MCP server](https://glama.ai/mcp/servers/ameernoufil/angel-one-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ameernoufil/angel-one-mcp)

Score Badge

Copy to your README.md:

[![angel-one-mcp MCP server](https://glama.ai/mcp/servers/ameernoufil/angel-one-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ameernoufil/angel-one-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/ameernoufil/angel-one-mcp'

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