Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@angelone-mcp Show my current positions and available margin"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that wraps Angel One's SmartAPI — trading, portfolio, market data, GTT rules, and margin/brokerage — so any MCP client (Claude, Claude Code, etc.) can query your account and place orders through natural conversation.
⚠️ This places real orders on a real trading account. Test with small quantities first, and keep in mind Angel One (like most brokers) does not let you "undo" a filled order.
angelone_mcp/client.py – REST client for every documented SmartAPI route:
auth, orders, positions/holdings, GTT rules, historical candles/OI,
quotes, option greeks, gainers/losers, margin calculator, brokerage
estimator. Handles TOTP login, auto re-login on token expiry, and paces
itself against SmartAPI's documented rate limits (see "Rate limiting"
below).
angelone_mcp/server.py – MCP server exposing 32 tools built on top of
the client (see full list below).
Related MCP server: icici-mcp
Python 3.10+
An Angel One trading account with SmartAPI access
A SmartAPI app created at https://smartapi.angelone.in/ (gives you an API key)
TOTP set up on your Angel One account, and the base32 secret used to set up that authenticator (not the 6-digit code — the secret behind it). You get this once, when you first scan the QR code to enable TOTP; if you don't have it saved, you'll need to reset/reconfigure TOTP on your account to get a fresh secret.
cd angelone-mcp
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txtSet these environment variables (e.g. in a .env file you source, or
directly in your MCP client config):
Variable | Description |
| API key from your SmartAPI app |
| Your Angel One client/trading account code |
| Your login PIN |
| Base32 TOTP secret for your account |
Never commit these to source control. Treat ANGELONE_TOTP_SECRET and
ANGELONE_PIN like passwords — anyone with them plus your API key can trade
on your account.
If your machine/network requires an outbound HTTP proxy to reach the internet, set:
Variable | Description |
| Proxy URL used for |
| Proxy URL used for |
| Optional comma-separated list of hosts to bypass the proxy for |
These are only needed if the standard HTTP_PROXY / HTTPS_PROXY environment
variables aren't already visible to the server process. That's commonly the
case for MCP servers, since MCP clients usually launch the server with an
explicit env block (like the JSON below) instead of inheriting your shell's
environment — so a proxy configured in your shell won't reach the server
unless you either add it to that env block yourself under HTTPS_PROXY, or
use the ANGELONE_* variables above. If neither ANGELONE_HTTP_PROXY nor
ANGELONE_HTTPS_PROXY is set, the server falls back to the standard
HTTP_PROXY/HTTPS_PROXY/NO_PROXY variables automatically.
Standalone (for testing):
python -m angelone_mcp.serverIt speaks MCP over stdio, so it's meant to be launched by an MCP client, not run interactively.
Add to your MCP client's config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"angelone": {
"command": "/absolute/path/to/angelone-mcp/.venv/bin/python",
"args": ["-m", "angelone_mcp.server"],
"cwd": "/absolute/path/to/angelone-mcp",
"env": {
"ANGELONE_API_KEY": "your_api_key",
"ANGELONE_CLIENT_CODE": "your_client_code",
"ANGELONE_PIN": "your_pin",
"ANGELONE_TOTP_SECRET": "your_base32_totp_secret",
"ANGELONE_HTTPS_PROXY": "http://user:pass@proxyhost:8080"
}
}
}
}Session
login, logout, get_profile
Orders
place_order, modify_order, cancel_order, get_order_book,
get_trade_book, get_individual_order_details
Portfolio / funds
get_positions, get_holdings, get_all_holdings, get_rms_limit,
convert_position
GTT (Good Till Triggered) rules
gtt_create_rule, gtt_modify_rule, gtt_cancel_rule, gtt_details,
gtt_list
Market data
get_ltp, get_market_quote, search_scrip, get_candle_data,
get_oi_data, get_option_greeks, get_gainers_losers,
get_put_call_ratio, get_oi_buildup, get_nse_intraday_data,
get_bse_intraday_data
Margin & brokerage
get_margin, estimate_charges
AngelOneClient logs in lazily on the first tool call using
clientcode + pin + a TOTP generated on the fly from
ANGELONE_TOTP_SECRET (via pyotp). It caches the resulting jwtToken,
refreshToken, and feedToken in memory for the life of the process. If any
call comes back with a 401/403 or a TokenException, it transparently
re-logs-in once and retries — you don't need to call login yourself unless
you want to force a fresh session.
Sessions issued by SmartAPI are valid until midnight IST regardless of activity, so a long-running server may still need a fresh login the next day — the auto-retry logic handles that automatically on the next call.
A successful login is also cached to a file on disk, so a fresh server process doesn't need a fresh TOTP-based login every time it starts (handy since TOTP requires the code to be freshly generated — restarting the server several times in a row otherwise means several real logins in a row).
On startup, before serving any tool calls, the server calls
AngelOneClient.restore_session(), which:
Looks for a previously saved session file. If there isn't one, it does nothing further — the client stays in its normal lazy mode and logs in on the first tool call, same as before this feature existed.
If a saved session is found, it loads the cached tokens and verifies them
with a real getProfile call.
If that verification succeeds, the restored session is used as-is — no fresh login needed.
If it fails for any reason (expired token, revoked session, corrupt file, etc.), the cached tokens are discarded and a normal fresh login runs instead.
Every successful login (fresh or via the automatic 401/403 retry described
above) re-saves the session file, so it stays current across the whole time
the server runs, not just at startup. logout deletes the file.
Variable | Description |
| Set to |
| Override the file path used to persist the session. Default: a file under the OS temp directory, named from a hash of your client code (so multiple accounts on the same machine don't collide) |
The session file holds a live access token — not your PIN or TOTP secret, but enough to call the API as you until it expires. It's written with owner-only file permissions where the OS supports it; treat it as sensitive the same way you'd treat any cached login session.
AngelOneClient paces every outgoing call against
SmartAPI's documented per-endpoint rate limits
— login and most portfolio reads at 1 request/sec, getProfile at 3/sec,
quotes/GTT/order-detail lookups at 10/sec, order placement at 20/sec, and so
on. Limits are per SmartAPI endpoint, not global, so calling different tools
back-to-back is never slowed down by this — only a repeat call to the same
endpoint made faster than SmartAPI's own limit allows gets held back, which
you'd want anyway.
If SmartAPI reports its own limit was hit regardless (HTTP 403/429, "Access denied because of exceeding access rate"), the call backs off and retries a few times with increasing delay before giving up — and that response no longer gets misread as an expired session and doesn't trigger a spurious extra login the way it used to.
This applies to every tool automatically; there's nothing to configure to get it. To turn client-side pacing off entirely (SmartAPI still enforces its own limits server-side either way — this only controls whether the client tries to stay under them proactively):
Variable | Description |
| Set to |
pip install -e ".[test]"
# Offline: verifies the server registers the expected tools. No credentials
# or network access needed.
python -m pytest tests/test_tool_registration.py -v
# Offline: unit tests for session persistence (login state cached to disk,
# restored + verified via get_profile on restart, falls back to a fresh
# login when the cache is missing/invalid). Uses a fake HTTP layer - no
# credentials or network access needed.
python -m pytest tests/test_session_persistence.py -v
# Offline: unit tests for AngelOneClient's own rate limiting (pacing per
# ROUTE_MIN_INTERVAL, backoff/retry on a 403/429 rate-limit response, and
# that such a response is never misread as an expired session). Uses a fake
# HTTP layer - no credentials or network access needed.
python -m pytest tests/test_client_rate_limiting.py -v
# Live, read-only smoke test against your real account. Calls get_profile,
# get_order_book, get_holdings, search_scrip, get_ltp, etc. through the
# actual MCP server subprocess, plus a check that a session survives a
# restart of the server without calling the "login" tool again. Never calls
# place_order/modify_order/cancel_order/gtt_create_rule/gtt_modify_rule/
# gtt_cancel_rule/convert_position/logout - a SafeSession wrapper
# hard-asserts those are never invoked. On top of the server's own rate
# limiting (see "Rate limiting" above), the test itself also paces its tool
# calls and backs off/retries if the API reports one was hit anyway (see
# "Rate limiting in the live test" below) - belt and suspenders. Requires
# ANGELONE_API_KEY/ANGELONE_CLIENT_CODE/ANGELONE_PIN/ANGELONE_TOTP_SECRET
# to be set; skips automatically if they aren't.
python -m pytest tests/test_readonly_live.py -v -s
# or, for a plain-text report without pytest:
python tests/test_readonly_live.pyThe live test (tests/test_readonly_live.py) calls a real account against
the real SmartAPI. The server it drives already paces itself (see "Rate
limiting" above), but the test adds its own independent pacing on top -
useful because it also exercises things the server-side limiter doesn't see
by itself, like two separate server subprocesses (the session-persistence
check) hitting the same account back to back:
A RateLimiter tracks the last time each MCP tool was called and, before
calling it again, waits out the rest of that endpoint's minimum interval
(1/req-per-second-limit, plus a ~20% safety margin). Distinct tools hit
distinct SmartAPI endpoints with independent limits, so this only ever
delays a repeat call to the same tool (e.g. get_profile being called
again by the second server spawn in the session-persistence check) - a
normal single pass through the suite, where every tool is called once or
twice, isn't slowed down by it in practice.
If SmartAPI reports a rate limit was hit anyway (HTTP 403, "Access denied because of exceeding access rate"), the test backs off and retries a couple of times with increasing delay instead of failing outright.
This governs the test suite's own request pace only - it has no effect on how the MCP server behaves for a real MCP client (Claude, etc.); SmartAPI still enforces its limits server-side either way.
Order params (price, quantity, etc.) are passed as strings, matching
what SmartAPI's placeOrder expects.
get_margin and estimate_charges take a list of position/order dicts —
see the SmartAPI docs for exact field names per instrument type
(https://smartapi.angelone.in/docs/Margin, .../Brokerage).
Rate limits are enforced by Angel One per endpoint; see https://smartapi.angelone.in/docs/RateLimit. This server does not do its own client-side rate limiting.
Not affiliated with or endorsed by Angel One / Angel Broking.
Cancel an open order by its order id. variety: NORMAL | STOPLOSS | AMO | ROBO
| Name | Required | Description | Default |
|---|---|---|---|
| variety | Yes | ||
| order_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the order must be open, but does not disclose whether cancellation is irreversible, what happens for already-filled or expired orders, or any required permissions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a single clear sentence states the action, followed by a short list of valid variety values. There is no filler, repetition, or unnecessary detail; every element contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two required parameters and an output schema exists, so return value explanation is unnecessary. However, with no annotations and no explicit usage guidance, the description leaves the agent to infer cancellation semantics and the role of the variety parameter. It is adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the valid variety values (NORMAL | STOPLOSS | AMO | ROBO), which provides meaning beyond the bare schema titles. However, it does not define these varieties or clarify where to find the order_id, so the compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and target: 'Cancel an open order by its order id.' This specific verb and resource make it easy to distinguish from siblings like place_order, modify_order, and get_order_book. The variety list further clarifies the scope of orders covered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool should be used—when an open order needs to be canceled by its ID. However, it does not explicitly state when not to use it or name alternatives, such as using modify_order to change an order or gtt_cancel_rule for GTT rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a position from one product type to another (e.g. INTRADAY -> DELIVERY).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | DAY | |
| exchange | Yes | ||
| quantity | Yes | ||
| symboltoken | Yes | ||
| tradingsymbol | Yes | ||
| newproducttype | Yes | ||
| oldproducttype | Yes | ||
| transactiontype | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the core action but omits important side effects such as whether the original position is closed, whether margin or funds are affected, whether the conversion is reversible, or what the response indicates. For a mutating tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though it may be too brief for an 8-parameter mutation operation that lacks parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of position conversion, the lack of annotations, and the high number of undocumented parameters, the one-sentence description is insufficient. It does not explain preconditions, allowed product types, response behavior, or how to identify the position being converted, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate. It only clarifies the meaning of oldproducttype and newproducttype via the example, leaving exchange, symboltoken, tradingsymbol, transactiontype, quantity, and type unexplained. The example adds some value but does not cover the majority of required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Convert'), the resource ('a position'), and the transformation ('from one product type to another'). The example INTRADAY -> DELIVERY makes the operation instantly understandable and distinguishes it from order placement/modification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—changing the product type of an existing position—but does not explicitly state when to use this tool versus place_order, modify_order, or get_positions. No exclusions or alternative tool names are provided, so the guidance is present only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate brokerage and other charges for a basket of prospective orders.
Each order dict needs: product_type, transaction_type, quantity, price, exchange, symbol_name, token.
| Name | Required | Description | Default |
|---|---|---|---|
| orders | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of indicating side effects. 'Estimate' and 'prospective' strongly suggest no order is actually placed, but the description does not explicitly disclose this safety-relevant trait or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the purpose is stated first, then the essential parameter requirement follows immediately. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema present, the description gives enough to call it correctly by listing the required sub-fields. It lacks some operational context such as whether orders can be empty or whether estimates are per-order or aggregate, but those are minor against the output schema and the clear required fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the orders parameter is undocumented in the schema, but the description compensates by enumerating the required key fields for each order dict: product_type, transaction_type, quantity, price, exchange, symbol_name, token. It stops short of giving types or formats, so it is strong but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') and clarif resource ('brokerage and other charges for a basket of prospective orders'). This clearly distinguishes the tool from siblings like place_order or get_margin, none of which are about estimating charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'prospective orders' implies use before placing real orders, but the description does not explicitly state when to use this tool versus alternatives, nor when not to use it. Usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get holdings plus a portfolio-level summary (total investment, current value, P&L).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It signals a read-only retrieval operation and lists the returned data categories, but it does not address authentication needs, response structure, or any other behavioral constraints. The read-only nature is inferable from 'Get' but not formally backed by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The core action and distinguishing output features are front-loaded and immediately scannable by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with an output schema, the description is mostly sufficient. However, it omits any mention of authentication/session prerequisites and does not explicitly resolve the ambiguity with the similarly named get_holdings sibling, so more contextual guidance would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so no parameter-level documentation is needed. The description adds useful context by clarifying that results include both holdings and computed summary fields, which is more than the empty input schema conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get'), the resource ('holdings'), and the added output ('portfolio-level summary' with total investment, current value, P&L). It implicitly differentiates from the sibling get_holdings by mentioning the summary, but it does not name or explicitly contrast that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: choose this tool when you need holdings plus portfolio-level summary numbers. However, there is no explicit guidance about when to use get_holdings instead, nor any mention of alternatives, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get BSE intraday most-active-by-volume/value data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Get' signals a read-only data retrieval and 'most-active-by-volume/value' clarifies the data selection/ordering behavior, but it does not disclose operational details such as data freshness, login requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to identifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter data-retrieval tool, the description names the exchange, the data category, and the selection criteria, and an output schema exists to document the return shape. It is slightly incomplete because it does not explicitly contrast with get_nse_intraday_data or state usage caveats, but the simple scope makes it sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and schema description coverage is 100%, so there is no parameter documentation burden on the description. Per the baseline for tools with no parameters, this is a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get BSE intraday most-active-by-volume/value data'. It clearly identifies the exchange (BSE) and the selection criteria (most active by volume/value), which distinguishes it from sibling tools such as get_nse_intraday_data and other market-data endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'BSE intraday' implies this tool is for BSE market data, so the usage context is evident by contrast with the NSE sibling. However, it does not explicitly state when to choose this tool over alternatives or describe any exclusions, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical OHLCV candle data.
interval: ONE_MINUTE | THREE_MINUTE | FIVE_MINUTE | TEN_MINUTE | FIFTEEN_MINUTE | THIRTY_MINUTE | ONE_HOUR | ONE_DAY fromdate/todate format: "YYYY-MM-DD HH:MM" (e.g. "2024-01-01 09:15")
| Name | Required | Description | Default |
|---|---|---|---|
| todate | Yes | ||
| exchange | Yes | ||
| fromdate | Yes | ||
| interval | Yes | ||
| symboltoken | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It does not mention read-only nature, data availability limits, rate limits, pagination, or any other operational behavior. The interval and date-format notes are parameter help rather than behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one clear purpose sentence followed by essential format constraints. Every line earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the most error-prone parameters (interval and date format) and the output schema exists, so return structure is already handled. However, without guidance on exchange values or how symboltoken is obtained, an agent may still struggle to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's parameter notes add real value: it enumerates all valid interval values and specifies the exact fromdate/todate format with an example. However, exchange and symboltoken remain unexplained, leaving the agent to infer their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get historical OHLCV candle data,' which names a specific verb and resource. It is clearly distinguishable from most siblings, though it does not explicitly differentiate itself from get_nse_intraday_data or get_bse_intraday_data beyond the OHLCV term.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is only implied: 'historical OHLCV candle data' suggests this is for past price data rather than real-time quotes or intraday-specific feeds. No explicit guidance about when not to use it or what alternatives to prefer is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top F&O gainers/losers.
datatype: PercPriceGainers | PercPriceLosers | PercOIGainers | PercOILosers expirytype: NEAR | NEXT | FAR
| Name | Required | Description | Default |
|---|---|---|---|
| datatype | Yes | ||
| expirytype | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the domain and allowed parameter values, but does not state whether the call is read-only, how results are ranked, what time frame applies, or any other behavioral constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded, with the core purpose in the first sentence and parameter values listed in two terse lines. Every part earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return-value expectations, and the description covers purpose and parameter values. However, with no annotations and no usage guidance, the definition is only minimally sufficient for an agent to call the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the enumerated values in the description are the only semantic guidance for the parameters. The value lists are helpful and self-explanatory, but the description does not explain what each datatype means or how NEAR, NEXT, and FAR differ beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource statement: 'Get top F&O gainers/losers.' The parameter value lists further specify the exact categories of gainers/losers, which distinguishes this from close siblings like get_oi_buildup or get_market_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus sibling market-data tools, and names no alternatives or exclusions. It only states what the tool does and lists parameter values, so an agent gets no decision support for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the equity holdings currently in the demat account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It indicates a read-only operation via 'Get' and adds temporal scope with 'currently', but it does not mention authentication requirements, rate limits, or any other operational behavior. This is adequate but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or redundant content. Every word contributes to defining what the tool returns and for what account context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with zero parameters and an output schema, so the description does not need to explain return structure. However, it leaves ambiguity around how this relates to sibling tools like get_all_holdings, and it does not provide any usage or exclusion context, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 for zero-parameter tools applies, and the description does not need to compensate for missing parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and resource ('equity holdings currently in the demat account'), making the tool's core purpose understandable. However, it does not explicitly differentiate itself from the sibling tool get_all_holdings, so it is clear but lacks direct sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool would be used, but it provides no explicit guidance on when to choose this tool over alternatives such as get_all_holdings or get_positions. There are no stated usage contexts, exclusions, or routing signals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full lifecycle detail/history for a single order by its unique order id.
| Name | Required | Description | Default |
|---|---|---|---|
| unique_order_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It conveys a read-only intent and reveals that the result includes full lifecycle detail/history, but it does not mention any prerequisites, scope restrictions, or data freshness caveats. The disclosure is adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the verb, resource, scope, and identifying parameter with no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with an output schema, the description is nearly sufficient. It identifies the required input and the nature of the returned data, though it leaves usage context and alternative routing to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It restates 'unique order id' but adds no format, example, or provenance. The single parameter is self-descriptive enough for an agent to supply it, but meaningful extra detail is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), resource ('single order'), and scope ('full lifecycle detail/history... by its unique order id'). This clearly distinguishes it from list-oriented siblings like get_order_book and 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for retrieving one specific order via unique_order_id, providing clear context against the sibling list tools. It does not explicitly name alternatives or exclusions, but the single-order scoping is strong enough guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the last traded price (LTP) for a single instrument.
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | ||
| symboltoken | Yes | ||
| tradingsymbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only communicates a read-style 'Get' action; it does not mention authentication needs, live-vs-delayed data behavior, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, but with no annotations the description lacks guidance on how to obtain valid symboltoken/tradingsymbol pairs and does not distinguish itself from market-data siblings. It is minimally adequate but has practical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain how exchange, symboltoken, and tradingsymbol identify the instrument. It only refers to 'a single instrument,' leaving parameter semantics almost entirely to the raw schema and field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Get the last traded price (LTP)') and clearly limits scope to 'a single instrument,' so an agent knows what the tool returns. It does not explicitly differentiate itself from siblings like get_market_quote or get_candle_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a single instrument' implies this tool is for isolated LTP lookups rather than broader market data queries, but no alternatives or when-not-to-use guidance is provided. The intended usage is inferable, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate span + exposure margin required for a basket of positions before placing them.
Each position dict needs: exchange, qty, price, productType, token, tradeType (BUY/SELL), orderType.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully discloses that each position dict requires specific fields, but does not state whether the operation is read-only, requires authentication, or has any side effects. The word 'calculate' implies a query-like operation but does not make this explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states the primary purpose, the second details input requirements. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered. The description fully specifies the only parameter's structure and required fields. Minor missing context includes auth prerequisites and behavior with empty or invalid baskets, but for a single-parameter margin calculator this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines an array of objects with additionalProperties true (0% coverage), so the description fully compensates by enumerating the required fields: exchange, qty, price, productType, token, tradeType (BUY/SELL), orderType. This provides essential semantics the schema lacks, including tradeType's allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Calculate') and resource ('span + exposure margin') for a basket of positions, with the context 'before placing them.' This makes the tool's purpose unambiguous and differentiates it from siblings like place_order, estimate_charges, and get_rms_limit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before placing them' provides an explicit context for when to use the tool – as a pre-trade margin check. However, it does not name alternative tools or state when not to use this tool, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get market quotes for up to 50 instruments per exchange in one call.
mode: LTP | OHLC | FULL exchange_tokens: e.g. {"NSE": ["3045", "881"], "NFO": ["58662"]} - a map of exchange -> list of symbol tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| exchange_tokens | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the 50-instrument-per-exchange limit and the LTP/OHLC/FULL modes, which is useful behavioral context. However, it does not mention authentication requirements, error conditions, or how the API handles invalid tokens, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose, followed by a useful parameter key block. The example is necessary and well-placed, and there is minimal fluff. The formatting could be slightly tighter, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not detail return values. It covers purpose, parameter semantics, a realistic example, and the batch limit. The main missing element is explicit usage guidance versus related tools, but the core information an agent needs to invoke this tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by defining valid values for mode and explaining the exchange_tokens structure with a concrete JSON example. This goes well beyond the bare string/object types in the schema and removes ambiguity about how to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Get market quotes' with the precise scope 'up to 50 instruments per exchange in one call.' The batching and per-exchange framing distinguishes this from single-instrument siblings like get_ltp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'in one call' phrasing and the per-exchange limit imply that this tool is for batch quote retrieval, but it never explicitly says when to use it instead of alternatives such as get_ltp or get_candle_data. No exclusions or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get NSE intraday most-active-by-volume/value data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral weight. It conveys that this is a read-only data retrieval operation and specifies the exchange and metric ('most-active-by-volume/value'), but it does not disclose details such as whether data is delayed, whether it reflects current trading day, or what the output structure means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler or redundancy. The key qualifiers ('NSE', 'intraday', 'most-active-by-volume/value') are all present and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is largely sufficient. The only minor gap is that 'volume/value' is slightly ambiguous (could mean either or both), and no explicit distinction from the BSE sibling is named, but overall the tool can be invoked correctly with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially satisfied. The description does not need to explain parameters that do not exist, and no ambiguity is introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('NSE intraday most-active-by-volume/value data'). It is immediately distinguishable from the sibling tool get_bse_intraday_data by exchange, so an agent can select it appropriately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'NSE intraday' clearly establishes when this tool applies versus the BSE-focused sibling. It does not explicitly name alternatives or exclusions, but the context is strong enough for a zero-parameter retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get open-interest buildup data (long/short buildup, unwinding, etc.) for F&O contracts.
datatype: Long Built Up | Short Built Up | Short Covering | Long Unwinding expirytype: NEAR | NEXT | FAR
| Name | Required | Description | Default |
|---|---|---|---|
| datatype | Yes | ||
| expirytype | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only says 'Get' data, implying a read operation, but does not disclose authentication needs, rate limits, data freshness, or any side effects. The listed values for datatype and expirytype are parameter information rather than behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. The parameter value lists are formatted clearly and contain no filler. Every line contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two required string parameters and an output schema, the description supplies the necessary valid values to call it correctly. However, it lacks usage context, behavioral expectations, and differentiation from the closely related get_oi_data sibling. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and no enums for either parameter. The description compensates by listing the exact allowed values for datatype and expirytype, which is essential for correct invocation. It does not deeply explain the meaning of each value, but the provided enum lists add substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get open-interest buildup data' for F&O contracts. It also enumerates the data categories (long/short buildup, etc.), making the tool's purpose clear. It does not explicitly distinguish itself from the sibling get_oi_data, but the name and content are sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus related alternatives like get_oi_data or get_put_call_ratio. The description states what data is returned but not the scenarios where this data is relevant or when a sibling should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical open-interest (OI) data for F&O instruments. Same interval/date format as get_candle_data.
| Name | Required | Description | Default |
|---|---|---|---|
| todate | Yes | ||
| exchange | Yes | ||
| fromdate | Yes | ||
| interval | Yes | ||
| symboltoken | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states that the tool fetches historical OI data and reuses a date/interval format; it does not disclose authentication needs, rate limits, response shape nuances, or any read-only guarantees beyond the verb 'Get.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no filler. It states the core purpose first and uses a sibling reference to avoid repeating format documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 required, entirely undocumented parameters, no annotations, and a close sibling named get_oi_buildup, the description is too sparse to fully guide an agent. The get_candle_data reference helps for format, but the agent would need to fetch another tool's schema and infer selection criteria on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does add meaning for interval, fromdate, and todate by referencing get_candle_data's format, but exchange and symboltoken are left completely unexplained, with no enums or allowed-value hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get historical open-interest (OI) data for F&O instruments.' It also references get_candle_data for format, which hints at lineage but does not explicitly distinguish this tool from the closely named sibling get_oi_buildup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Same interval/date format as get_candle_data' gives the agent useful format guidance and implies a relationship between the tools. However, it does not state when to prefer get_oi_data over get_oi_buildup or get_candle_data, leaving usage selection somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get option greeks (delta, gamma, theta, vega, IV) for all strikes of an underlying. name: e.g. 'NIFTY'. expirydate format: '25MAR2024'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| expirydate | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clearly signals a read-only operation through 'Get', and it discloses the useful result scope ('all strikes of an underlying') and the included greeks. Authentication and data freshness are not mentioned, but these are not critical for a simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the functional summary first and parameter examples second. There is no filler, repetition, or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Both required parameters are addressed with examples or formats, and the return content is named; the output schema handles the exact response shape. The description is complete enough for a low-complexity read-only tool, though explicit usage boundaries would improve it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% per-parameter descriptions, so the description must compensate. It does so by giving a concrete example for 'name' ('NIFTY') and a specific date format for 'expirydate' ('25MAR2024'), clarifying both required parameters. It stops short of enumerating valid underlying names or date edge cases, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('option greeks'), enumerates the returned fields (delta, gamma, theta, vega, IV), and narrows the scope to all strikes of an underlying. This clearly differentiates it from market-data siblings like get_market_quote or get_ltp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description: call this tool when you need option greeks for a given underlying and expiry. However, it does not explicitly state when not to use it or mention alternatives, leaving usage-boundary guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all orders placed today, with their current status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of indicating that this is a read-only operation; the verb 'Get' does imply that. However, it does not disclose details such as whether previous days' orders are returned, how the 'today' boundary is defined, or any authentication/rate-limit considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes meaning: the verb, the resource, the time scope, and the returned status detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema present, this description is complete. It states what the tool returns and the scope of the data, and no further invocation details are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing meaningful for the description to add. This is the baseline 4 for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and the resource ('all orders placed today'), and adds the relevant detail that the current status is included. It distinguishes this from market-depth order books and from trade book/positions by the 'orders placed today' scope, though it does not explicitly reference sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'today' scope gives the agent a clear temporal context for deciding when to call this tool, and the description implies it is for viewing submitted orders rather than trades or positions. It does not explicitly list exclusions or alternative tools like get_trade_book or get_individual_order_details, but the context is clear enough for a basic routing decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the day's open and net positions (intraday + carryforward).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must stand alone. 'Get' signals a read-only operation and the parenthetical clarifies the position components returned, but the description does not mention authentication/session requirements or behavior when no positions exist. The output schema supplies return structure, but on its own the description leaves some behavioral context implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one compact sentence with no filler. It front-loads the output type and then adds the two key qualifiers ('open and net', 'intraday + carryforward').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with an output schema, the description is nearly complete: it states exactly what positions are returned and the time scope. It is not a 5 because it leaves the operational context (e.g., login requirement, session/day definition) to the reader rather than stating it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is fully documented as empty, so there is no parameter meaning the description must add. A baseline of 4 is appropriate because there is nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource—'Get the day's open and net positions'—and the parenthetical '(intraday + carryforward)' adds scope that helps distinguish this from sibling tools like get_holdings. It is immediately clear what data the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the phrase 'day's open and net positions': an agent should choose this when it needs current intraday and carryforward positions. However, no explicit alternatives or exclusions are given, so the description does not actively route away from get_holdings or get_all_holdings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the logged-in user's profile: client code, name, email, exchanges enabled, products enabled, and broker.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the returned profile fields and implies an authenticated session, but it does not explicitly state that the operation is read-only, whether a valid session is required, or any other behavioral constraints. This is an adequate but minimal disclosure for a simple no-parameter read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then uses a colon to efficiently list the returned fields. Every word contributes meaning and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only profile tool with an output schema available, the description covers the essential purpose and return contents. There are no hidden inputs or complex side effects, so nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to document. The description adds value by clarifying what the profile contains, which indirectly serves the same goal. Baseline 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a specific resource ('logged-in user's profile'), and enumerates the returned fields (client code, name, email, exchanges, products, broker). This distinguishes it from all sibling tools, none of which target profile retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of retrieving the logged-in user's profile is clear and the tool is unique among siblings, so no alternative routing is necessary. It does not explicitly say 'use after login', but the phrase 'logged-in user' implies the prerequisite without causing ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current put-call ratio (PCR) across index/stock option contracts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation and scope but does not mention data source, aggregation method, refresh behavior, or whether this is a market snapshot versus a computed value. For a no-parameter tool, this is thin but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the essential action, resource, and scope. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read tool, the description is mostly complete: the action and scope are clear, and an output schema exists so return values do not need to be explained. The only gap is the lack of behavioral context like computation basis or refresh timing, but that is minor for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden on the description. The schema is trivially complete, and the description adds the scope of the PCR calculation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('current put-call ratio') with a defined scope ('across index/stock option contracts'). It clearly distinguishes this tool from siblings like get_option_greeks or get_market_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving the current PCR, but it does not explicitly state when to use it over alternatives or mention any exclusions. An agent can infer the basic use case, but there is no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available margin / funds (RMS limits): net cash, available margin, utilised margin, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'Get' signals a read-only operation, and the listed fields indicate what information is returned. However, it does not mention prerequisites such as login, data freshness, or whether this reflects real-time or end-of-day values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that quickly conveys the tool's purpose and includes concrete examples. The trailing 'etc.' is slightly vague, but overall the description is appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema available, the description is reasonably complete. It tells the agent what kind of data is returned and does not need to document arguments. It does not address authentication or distinguish the tool from get_margin, but this is a simple tool and the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden on the description. The baseline of 4 applies, as the description does not need to compensate for any missing parameter schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('available margin / funds (RMS limits)') and lists representative fields such as net cash, available margin, and utilised margin. It is clear about what the tool does, though it does not explicitly differentiate it from the sibling get_margin tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. Given that get_margin appears as a sibling and appears to overlap in purpose, the lack of any usage direction is a meaningful gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all executed trades for the day.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It clearly signals a read-only operation ('Get') and a day-limited scope, but it does not disclose whether the result is paginated, sorted, or strictly limited to the current trading session versus the calendar day.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundant restatement of the tool name. Every word adds meaning: 'all', 'executed trades', and 'for the day'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple, parameterless read operation, and an output schema exists to define the return shape. However, it leaves ambiguity about the meaning of 'the day' and gives no hint about ordering or pagination, which matters for a potentially large trade list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so there is nothing to document. The phrase 'for the day' provides a useful implicit filter that is not visible in the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('executed trades'), with a daily time scope, so an agent understands it returns today's fills. It does not explicitly contrast with get_order_book or get_positions, but 'executed trades' is specific enough to separate it from order-level and position-level tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over siblings such as get_order_book, get_individual_order_details, or get_positions. The 'for the day' clause only narrows the time range; it does not say when this tool is appropriate or when another should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a GTT rule by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| exchange | Yes | ||
| symboltoken | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Cancel' conveys mutation but nothing about side effects, idempotency, prerequisites, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no filler; the core action and key parameter are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, but the tool requires three parameters and only one is explained. Additional context about the role of symboltoken and exchange is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies 'id'. The required 'symboltoken' and 'exchange' fields are left unexplained, so an agent cannot know what values to supply beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Cancel') and resource ('GTT rule') and identifies the primary key ('by its id'). It is clearly distinguishable from sibling tools like gtt_create_rule, gtt_modify_rule, and gtt_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies you should call this when you want to cancel a GTT rule and have its ID, but it gives no explicit when-to-use guidance or alternatives. It does not differentiate this from cancel_order or explain when gtt_modify_rule might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GTT (Good Till Triggered) rule that auto-places an order when the trigger price is hit.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | Yes | ||
| price | Yes | ||
| exchange | Yes | ||
| timeperiod | No | ||
| producttype | Yes | ||
| symboltoken | Yes | ||
| disclosedqty | No | ||
| triggerprice | Yes | ||
| tradingsymbol | Yes | ||
| transactiontype | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does reveal a key non-obvious behavior—auto-placing an order later when the trigger price is hit—which is helpful. However, it omits other behavioral traits such as authentication requirements, persistence, error handling, or what happens after creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the action and resource, expands the GTT acronym, and contains no filler. Every word adds value, though the brevity does leave substantive gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter create operation with 0% schema parameter descriptions and no annotations, this description is too thin. Even though an output schema exists, the agent still lacks guidance on how to populate required fields like symboltoken, exchange, producttype, transactiontype, and disclosedqty, and gets no context about the GTT lifecycle or timeperiod behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly references triggerprice. It does not explain the meaning or valid values for exchange, producttype, transactiontype, symboltoken, disclosedqty, timeperiod, or the difference between price and triggerprice. With 8 required parameters, the description fails to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and a clear resource ('GTT rule'), and explains the core behavior: auto-placing an order when the trigger price is hit. This clearly distinguishes the tool from sibling tools like gtt_modify_rule, gtt_cancel_rule, gtt_details, and gtt_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating a new GTT rule, and the sibling context reinforces that other operations are separate. However, it does not explicitly state when to use this over place_order or the other GTT management tools, nor does it mention prerequisites like authentication or symbol selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a single GTT rule by id.
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the action ('Get details') without explicitly confirming read-only behavior, error conditions, or dependence on an existing rule, leaving important traits implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no redundant words. The action and object are front-loaded, making it immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one required parameter, and includes an output schema, so the basic invocation is well-defined. However, the absence of usage guidance, behavioral notes, or any link to sibling GTT tools makes the contextual picture slightly incomplete, though adequate for a trivial lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description needed to compensate but only says 'by id', which merely mirrors the parameter name 'rule_id'. It adds no extra meaning about the ID's format, source, or usage, failing to enrich the schema's minimal definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('details of a single GTT rule'), and a qualifier ('by id'), making its action unambiguous. It naturally differentiates from sibling GTT operations like gtt_list, gtt_create_rule, gtt_modify_rule, and gtt_cancel_rule by targeting a single rule's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing implies usage when a caller possesses a specific GTT rule ID and wants its details. However, it does not explicitly state when to prefer this over alternatives such as gtt_list, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List GTT rules. status is a list of any of: NEW, CANCELLED, ACTIVE, SENTTOEXCHANGE, FORALL, REJECTED, EXPIRED, DELETED.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| count | No | ||
| status | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only lists allowed status values and does not disclose read-only behavior, pagination, or any other operational traits. The word 'List' implies read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core purpose, and the second provides the valuable status enumeration that the schema lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema covers return values, and the description plus schema adequately convey the required status filter. However, with no annotations and no mention of pagination or usage context, the definition is only minimally adequate for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful enumeration for the status parameter, which the schema does not define as enums. However, page and count parameters are not described, leaving their semantics to be inferred from names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('List GTT rules'), which is clear and distinguishes it from siblings like gtt_create_rule, gtt_modify_rule, and gtt_details. It is unambiguous, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like gtt_details, nor any context about pagination or required status filtering. Usage is only implied by the word 'List' and the schema's required status field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify an existing GTT rule.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| qty | Yes | ||
| price | Yes | ||
| exchange | Yes | ||
| timeperiod | No | ||
| symboltoken | Yes | ||
| disclosedqty | No | ||
| triggerprice | Yes | ||
| tradingsymbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Modify an existing GTT rule.' It does not explain whether fields are overwritten, whether rules must be in a particular state, what side effects occur, or whether the modification is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler or redundancy. However, the conciseness comes at the cost of useful detail, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 9 parameters, zero schema descriptions, and no annotations. The one-sentence description is far too lean to guide an agent on required fields, update semantics, or constraints, so the overall definition is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level meaning. The agent is left to infer the roles of id, symboltoken, exchange, tradingsymbol, qty, price, triggerprice, and timeperiod from names alone, which is insufficient for a 9-parameter mutation tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Modify') and a named resource ('existing GTT rule'), clearly distinguishing the operation from creating or cancelling a rule. It does not explicitly name sibling alternatives, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: if you need to change an existing GTT rule, use this tool. No explicit guidance is provided about prerequisites, when not to use it, or how it relates to alternatives like gtt_create_rule or gtt_cancel_rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicitly (re)authenticate with Angel One using the configured client code, PIN, and TOTP secret. Normally not needed - the client logs in automatically on first use - but useful to force a fresh session or verify credentials are configured correctly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does a solid job: it reveals that login normally happens automatically, that this call creates a fresh session, and that it can be used to validate credential configuration. It does not detail side effects like session invalidation or failure behavior, but the key behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences. The first names the action and mechanism; the second provides usage guidance without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema, and a clear purpose, the description is complete. It covers what the tool does, why it might be needed, and when it can be skipped. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description adds useful context by mentioning the configured client code, PIN, and TOTP secret, even though these are not tool parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('authenticate') and a specific resource ('Angel One'), and clarifies that this is an explicit reauthentication action. It also differentiates itself from the normal automatic login behavior, making its purpose unambiguous among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says the tool is 'normally not needed' because the client logs in automatically, and gives two concrete use cases: forcing a fresh session or verifying credentials. It does not name an alternative tool, but that is less relevant since login has no direct sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminate the current Angel One trading session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and 'terminate' clearly signals a state-changing action on the session. It could add that subsequent authenticated requests will require a fresh login, but the core behavioral effect is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every word contributes semantic content. It is appropriately sized for a zero-parameter session terminator.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless operation with an output schema available, the description gives enough to call the tool correctly. A short note about reauthentication after logout would make it fully complete in a no-annotation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and there are zero parameters, so there is nothing for the description to clarify beyond what the schema already shows. This matches the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Terminate') and a clear resource ('current Angel One trading session'), and is readily distinguished from siblings like login by naming the action that ends the session. It is not a tautology of the tool name, despite the name matching the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'current' indicates that this tool is for ending an existing authenticated session, which gives clear usage context. It does not explicitly name login as the counterpart or list when not to use it, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify an existing open order. All identifying fields (tradingsymbol, symboltoken, exchange) must match the original order.
| Name | Required | Description | Default |
|---|---|---|---|
| price | No | ||
| orderid | Yes | ||
| variety | Yes | ||
| duration | Yes | ||
| exchange | Yes | ||
| quantity | Yes | ||
| ordertype | Yes | ||
| producttype | Yes | ||
| symboltoken | Yes | ||
| triggerprice | No | ||
| tradingsymbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses an important behavioral constraint: all identifying fields must match the original order. It also restricts modifications to open orders. Still, it does not mention permission requirements, what happens to the original order, or rejection/failure behavior, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The action is front-loaded, and the second sentence adds a necessary constraint that directly affects invocation. Every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 9 required fields, no annotations, and no enum values, the description is not sufficient for reliable invocation. The only contextual guidance is the identifying-fields constraint; required domain fields such as variety, ordertype, and producttype are undocumented, so an agent would still face significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates for only three of eleven parameters by saying tradingsymbol, symboltoken, and exchange must match the original. The meaning of domain-specific parameters like variety, ordertype, producttype, duration, and triggerprice is left entirely to inference from field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action and target ('modify an existing open order') rather than just restating the tool name. The 'open order' scope distinguishes it from siblings like place_order, cancel_order, and convert_position, making its purpose immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when an existing order is open and needs to be changed. However, it does not explicitly state when not to use it or point to alternatives such as cancel_order for closed or filled orders, leaving some usage inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an order.
variety: NORMAL | STOPLOSS | AMO | ROBO transactiontype: BUY | SELL exchange: NSE | BSE | NFO | MCX | BFO | CDS ordertype: MARKET | LIMIT | STOPLOSS_LIMIT | STOPLOSS_MARKET producttype: DELIVERY | CARRYFORWARD | MARGIN | INTRADAY | BO duration: DAY | IOC price/triggerprice: required for LIMIT/STOPLOSS order types (as strings, e.g. "199.50") squareoff/stoploss/trailingStopLoss: only used when variety=ROBO (bracket order)
| Name | Required | Description | Default |
|---|---|---|---|
| price | No | 0 | |
| variety | Yes | ||
| duration | No | DAY | |
| exchange | Yes | ||
| ordertag | No | ||
| quantity | Yes | ||
| stoploss | No | ||
| ordertype | Yes | ||
| squareoff | No | ||
| producttype | Yes | ||
| symboltoken | Yes | ||
| triggerprice | No | ||
| tradingsymbol | Yes | ||
| transactiontype | Yes | ||
| trailingStopLoss | No | ||
| disclosedquantity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden and it partially does: it discloses that placing an order is a live action and that certain parameters only apply to bracket/ROBO orders. However, it does not describe execution side effects, authentication requirements, idempotency, or failure behavior, leaving meaningful gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a one-line purpose followed by a scannable field-value list. Every line conveys a distinct constraint or value set, so nothing feels redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter order-placement tool with no annotations, the description supplies essential enums and conditional dependencies but omits the order lifecycle (e.g., what response/order ID is returned, whether orders can be placed outside market hours) and leaves ordertag and disclosedquantity semantically unaddressed. It is enough to construct a valid request with some domain knowledge, but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema property descriptions are absent (0% coverage), and the description compensates by enumerating valid values for variety, transactiontype, exchange, ordertype, producttype, and duration, and by explaining conditional requirements for price, triggerprice, squareoff, stoploss, and trailingStopLoss. It does not explicitly define tradingsymbol, symboltoken, quantity, ordertag, and disclosedquantity, but most of those are self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'Place an order' identifies a specific action on a specific resource, making the core purpose immediately clear. It does not explicitly contrast with sibling tools like modify_order or cancel_order, but the verb-plus-resource phrasing is enough for an agent to distinguish this from those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives conditional parameter rules (e.g., price/triggerprice required for LIMIT/STOPLOSS; squareoff/stoploss/trailingStopLoss only for ROBO), but it gives no guidance on when to choose place_order versus alternatives such as convert_position or gtt_create_rule. No exclusions or alternative-selection conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for the tradingsymbol and symboltoken of an instrument by name, e.g. exchange='NSE', searchscrip='INFY'. Use this to resolve symboltoken before placing orders or requesting quotes.
| Name | Required | Description | Default |
|---|---|---|---|
| exchange | Yes | ||
| searchscrip | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It states what is returned conceptually and provides an example, but it does not disclose matching semantics (e.g. exact vs partial, case sensitivity), whether multiple results may be returned, or what happens on no match. This is a minor gap for a simple lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the action and result, the second gives a concrete example and usage context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two required parameters and an output schema exists, the description provides enough operational context for a correct call. It covers the search purpose, the crucial use case, and a realistic example. Minor omissions like exchange options and error behavior are not necessary for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by showing exchange='NSE' and searchscrip='INFY', but it does not define valid exchange values or the expected format/pattern for searchscrip beyond an example. Meaningful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and names the exact resource and result fields ('tradingsymbol and symboltoken of an instrument by name'). The example and the phrase 'before placing orders or requesting quotes' help distinguish it from price/quote tools like get_ltp and get_market_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: to resolve symboltoken before placing orders or requesting quotes. It does not name alternatives or exclusion conditions, but the context is clear enough for correct routing among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target distinct actions and resources—orders, positions, holdings, GTT rules, market data, and analytics are clearly separated. Minor overlap exists between get_holdings and get_all_holdings, and between get_ltp and get_market_quote, but descriptions clarify their scope.
The naming mostly follows a clear verb_noun snake_case pattern, such as place_order, cancel_order, get_positions, and search_scrip. The gtt_* tools deviate by leading with the domain prefix instead of the verb, and a few names like get_all_holdings vs get_holdings are slightly inconsistent, but overall the pattern is predictable.
With 32 tools, the surface feels heavy and exceeds the 25-tool threshold that typically signals over-expansion. Many market-data and analytics tools could be consolidated or grouped, though the breadth is understandable for a full brokerage API.
The tool surface covers the core brokerage lifecycle well: authentication, order placement/modification/cancellation, order and trade books, positions, holdings, GTT rules, margin checks, and charge estimation. Some gaps exist such as historical order history or bulk order capabilities, but agents can accomplish most common trading workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Trade 16 crypto exchanges + MetaTrader 5 from your AI assistant via one MCP connection.
MCP server exposing the Backtest360 engine API as tools for AI agents.
Hosted MCP for stocks, options, Greeks, brokers, order previews, alerts, and workflows.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pyalgobot/angelone-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
