Indian Broker MCP Server

by Sparker0i

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but get_positions and get_fno_positions could be confused since F&O positions are a subset of positions. Similarly, get_holdings, get_mutual_funds, get_us_stocks, and get_gold are differentiated by asset type, which is clear. Overall, the tools are separable by their descriptions.
Naming Consistency3/5
The naming convention is mixed: some tools follow a verb_noun pattern (e.g., get_holdings, search_stock), while others use a noun_verb pattern (e.g., broker_connect, broker_disconnect). This inconsistency is not chaotic but could be more uniform. Both patterns use lowercase with underscores, so it's readable.
Tool Count5/5
14 tools is appropriate for a broker aggregation server. The count is well within the typical 3-15 range, and each tool addresses a specific aspect of broker connectivity, data retrieval, or usability. None feel redundant.
Completeness3/5
The tool set covers connection management, holdings, positions, and orders, but misses obvious financial data like cash balances and trade history. It also lacks any trading or order placement capabilities, which could be expected for a broker MCP, though it may be intentionally read-only. The core read-only aggregation surface is present, but notable gaps exist.
Average 3.1/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'connected brokers' but does not explain behavior when no broker is connected, whether holdings are aggregated across brokers, or any permission/error scenarios. Minimal context is added beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the action and resource. It earns its place structurally, though it is too terse to cover necessary semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema, yet the description is only a short phrase. It does not describe return shape, error cases, or how broker filtering works, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'broker' parameter at all. With 0% schema description coverage, the description should compensate by explaining how broker selection and the 'all' default work, but it provides no parameter semantics beyond what the enum values themselves imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('stock holdings') with a source ('connected brokers'), clearly stating what the tool does. It distinguishes from siblings like get_orders or get_mutual_funds, though get_positions could overlap and is not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus get_positions or get_portfolio_summary, nor are prerequisites such as a successful broker connection mentioned. Usage is only implied by the tool's name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'current price quote' but omits important traits like whether the quote is real-time or delayed, whether it depends on broker availability, or if any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. It is appropriately short for a straightforward tool, prioritizing clarity over verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and the tool has two parameters, the description should explain return values and broker semantics. It provides only minimal information, leaving the agent uncertain about how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (symbol is described, broker is not). The description adds no extra meaning for the broker parameter, which is crucial for selecting the brokerage. It does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get current price quote for a stock' with a specific verb and resource. However, it does not differentiate this from sibling tools like get_us_stocks or get_gold, which may also return quotes for different asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention broker context, whether it requires a connected broker, or how it differs from other quote-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it opens a browser and records specific data, but with no annotations, it fails to disclose side effects, whether the operation is read-only, whether it requires user interaction, or what happens after recording. The behavioral burden falls entirely on the description, and it is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core action and targets. It is concise and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is incomplete. It does not explain what the tool returns, how the recorded data is stored or used, or how the optional 'url' parameter interacts with the default dashboard behavior. The tool's complexity warrants more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description adds no parameter-level meaning beyond what the schema already provides. The schema documents 'broker' via an enum and 'url' as a starting URL, but the description does not clarify how these parameters affect the recording behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records navigation patterns, XHR requests, and DOM snapshots for a broker. The verb 'record' and the specific artifacts make the purpose clear, but it does not explicitly differentiate from siblings like broker_connect or broker_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as broker_connect or get_holdings. There is no mention of prerequisites, when not to use it, or how it fits into the broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only discloses that a browser is opened for login, but omits the cookies method, potential need for user interaction, and post-login session behavior, making it insufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the main action with no wasted words. While it omits details, that is a completeness concern, not a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and low schema coverage, the description leaves significant gaps: it does not explain the cookies method, prerequisites, return behavior, or when browser interaction is required. This is inadequate for a 3-parameter tool in a broker workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only cookies has a description). The description adds no parameter-level meaning, failing to explain the broker enum or the method parameter, and does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool connects to an Indian broker, a specific verb and resource, and distinguishes it from sibling tools like broker_disconnect and broker_status. The appended 'by opening a browser for login' is accurate for the default method and does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as broker_status or broker_disconnect. The description only implies usage for connecting, without explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. 'Fetch' implies a read operation, but the description does not explicitly state that it is read-only, whether it touches all brokers by default, or any other behaviors. The minimal text provides little beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It places the verb at the start and is appropriately short for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool with one optional parameter and no output schema, the description is too scant. It fails to explain the broker parameter, differentiate from the broader get_positions tool, or clarify what the agent should expect in the response. More context is needed for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'broker' with an enum but no description (0% schema description coverage). The description does not mention the broker parameter at all, leaving the agent without any explanation of how to filter results or what the default behavior is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and identifies the resource 'F&O positions' from 'connected brokers', making the tool's purpose clear. It is more specific than siblings like get_positions, though it doesn't explicitly distinguish between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the tool name and description: use this when you need F&O (derivatives) positions. However, there is no explicit guidance on when to use this versus alternatives like get_positions, or any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions 'connected brokers' but does not explain what happens if none are connected, the meaning of the default 'all', or any limitations. The non-mutating nature is implied by 'Fetch' but never explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. There is no wasted content, and it is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description is adequate but leaves gaps. It does not clarify whether 'positions' includes F&O (given the get_fno_positions sibling), how the default 'all' behaves, or what the response structure looks like. These are notable omissions for an agent selecting the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'broker' parameter beyond what the schema's enum and default already show. The schema is self-explanatory for a simple parameter, but the description adds no value in clarifying how the broker selection affects the returned data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Fetch'), resource ('open positions'), and scope ('from connected brokers'). It distinguishes from siblings like get_holdings and get_orders, but does not explicitly contrast with get_fno_positions, leaving ambiguity about whether positions include derivatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like get_fno_positions or get_holdings. It also does not mention prerequisites, such as ensuring brokers are connected, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral disclosure burden. 'Fetch' implies a read-only operation, but no details are given about return format, error handling, rate limits, or authentication requirements. 'Connected brokers' hints at a prerequisite but does not explain behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and efficient. Every word earns its place, with no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description fails to explain return values or usage nuances. It is minimally sufficient for a simple read operation but lacks completeness regarding response structure and operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'broker' parameter at all. While the schema's enum and default provide some clarity, schema description coverage is 0%, and the description adds no semantic value beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches mutual fund holdings, using a specific verb and resource. It distinguishes from sibling tools like get_holdings (general) and get_us_stocks/gold by specifying 'mutual fund'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_holdings. The phrase 'from connected brokers' implies a prerequisite but does not explain when this tool is preferred or what to do if brokers are not connected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It discloses only the search action and criteria, but nothing about result format, pagination, ranking, or potential limitations. This is minimal and not contradictory, but insufficient for an agent to anticipate the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no excess words. It communicates the essential purpose clearly and efficiently, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too sparse. It does not indicate whether the response is a list or single match, how results are ranked, or how this tool fits into a broker interaction workflow. This is a minimal viable description but not complete enough for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: only 'query' has a description, while 'broker' has none. The tool description does not explain the broker parameter or when/how to use it. 'By name or symbol' merely restates the query description, adding no new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for a stock or mutual fund by name or symbol.' It uses a specific verb (search) and resource (stock or mutual fund), and differentiates from siblings like get_quote or get_holdings by focusing on discovery rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to search vs. directly fetching a quote or holdings, nor does it specify any exclusions or prerequisites. Usage is only implied by the term 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavior. It only states that data comes from connected brokers, but does not describe return format, aggregation across brokers, error behavior, or any side effects. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the verb, resource, and source efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only holdings tool, the core purpose is clear, but without an output schema or annotations, the description does not specify what a returned holding includes (symbol, quantity, etc.) or the behavior when no brokers are connected. It is minimally viable but lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'broker' parameter at all, and schema description coverage is 0%. Although the schema's enum values and default are self-explanatory, the description fails to compensate or add any meaning beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with the resource 'US stock holdings' and source 'connected brokers', making the tool's purpose unambiguous. It clearly distinguishes this from sibling tools like get_holdings, get_mutual_funds, or get_gold by restricting to US stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to choose this tool over alternatives such as get_holdings or get_positions. The 'US stock holdings' phrasing implies a use case, but no prerequisites, exclusions, or alternative comparisons are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description only states the action and scope; it does not mention read-only nature, error handling for disconnected brokers, or response format. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word is purposeful, with no redundancy or fluff. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and only one parameter, the description is too minimal to provide complete context. It lacks guidance on usage, behavioral traits, and parameter semantics. The description is enough to convey the basic purpose but not the necessary surrounding context 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'broker' with enum values but zero description coverage. The tool description does not explain how this parameter affects the result, such as filtering by specific broker or defaulting to 'all'. The phrase 'connected brokers' loosely relates to the parameter but adds no meaningful semantics beyond the schema's enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' with a clear resource 'today's order history' and scope 'from connected brokers'. It clearly distinguishes itself from sibling tools like get_holdings and get_positions by focusing on order history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (requires connected brokers, fetches orders for today) but provides no explicit guidance on when to use this tool versus alternatives like get_positions or get_portfolio_summary. No exclusions or alternative tool mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must handle full behavioral context. It mentions 'aggregated' and 'across all connected brokers', suggesting data is combined, but it does not disclose whether the operation is read-only, whether it requires existing broker connections, or whether the summary is real-time vs delayed. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that conveys the essential scope ('across all connected brokers') without any filler. It is front-loaded and every word contributes meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what the summary contains (e.g., total value, asset allocation, per-broker breakdown). The current wording is too vague for an agent to know what response to expect or how to interpret the result, making the tool under-specified for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description has no need to explain parameter meaning. The schema coverage is effectively 100% (vacuously), and the description does not add unnecessary detail. Consequently, this dimension is at the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aggregated portfolio summary across all connected brokers' clearly indicates a read operation that returns a consolidated view of the user's total portfolio, distinguishing it from more specific sibling tools like get_holdings or get_positions. The lack of an explicit verb is compensated by the tool name starting with 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for obtaining a high-level overview across all brokers, but it does not explicitly state when to use it versus alternatives like get_holdings or get_mutual_funds. There is no mention of when not to use it or which sibling tools to prefer for detailed breakdowns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only says 'Show connection status' which implies a read-only operation but provides no details on return format, required authentication, or any side effects. This is insufficient for an agent to understand the tool's behavior beyond the surface-level action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, completely free of redundancy. It states the purpose efficiently without wasted words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no annotations, no output schema), the description adequately conveys the essential purpose. It could benefit from indicating what kind of statuses are returned, but for a status-check tool, 'connection status' is reasonably self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the tool has zero parameters, the schema is empty. The description adds meaning by clarifying the scope ('for all brokers'), which is relevant to the absence of parameters. Per the rubric, a baseline of 4 is appropriate for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show connection status for all brokers' with a specific verb 'Show' and a specific resource. It distinguishes from sibling tools like broker_connect and broker_disconnect, which are about establishing and terminating connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusion conditions. It simply states what the tool does without helping the agent decide between this and the connection management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive side effect of wiping session data, which is crucial given the absence of annotations. However, it does not elaborate on broader consequences, such as impacted orders or token invalidation, which could be important for the agent to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and notes the side effect. It contains no redundant information and is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema or annotations, the description covers the core action and side effect. It lacks details on return values or error conditions, but those are less critical for a disconnect operation, and the sibling tools provide enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'broker' parameter with an enum, and the description does not add specific semantic meaning beyond the schema. It mentions 'a broker' in general terms but does not explicitly tie the parameter to the action or describe selection implications, failing to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'disconnect' and identifies the resource as 'a broker', clearly distinguishing it from sibling tools like broker_connect and broker_status. The additional phrase 'wipe session data' further clarifies the scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool or when not to. It does not mention that it is the inverse of broker_connect or that it should be used when ending a broker session, leaving usage to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It does disclose the prerequisite of connected brokers and the read-only nature of 'Fetch', but it does not describe what happens if no brokers are connected or other failure modes. This gives partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It effectively states the tool's purpose without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only one enum parameter and no output schema, the description provides sufficient context. It names the resource and the prerequisite of connected brokers, which covers the essential use case. It does not mention return format, but that is not required when output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'broker' parameter at all. Although the enum values are self-explanatory and a default exists, the description should have compensated for the lack of schema coverage but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Fetch) and names the resource (gold holdings) along with the scope (from connected brokers). It clearly distinguishes itself from sibling tools like get_holdings and get_mutual_funds by specifying 'gold'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving gold holdings, but it does not explicitly state when to prefer this over the more general get_holdings, nor does it mention any exclusions or alternatives. The context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![indian-stock-mcp-agent MCP server](https://glama.ai/mcp/servers/Sparker0i/indian-stock-mcp-agent/badges/card.svg)](https://glama.ai/mcp/servers/Sparker0i/indian-stock-mcp-agent)

Score Badge

Copy to your README.md:

[![indian-stock-mcp-agent MCP server](https://glama.ai/mcp/servers/Sparker0i/indian-stock-mcp-agent/badges/score.svg)](https://glama.ai/mcp/servers/Sparker0i/indian-stock-mcp-agent)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sparker0i/indian-stock-mcp-agent'

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