mcp-ibkr-agent

by pedrobraiti

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.8.0
Disambiguation5/5
Each tool serves a distinct purpose: account info, quotes, order placement (different order types), order management, preview, history, reconciliation, and session status. Descriptions clearly differentiate even similar-sounding tools like 'open_orders' and 'order_status'.
Naming Consistency5/5
Tool names follow a consistent snake_case verb_noun pattern (e.g., account_summary, cancel_order, get_quote). A few are single verbs (buy, sell) but that is standard for basic actions and does not break consistency.
Tool Count4/5
With 20 tools, the server covers a wide range of trading operations without being excessive. Some tools (e.g., get_quote and get_quotes) could be merged, but the count is still appropriate for the domain.
Completeness4/5
The tool set covers core trading workflows: account info, quotes, various order types, order management, preview, history, and reconciliation. Minor gaps like order modification are absent, but the set is largely complete for common trading tasks.
Average 4/5 across 20 of 20 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 62 commits in the last 12 weeks
- Last stable release on July 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits like read-only nature, data freshness, or authentication requirements. The minimal description fails to provide such context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence, but it could be more informative without being wordy. It is front-loaded and avoids 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 zero parameters, no output schema, and many sibling tools, the description is incomplete. It does not explain the output format or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds no value beyond the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open positions in the account' clearly indicates the tool retrieves open positions, but it is vague and does not differentiate from sibling tools like 'portfolio' which may also list positions.
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 'portfolio', 'account_summary', or 'close_position'.
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 provided. The description only lists output fields but does not disclose behavioral traits like whether the operation is read-only, requires authentication, or has any side effects. For a tool with no annotations, this 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?
Single sentence, front-loaded with the tool's purpose, no unnecessary words. Extremely concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is minimal. It lists three fields but does not clarify if these are all returned fields or just examples, nor does it describe the return format. Adequate for a simple tool but leaves some ambiguity.
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?
Input schema has zero parameters, so schema description coverage is 100%. According to guidelines, baseline is 4. The description does not need to add parameter details because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns an account summary with specific fields (available funds, net liquidation, buying power). The verb 'summary' implies retrieval, distinguishing it from sibling tools like 'portfolio' or 'positions' that provide different granularity.
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 such as 'portfolio' or 'positions'. Missing context on whether this is a high-level snapshot or if it includes additional details, and no exclusions for specific scenarios.
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 disclose behavioral traits. It states it lists active orders but does not mention if it is read-only, what authentication is needed, or any side effects. It adds unit contract info but lacks broader 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 two concise sentences, front-loading the primary purpose. No extraneous information; every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and one data format detail. However, with no output schema and no annotations, it lacks information about the structure of the returned data (e.g., list of orders with fields, pagination) and completeness for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds value by clarifying the unit contract (filled_quantity in SHARES, filled_cash in US$). This compensates for the lack of parameter info.
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 that the tool lists active (live) orders. The verb 'lists' and specific resource 'active orders' make the purpose clear. It does not explicitly differentiate from siblings like 'order_status' or 'trade_history', but the name and description are sufficient.
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 like 'order_status' (for a single order) or 'trade_history' (for past trades). The description mentions unit contract consistency with 'order_status', but this is more about data format than usage context.
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 provided, so the description must disclose all behavioral traits. It explains the two trail methods and side logic, but does not disclose whether the order becomes a market order when triggered, what happens if both trail_amount and trail_percent are set, order duration, or cancellation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and well-structured, using line breaks and bullet-point style. It conveys key information without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the core functionality but lacks details on execution behavior, potential errors, and order lifecycle. It is adequate for a simple trailing stop order but not fully comprehensive for all edge cases.
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?
Schema coverage is 0%, so description carries full burden. It explains trail_amount and trail_percent as alternatives (though not explicit about mutual exclusivity), clarifies side with an example, and mentions quantity. Symbol is self-explanatory but not described. This adds significant value beyond the schema.
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 it places a trailing stop and explains what a trailing stop does ('follows the price, locks in gains'). It distinguishes from a regular stop (sibling stop_order) by using 'trailing' and describing the trail mechanism, but does not explicitly name the alternative.
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 gives guidance on side ('trailing stop-loss on a long position is a SELL') and explains the two trail methods, but does not specify when to use a trailing stop versus a regular stop order or other order types. No when-not-to-use or alternative names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description only says 'Cancels an open order.' No disclosure of side effects (e.g., irreversibility), error handling (e.g., invalid order_id), or state changes beyond cancellation.
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?
Single sentence, perfectly concise, no filler. Essential information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, description covers core action. Lacks behavioral details like idempotency or error responses, but still mostly adequate for agent 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?
Only one parameter (order_id). Description merely repeats 'by its order_id' without adding format, source, or validation rules. Schema coverage is 0%, so description fails to add meaning beyond 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?
Description states verb 'Cancels' and resource 'open order by its order_id.' Clearly distinguishes from siblings like 'preview_order' or 'order_status'.
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?
No explicit when-to-use or alternatives are provided. Usage is implied by name and description, but no guidance on when not to use or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states 'current quote' and lists fields (last/bid/ask), but does not disclose data freshness, source, permission requirements, or error behavior. This is adequate for a simple read but lacks depth.
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 covers the essential purpose without any wasted words. It is well-structured and front-loaded.
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 simplicity of the tool (1 parameter, no output schema, no annotations), the description is insufficient. It does not explain the return format, possible error states, or what happens for invalid symbols. A financial data tool should provide more context on the returned data structure.
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 only adds 'US stock symbol' to the parameter, providing minimal extra meaning beyond the schema's 'Symbol' title. It does not explain format, constraints, or examples.
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 returns a current quote (last/bid/ask) for a US stock symbol, which is a specific verb+resource combo. It also implies a distinction from the sibling tool 'get_quotes' (plural) which likely handles multiple symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by limiting to 'a US stock symbol', but it lacks explicit guidance on when to use this vs 'get_quotes' or other price-related tools. No when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'one snapshot' (implying non-streaming) and 'cheaper', but does not disclose rate limits, data freshness, or error behavior. Minimal transparency beyond 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, efficient sentence with a clarifying parenthetical. No redundant words; front-loaded key information.
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 one parameter and no output schema, the description covers the essentials (what, when, benefit). Lacks details on output structure or limitations (e.g., max symbols), but still reasonably complete for its complexity.
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?
With 0% schema description coverage, the description should elaborate on the 'symbols' parameter. It specifies 'US stock symbols' but lacks details on format, case sensitivity, or maximum count. Adds marginal meaning.
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 verb ('get quotes'), resource ('several US stock symbols at once'), and differentiates from sibling tool 'get_quote' by emphasizing batch retrieval and cost benefit for watchlists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for multiple symbols, cheaper snapshot) and distinguishes from likely single-quote sibling, but does not explicitly exclude single-symbol scenarios or mention alternatives.
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 should fully disclose behavior. It states the tool indicates market open status, but does not specify return format, latency, caching, or whether 'right now' is real-time or with delay.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence containing the essential information, no waste. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is minimally adequate. It could be improved by specifying the output type (e.g., boolean or string) or any caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. Baseline is 4; no additional parameter info is needed.
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 ('Indicates') and resource ('whether the US market is open (RTH) right now'). It clearly distinguishes the tool's purpose from siblings like buy/sell or account_summary.
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 checking market status before trading, but provides no explicit guidance on when to use versus alternatives like session_status, nor when not to use it.
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?
With no annotations, the description carries full burden. It discloses it is a read operation ('Reads the local trade journal') and is local-only ('Does not hit IBKR'). However, it does not detail output format, whether data is real-time, or how 'recent' is defined. Overall, good transparency for a simple local read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences to convey core purpose and behavior. Every sentence adds value, and the key phrase 'answers what did my agent do?' is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter and no output schema or annotations, the description adequately explains what the tool returns (audit log of order attempts) and where it reads from (local trade journal). However, it could clarify what 'recent' means and whether limit applies to maximum entries or pagination. It is minimally sufficient.
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 only parameter 'limit' has no description in the schema (0% coverage) and is not mentioned in the tool description. The description does not explain its purpose, default, or effect on results. This fails to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is an audit log of recent order attempts (buys, sells, dry-runs, blocks) and answers 'what did my agent do?'. It distinguishes itself from sibling tools like buy/sell (execution) and account_summary (overview) by specifying it reads the local trade journal and does not hit IBKR.
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 reviewing recent actions and notes it does not hit IBKR (suggesting low cost), but does not explicitly state when to use instead of alternatives like positions, portfolio, or open_orders. It lacks exclusions or alternative recommendations.
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?
With no annotations, the description fully describes behavior: polling, terminal states, timeout cap, timed_out flag, inactive nuance, and unit conventions. It does not mention rate limits or side effects, but is still transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs, front-loaded with purpose and key states, followed by details. Efficient without redundancy, though slightly verbose in the second paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and moderate complexity, the description covers terminal states, timeout behavior, inactive interpretation, and units. It does not address error handling or authentication, but is sufficient for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains timeout_seconds cap at 120 and return fields (timed_out, filled_quantity, etc.) which aid understanding. However, order_id parameter lacks format hints, and parameter-specific details are minimal.
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 polls an order until a terminal state or timeout, with specific verbs and resource. It distinguishes from sibling tools like order_status by emphasizing the polling and loop closure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is for closing the confirm-the-fill loop, implying use after placing an order, and not for simple status checks. It mentions timeout cap and inactive ambiguity, but lacks explicit when-not-to-use alternatives.
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?
Details OCO mechanism, default market vs limit entry, and per-leg return format. Lacks edge cases like unfilled entry, but given no annotations, it provides solid behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear structure: purpose, then behavior details, then return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main interaction and output labels. No output schema, so description's return info is helpful. Missing failure modes (e.g., entry not filled) but sufficient for primary use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains key parameters (entry_limit_price, take_profit, stop_loss, quantity, side is implied via price direction). Could explicitly state side and symbol but adds meaningful behavior context.
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 places an entry order with OCO take-profit and stop-loss exits, distinguishing it from sibling tools like buy, sell, or stop_order which lack both exits.
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 use for bracket orders but does not explicitly state when to use it versus alternatives (e.g., placing separate orders) or provide when-not conditions to avoid ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it reads position size, sends opposite order, and explains eventual consistency and failure mode (closed=False). This provides excellent transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with two paragraphs, front-loading the core action. It could be slightly more streamlined, but it efficiently conveys important behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description covers the tool's purpose, behavior, edge cases, and alternative usage. It is complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description mentions 'symbol' implicitly but doesn't add extra detail beyond the schema's required field. For one parameter, more elaboration on format or constraints would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Closes 100% of a symbol's position' with specific verb and resource. It distinguishes from sibling 'sell' by specifying full closure and exact fractional quantity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use (closing entire position) and mentions the eventual consistency issue and fallback to 'sell'. It could explicitly list when not to use, but the guidance is effective.
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 term 'snapshot' implies a read-only operation, which is transparent about the behavioral trait. Since no annotations are provided, the description adequately conveys the non-destructive nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the key phrase 'Combined snapshot', concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains what the tool returns without missing critical information, given the simplicity of the tool and absence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters (0 params, 100% schema coverage), the description adds value by specifying what the tool returns (account summary, open positions, total unrealized P&L), which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it provides a combined snapshot of account summary, open positions, and total unrealized P&L, using specific verbs ('snapshot') and resources, which distinguishes it from sibling tools like account_summary and positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when a consolidated view is needed, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusion criteria or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses the tool's behavior and return values, including details like account_type being ground truth from IBKR's isPaper, trade_stops being active reasons not to trade, and the advisory safe_to_trade flag. No annotations are provided, so the description carries the full burden and does so excellently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by detailed bullet points. It is somewhat verbose but every sentence adds value. Could be slightly more concise, but overall well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description fully explains all return fields: identity, posture, warnings. It covers everything needed for an agent to understand and use the tool correctly. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so baseline 4 applies. The description does not need to explain parameters, but it adds meaning about the output, which is valuable given no output schema. The description effectively communicates what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to check trading posture and which account is live. It starts with a direct question 'am I safe to trade right now?' and explains it returns identity, account info, and safety indicators. This distinguishes it from sibling tools that perform actions like buying or selling.
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 an unattended caller to self-gate and mentions 'safe_to_trade', but it does not explicitly state when to use this tool versus alternatives. It provides context but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavior: triggers a market order (or limit order if limit_price given) on stop_price hit. No annotations, so description handles transparency well, but could note order validity.
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?
Three concise, front-loaded sentences with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 5-param tool with no output schema; covers order type and parameter behavior, but could mention return value or order lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains side, stop_price, limit_price, and quantity meaningfully. Symbol is not explained but is standard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Place a STOP order' and the trigger behavior, distinguishing it from siblings like bracket_order or trailing_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains side usage for stop-loss and optional stop-limit, but does not explicitly mention when not to use or compare with alternatives.
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?
With no annotations, the description carries the full burden. It discloses the blocking mechanism, the clearing of blocks for resting orders, and the risk of doubling orders if missing ones are blindly resolved. It also explains the safety layer's role, providing sufficient 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 concise yet complete, with each sentence adding value. It is well-structured: main action, context, mechanism, and parameter usage. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (safety-critical reconciliation) and lack of annotations/output schema, the description covers the problem, behavior, parameter, and recommended workflow. It does not describe return values, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, resolve_missing, has no schema description (0% coverage), but the description adds clear meaning: setting it to true clears the block for not-found orders only after verification via positions/trade_history. This adds critical context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reconciles dispatched-but-unconfirmed orders against IBKR's open orders, explaining the specific scenario (timeout/crash) and action. It distinguishes itself from sibling tools like cancel_order or order_status by addressing a unique problem of blocked resends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (after timeout/crash when an order may have landed without journaling) and provides guidance on handling missing orders (recommending verification before setting resolve_missing=true). It does not explicitly mention when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears the transparency burden. It details that 'filled_quantity' is always in shares, 'filled_cash' only present on cash_amount orders, and explains the 'quantity_is_estimate' flag's implications. Fully discloses output format and edge cases.
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?
Four concise sentences, each adding distinct value. Front-loaded with the main purpose. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains return fields, units, and special cases. It addresses usage context relative to siblings and provides necessary warnings. Complete for a status-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter is 'order_id', which is self-explanatory. Schema coverage is 0%, but description adds no further details about the parameter itself. However, the parameter's purpose is obvious from context, so score is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns status (state, filled quantity, average price) for a specific order by order_id. It distinguishes itself from sibling tools like 'positions' by noting eventual consistency, and from 'wait_for_fill' by being a status check rather than a wait action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using after 'buy'/'sell' to confirm fill, contrasts with 'positions' which lags, and warns not to use 'quantity_is_estimate' for exit sizing. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behavioral constraints: IBKR restriction on cashQty for sells and guidance for dollar amount orders. It lacks return value info but is otherwise 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?
Four sentences, front-loaded with core instruction, no unnecessary words. Efficiently packs key constraints and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 params, no output schema, and sibling tools, the description is complete: covers usage, constraints, and related tools for alternate scenarios.
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?
Adds meaning beyond schema: explains quantity as fractional ok, and limit_price behavior (omit for market, pass for limit). With 0% schema coverage, this is valuable context.
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 sells a specified quantity of shares, with fractional shares allowed. It distinguishes between market and limit orders by parameter usage, and references sibling tools like close_position for full position exit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to omit or include limit_price for market vs limit orders. Warns against using cashQty for sells (buy-only) and directs to close_position for full exit or get_quote for dollar amount conversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses limit order confirmation blocking, cash_amount buy returns 'is_cash_quantity', fill reporting in shares and dollars, and protective stop sizing.
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?
Concise but information-dense. Uses bullet-like structure to separate parameter rules and behavioral notes. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return fields (is_cash_quantity, filled_quantity, filled_cash). Covers parameter semantics, usage rules, and behavioral notes comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. Clearly explains each parameter's meaning and constraints (exclusive or, limit_price requires quantity, cashQty market-only).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool buys a security. Distinguishes market vs limit orders, cash vs share quantity. Differentiates from siblings like 'sell' and 'bracket_order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions on when to use cash_amount vs quantity, when to include limit_price. Lacks direct comparison to sibling tools but context makes it clear this is for simple buys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: it uses IBKR's whatif, returns margin/commission/warnings, and does not send the order. Parameter usage is also detailed, covering side, size options, and limit_price requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second explains parameters. Front-loaded, no extraneous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema), the description covers everything needed: what the tool does, when to use it, how to set parameters, and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description compensates by explaining that side is 'BUY' or 'SELL', size can be cash_amount (USD) or quantity (shares), and limit_price is for LIMIT orders needing quantity. This adds crucial meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Preview an order's impact (margin, estimated commission, warnings) WITHOUT sending it.' It specifies the action (preview), the resource (order impact), and distinguishes it from executing orders like buy/sell siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'before committing,' indicating when to use this tool. It does not list alternatives or exclusions, but the context of sibling tools (e.g., buy, sell) makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![agentic-trading-mcp MCP server](https://glama.ai/mcp/servers/pedrobraiti/agentic-trading-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pedrobraiti/agentic-trading-mcp)

Score Badge

Copy to your README.md:

[![agentic-trading-mcp MCP server](https://glama.ai/mcp/servers/pedrobraiti/agentic-trading-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pedrobraiti/agentic-trading-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pedrobraiti/agentic-trading-mcp'

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