ib-async-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool has a distinct purpose with clear boundaries, such as 'cancel_order' vs 'cancel_all_orders', 'get_account_summary' vs 'get_account_values', and 'place_order' vs 'what_if_order'. The descriptions specify unique functions, preventing agent misselection.
Naming Consistency5/5All tools follow a consistent verb_noun pattern (e.g., 'calculate_implied_volatility', 'get_historical_data', 'place_order'), with no deviations in style or convention. This predictability aids agent tool selection and understanding.
Tool Count3/5With 33 tools, the count is borderline high for an MCP server, potentially overwhelming for agents. While the domain (Interactive Brokers trading) is complex, it may benefit from consolidation or categorization to improve usability.
Completeness5/5The toolset comprehensively covers the trading domain, including connection management, contract creation, market data, order placement, account information, and analytics. No obvious gaps exist for core workflows, from setup to execution and monitoring.
Average 2.7/5 across 33 of 33 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full disclosure burden on the description. The text adds no behavioral context regarding read-only safety, error handling (what if symbol not found?), return format structure, or rate limiting. It does not confirm the implied read-only nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While brief (4 words), the single sentence fails to earn its place by being specific. It wastes the agent's attention with vague language ('detailed information') that could have specified the domain (financial instruments) or key parameter requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, complex financial domain, no output schema, and zero annotations, the description is severely incomplete. It omits return value structure, parameter interdependencies, and domain context necessary for safe invocation in a trading system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description completely fails to compensate. Critical parameters like `contract_type` (expected values: 'STK', 'OPT', 'FUT'?) and `symbol` (ticker format requirements) are undocumented. The description mentions no parameters, syntax, or formats, leaving agents blind to required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (get) and resource (contract information) but is vague and borderline tautological, merely restating the tool name with the adjective 'detailed'. It fails to distinguish this from critical siblings like `qualify_contracts` (validation), `create_contract` (creation), or `get_option_chain` (specific contract types), leaving agents uncertain which contract retrieval method to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives. Given siblings like `qualify_contracts` and `get_option_chain`, the description should explicitly state whether this retrieves generic contract metadata, validates instrument definitions, or serves as a prerequisite for placing orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description adds zero behavioral context. It does not disclose whether positions are returned for all accounts or require specification, what data structure is returned, whether the operation is idempotent, or any rate limiting concerns. The burden falls entirely on the description, which provides nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While brief, the three-word description represents under-specification rather than efficient conciseness. It wastes the opportunity to provide necessary context (scope, account handling, output format) given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trading domain tool with implied complexity (multi-account positions, security types, P&L implications), the description is inadequate. It lacks explanation of return values, account scoping behavior, and relationship to portfolio data—critical gaps for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'account' parameter, the schema sufficiently documents inputs. The description does not add additional semantics (such as explaining behavior when account is omitted), but the high schema coverage means it doesn't need to compensate—baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all positions.' is tautological—essentially restating the tool name with minor grammatical changes. While it indicates the resource (positions), it lacks specificity about what constitutes a position in this trading context and fails to distinguish from similar sibling tools like get_portfolio or get_open_trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives. Given siblings like get_portfolio, get_account_summary, and get_open_trades, the description should clarify the distinction between retrieving positions versus portfolio data or active trades, but offers no such differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses nothing about: monetary side effects, irreversibility, error handling, rate limits, or confirmation requirements. The term 'Place' implies mutation but lacks safety context essential for trading operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, it is brief but constitutes under-specification rather than efficient conciseness. No information is front-loaded; the sentence adds zero value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-stakes financial mutation tool with 9 parameters, no output schema, and no annotations, the description is dangerously incomplete. It omits return value structure, error scenarios, and whether this submits to live markets or paper trading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 56% (below 80% threshold), leaving critical parameters like 'contract_type' and 'symbol' undocumented. The description adds no semantic guidance, valid value ranges, or cross-parameter dependencies (e.g., limit_price required when order_type='limit').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Place a new order' is a tautology that restates the tool name. It fails to specify that this executes real financial transactions or distinguish it from the sibling tool 'what_if_order' (which likely simulates orders without execution).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus 'what_if_order' (critical for financial safety), prerequisites (connection status, account permissions), or when to prefer 'cancel_order' for error correction. Missing essential guardrails for a destructive financial operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. While 'Get' implies a read-only operation, the description omits response format, rate limits, authentication requirements, and error handling for invalid article IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is brief (three words), it exemplifies under-specification rather than effective conciseness. The single sentence wastes no words but also provides zero informational value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the financial/trading context of sibling tools and the specific ID-based retrieval pattern, the description inadequately prepares the agent. With no output schema, the agent receives no indication of what article fields (headline, body, timestamp) are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description completely fails to compensate. It describes neither the 'provider_code' format (is it a ticker? news source identifier?) nor the 'article_id' structure, leaving both critical parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a news article' is tautological and restates the tool name without adding specificity. It fails to distinguish this tool from sibling 'get_historical_news' (which retrieves multiple articles) or clarify what constitutes valid provider codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance provided. The description does not indicate when to use this specific retrieval endpoint versus 'get_historical_news' or 'get_news_providers', nor does it mention prerequisite steps like obtaining article IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it reveals almost nothing. It does not state whether this is read-only (implied by 'run' vs 'place_order' but not explicit), what the return format is, whether it requires an active connection, or rate limit implications. Only the domain (market) is hinted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
At 3 words, it is technically brief, but this represents under-specification rather than meaningful conciseness. The single sentence fails to earn its place by providing actionable context, making it indistinguishable from a placeholder.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter financial trading tool with no output schema and no annotations, the description is inadequate. It omits the scanner subscription model, the relationship to get_scanner_parameters for discovering valid codes, and what the execution actually produces (e.g., ranked lists of instruments).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage. The description adds no parameter-specific context beyond the schema, but with high schema coverage, the baseline is 3. The schema adequately documents the parameters including examples for scan_code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run a market scanner' is tautological, essentially restating the tool name with spaces. While it identifies the verb and resource, it fails to explain what a market scanner actually returns (lists of instruments, rankings) or how it differs from sibling tools like get_market_data, search_symbols, or get_historical_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Complete absence of usage guidance. The description does not mention the critical prerequisite relationship with sibling tool get_scanner_parameters (which likely provides valid scan_code values), nor when to use this versus other data retrieval tools. No 'when-not-to-use' or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It fails to specify what time range of fills is returned (historical vs session), whether the data is real-time or cached, or any rate limiting considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single three-word sentence that is appropriately front-loaded, but it is under-specified rather than meaningfully concise. Every sentence should earn its place, and this one adds minimal value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema provided and multiple similar trading data tools available (get_executions, get_open_orders), the description should clarify the specific scope and format of returned fill data. It fails to complete the picture for an agent deciding between related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters (empty properties object), which per rubric guidelines establishes a baseline score of 4. There are no parameters requiring semantic elaboration beyond what the trivial schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get order fills' essentially restates the camelCase name 'get_fills' with spaces added. While it confirms the resource type (order fills), it fails to distinguish from the sibling tool 'get_executions' or specify scope (time range, account, etc.), making it a near-tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus the sibling 'get_executions' tool, or what prerequisites (active connection, selected account) might be required. No alternatives or exclusions 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 the full disclosure burden. It does not specify what data the summary contains (balances, positions, equity), whether the data is real-time or cached, or if specific permissions are required. Only implies read-only behavior via the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (3 words), avoiding verbosity. However, the single sentence does not earn its place as it adds minimal value beyond the tool name itself. Front-loading is irrelevant given the lack of content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a financial/trading domain tool with no output schema. Should explainsummary contents and account selection behavior when the optional parameter is omitted. Leaves critical gaps for an agent trying to select between multiple account-related endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage (account: 'Account ID (optional)'). Since the schema fully documents the single optional parameter, baseline score is 3. Description adds no additional semantic context (e.g., default account behavior, ID format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get account summary' essentially restates the tool name (tautology). While it indicates a read operation on an account resource, it fails to distinguish from sibling tools like get_accounts, get_account_values, or get_portfolio, leaving the specific scope ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives (e.g., get_account_values for specific metrics or get_portfolio for holdings). The optional nature of the 'account' parameter is unexplained—description does not indicate what happens when omitted.
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, placing the full burden on the description, which fails to disclose behavioral traits such as whether the data is real-time or historical, if it includes commissions/fees, caching behavior, or required permissions. The description merely states the action without operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
While appropriately brief at three words, the description wastes its limited length by providing only minimal information. It is front-loaded with the verb but fails to include qualifying clauses that could clarify scope or constraints, resulting in under-specification rather than efficient precision.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the financial trading context with numerous related data tools and no output schema, the description is inadequate. It should clarify the temporal scope, PnL calculation methodology, and differentiation from account summary tools, but provides only a bare label.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 100%, the baseline score is 3. The description adds no meaningful context about the optional 'account' parameter (e.g., what happens if omitted, format expectations) beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get profit and loss' essentially restates the tool name (get_pnl) by expanding the acronym, functioning as a near-tautology. While it identifies the resource, it fails to specify scope (daily vs. total, realized vs. unrealized) or distinguish from siblings like get_account_summary or get_portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_account_summary, get_portfolio, or get_positions. Given the presence of multiple account data retrieval siblings, the absence of discriminatory guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden yet reveals no details about calculation methodology, convergence behavior, error conditions, or performance characteristics. It fails to disclose whether this performs a mathematical solve or data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is structurally efficient and front-loaded with the action verb, but extreme brevity constitutes under-specification rather than effective conciseness given the tool's complexity. The description sacrifices necessary parameter documentation for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial calculation with six undocumented required parameters, no annotations, and no output schema, the description fails to provide adequate domain context. It omits essential details such as option pricing model assumptions, parameter interdependencies, or expected return value format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 6 required parameters, the description inadequately compensates by failing to explain critical semantics such as date format for 'expiry' or valid values (Call/Put) for 'right'. While it mentions 'option price' conceptually, it does not map this to the parameter name or document the other five trading parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific calculation (implied volatility) and primary input (option price), but fails to differentiate from sibling tool `calculate_option_price`, which performs the inverse calculation. In a domain with complementary calculation tools, explicit scope definition is needed to prevent selection errors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, prerequisites, or comparison to sibling `calculate_option_price` is provided. The description offers no criteria for selecting this IV calculator versus retrieving market data or performing other calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only minimally indicates this is a read operation ('Get') and historical in nature. It fails to disclose data source limitations, rate limiting, what happens if historical data is unavailable, or the structure of the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (4 words) and front-loaded, but given the tool's complexity (8 parameters, no annotations, no output schema), this brevity results in under-specification. The sentence doesn't earn its place given the information gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter financial data tool with no annotations and no output schema, the description is woefully incomplete. It doesn't explain output format, parameter relationships (e.g., that SMART is Interactive Brokers' routing destination), or data granularity constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (4 of 8 parameters documented). The description mentions no parameters whatsoever, failing to compensate for the undocumented contract_type, symbol, exchange, and currency parameters. It adds zero semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves 'historical bar data' (OHLCV candles), which is specific enough to distinguish from siblings like get_historical_news or get_market_data. However, it lacks domain context for financial trading and doesn't clarify the distinction from get_head_timestamp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_market_data (likely real-time) or get_head_timestamp, nor does it mention prerequisites like requiring a valid contract or connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to specify return format, whether results are cached, or what 'available' means (valid options vs current settings). Only the 'Get' verb implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is brief (4 words), the single sentence fails to earn its place by providing meaningful value beyond the function name. It is front-loaded but underspecified for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of run_scanner as a sibling and no output schema, the description should explain that this returns configuration metadata for the scanner. The absence of return value description and tool relationships leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, which per the evaluation guidelines sets a baseline score of 4. There are no parameters requiring semantic elaboration in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get available scanner parameters' is essentially a tautology of the function name, providing minimal additional clarity. It does not specify what 'scanner' refers to (market scanner), what the parameters control, or how it differs from run_scanner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus run_scanner or other data retrieval tools. It omits the crucial context that this should be called before run_scanner to determine valid parameter configurations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to specify the timestamp format returned (ISO 8601, Unix epoch?), whether this performs a live exchange lookup or cached lookup, error conditions for invalid symbols, or rate limiting concerns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded, but underspecified for a tool with 5 undocumented parameters and complex financial data semantics. It is brief at the cost of necessary parameter and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with no schema descriptions, no annotations, and no output schema, the description is critically incomplete. It omits return value structure, parameter semantics, and how the 'what_to_show' parameter affects the timestamp calculation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage across 5 parameters, the description must compensate but mentions none of them (contract_type, symbol, exchange, currency, what_to_show). It only implicitly suggests parameters identify an instrument, without explaining valid values for contract_type (e.g., 'STK', 'OPT') or what_to_show options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action (get) and resource (earliest available historical data timestamp). However, it does not explicitly distinguish this metadata lookup from the sibling `get_historical_data` tool that retrieves actual price data, though 'timestamp' implies this returns boundary metadata rather than series data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives, or that it should typically be invoked before `get_historical_data` to determine valid date ranges. No prerequisites or conditions 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 disclosure burden. It fails to mention if this is a synchronous request, what data structure is returned (strikes, expirations, bid/ask), rate limits, or whether results are real-time or delayed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and wastes no words, but the overall description is insufficiently sized for a tool with 3 parameters and no annotations. Conciseness becomes under-specification here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, absence of output schema, and low parameter coverage, the description should explain return format, authentication context, or parameter interactions. It provides only the minimal action statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage (1 of 3 parameters documented), the description must compensate for 'exchange' and 'underlying_sec_type'. It mentions 'underlying' which aligns with the symbol parameter but provides no guidance on the default security type (STK) or exchange filtering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (option chain) with scope (for an underlying). Uses standard financial terminology that distinguishes it from sibling tools like calculate_option_price or get_contract_details, though it could explicitly contrast with the latter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like get_contract_details or get_market_data. No mention of prerequisites (e.g., connection state) or typical use cases (e.g., 'use this to see all available strikes and expirations').
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 description carries full burden. While 'market values' indicates current valuation data, critical behavioral details are missing: data freshness (real-time vs delayed), default account behavior when parameter omitted, caching policies, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 5 words with no redundancy. Single sentence structure is efficient, though arguably under-specified given domain complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a financial trading tool with 20+ siblings including `get_positions`, the description is insufficient. Missing: explicit differentiation from related position queries, output structure guidance (no output schema exists), and multi-account behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (account parameter fully documented). Description adds no parameter context, but baseline 3 applies when schema does the heavy lifting. No explanation of account ID format or omission behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Get' and resource 'portfolio positions with market values', distinguishing content from raw positions. However, fails to explicitly differentiate from sibling tool `get_positions`, which is critical given the overlapping semantics in trading contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus siblings like `get_positions`, `get_account_values`, or `get_account_summary`. No mention of prerequisites or behavior when the optional account parameter is omitted.
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, yet the description discloses no behavioral details: it doesn't state what the search returns (list of contracts? symbols?), matching logic (substring, exact, regex), or if the operation is idempotent/safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no fluff or redundancy. However, the brevity contributes to under-specification rather than efficient communication of necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a financial trading API with complex contract types. Lacks explanation of return format, pagination, or how results differ from related contract tools. With no output schema and no annotations, the description should carry more explanatory burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'pattern' parameter. The description mentions 'matching' but adds no specific semantics about pattern syntax (e.g., glob vs. regex) or valid formats beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
States the basic action (search) and resource (symbols/contracts) but is somewhat tautological with the tool name. Critically, it fails to distinguish from siblings like 'qualify_contracts' or 'get_contract_details' which also deal with contract resolution/validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus 'qualify_contracts', 'get_option_chain', or 'get_contract_details'. No mention of search syntax (wildcards, partial matching) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. It does not specify the pricing model used (Black-Scholes, Binomial, etc.), computation latency, validation behavior, or error conditions for invalid option parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) and front-loaded with the key action. However, given the tool's complexity (6 required parameters, financial domain) and complete lack of schema documentation, this brevency crosses into under-specification rather than optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex financial calculation tool with 6 required parameters, 0% schema coverage, no output schema, and no annotations, a 5-word description is severely inadequate. It fails to address domain-specific requirements like option type semantics, date formats, or output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all 6 parameters. While the description mentions 'volatility', it provides no semantic context for the other 5 required parameters (symbol, expiry, strike, right, underlying_price)—critical omissions for financial instruments where 'right' (call/put) and date formats require explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb ('Calculate') and resource ('option price') with the key input ('volatility'), making the basic function understandable. However, it fails to explicitly distinguish from sibling tool 'calculate_implied_volatility' (the inverse operation), which is a significant gap in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'calculate_implied_volatility', or prerequisites such as requiring specific market data connections. The description is purely functional with no contextual usage advice.
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, yet the description fails to disclose what data the reports contain, whether results are paginated, time-range limited, or the format of returned execution data. Does not mention if this requires authentication or specific account permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
While brief at only three words, it is under-specified rather than efficiently informative. Lacks front-loaded critical constraints or scoping details that would help an agent determine if this tool fits their need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex financial trading domain evidenced by siblings (orders, positions, PnL), the description is insufficient. It does not indicate what time period is covered, what fields are returned, or how this relates to account history.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, establishing baseline 4. Description neither adds nor removes value regarding parameters since none exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
States a verb ('Get') and resource ('execution reports'), but 'execution' is vague in this trading context and fails to distinguish from sibling tool 'get_fills' or indicate what constitutes an execution versus a fill or trade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like 'get_fills' or 'get_open_trades', nor mentions prerequisites such as requiring an active connection (implied by sibling 'connect'/'is_connected' tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full responsibility. 'Real-time' and 'snapshot' imply synchronous current data retrieval, but description omits critical trading API details: rate limits, whether this consumes market data subscriptions, connection requirements, caching behavior, or handling of market closed scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 9 words. Information-dense without redundancy. However, extreme brevity becomes a liability given the complexity of the financial domain and lack of schema documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a 4-parameter trading tool with 0% schema coverage, no annotations, and no output schema. Description fails to indicate what market data fields are returned (price, volume, greeks, etc.) or how to interpret results, which is critical given the sibling tool density (30+ tools) and potential confusion with get_contract_details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (4 undocumented parameters). Description mentions 'contract' generally, implying parameters identify a contract, but fails to explain valid contract_type values (STK, OPT, etc.), symbol formats, or the significance of exchange/currency defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Get) and resource (real-time market data snapshot) with scope (for a contract). Uses 'real-time' and 'snapshot' which partially distinguish from get_historical_data, though it fails to differentiate from get_contract_details which also retrieves contract information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus siblings like get_historical_data or get_contract_details. No mention of prerequisites like active connection (is_connected sibling exists) or market hours.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden but fails to explain what 'create' actually produces (a local object vs. server registration), whether it validates symbol existence, what it returns, or if the created contract persists across sessions. No behavioral traits beyond the basic verb are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief at two sentences. While not bloated, the second sentence is merely a flat list that could benefit from formatting or integration into usage guidance. Given the tool complexity, additional length would be warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for an 8-parameter trading tool with no output schema or annotations. The description omits critical trading context: return value format, validation behavior, whether the contract is validated against the exchange, and how it relates to order placement. Should explain the contract creation lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by listing valid contract_type values (stock, option, future, etc.) which the schema does not enumerate. With 100% schema coverage for all 8 parameters, the baseline is met, though the description misses opportunity to explain conditional requirements (e.g., that expiry/strike are only relevant for options/futures).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb and resource ('Create a contract for trading') and enumerates the eight valid contract types. However, it does not explicitly differentiate from sibling tools like qualify_contracts or get_contract_details that also handle contract objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., requiring an active connection) or its relationship to place_order. The description lacks any 'when-not' guidance or workflow 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?
Zero annotations provided, so description carries full burden. 'Historical' implies past data but fails to disclose time range limits, pagination behavior, rate limits, or response format. No mention of data availability or caching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (4 words) and front-loaded, but undersized for a 3-parameter tool with no annotations. The single sentence states the obvious without earning its place through behavioral details or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Insufficient for complexity level. With 3 parameters, no annotations, no output schema, and related siblings, the description should explain the contract-news relationship, provider code source, and return structure. Current description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params described). Description adds no parameter context, but schema adequately covers con_id and provider_codes. total_results lacks description in schema and description provides no compensation for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States clear verb ('Get') and resource ('historical news headlines'). 'Headlines' distinguishes from sibling 'get_news_article' (likely full articles), though it doesn't explicitly note this is contract-specific via con_id parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives like 'get_news_article' or 'get_news_providers'. Does not mention prerequisite steps (e.g., obtaining provider codes via get_news_providers) or when historical vs current news is 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 provided, and the description adds minimal behavioral context beyond the name. Does not clarify what constitutes an 'open' trade, whether data is real-time or cached, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief at four words with no waste, though arguably too terse given the domain complexity. Structure is front-loaded but lacks the substance needed for a financial API tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex trading domain with numerous sibling tools that have overlapping concerns, the description is insufficient. It should explain the relationship between trades, orders, and positions, and ideally mention return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, which sets a baseline of 4 per scoring rules. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
States the verb (Get) and resource (open trades) clearly, but fails to distinguish from siblings like 'get_open_orders' or 'get_positions' in a trading domain where these are distinct concepts (trades=executed, orders=pending, positions=holdings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus 'get_open_orders', 'get_positions', or 'get_portfolio'. In trading APIs, these distinctions are critical for correct agent behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to specify the state change (e.g., order status changes to 'cancelled'), reversibility, error conditions (e.g., attempting to cancel a filled order), or side effects. 'Cancel' implies mutation but lacks crucial specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word sentence is appropriately front-loaded with no extraneous information. While extremely brief given the lack of annotations and behavioral details, it contains no structural waste or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive financial operation with no output schema or annotations, the description is dangerously incomplete. It omits critical trading-domain context such as 'only cancellable while order is open' and 'cannot cancel filled orders', which are essential for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter ('Order ID to cancel'). The description adds no supplementary context about the parameter (e.g., source, format constraints), meeting the baseline expectation when the schema is fully self-documenting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cancel') and resource ('order'), clearly stating the tool's function. However, it misses the opportunity to explicitly distinguish from the sibling tool 'cancel_all_orders' by clarifying this operates on a single order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus 'cancel_all_orders', nor does it mention prerequisites such as the order needing to be in an open/pending state (critical for trading contexts). It merely restates the tool's action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. While it lists data categories (balance, margin), it doesn't disclose read-only status, error behaviors, or whether omitting the account parameter returns all accounts or a default account.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief single sentence with no filler. Every word earns its place. However, given the complexity of sibling tools and optional parameters, extreme breveness may underserve the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read operation with one parameter, but lacks differentiation from the server's extensive suite of account-related tools. Without an output schema, the 'etc.' leaves return value ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage (account ID described as optional), establishing baseline 3. The description adds minimal additional semantics about the parameter itself, such as expected format or default behavior when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb and resource with specific examples (balance, margin). However, it doesn't differentiate from siblings like get_account_summary or get_portfolio which may overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus get_accounts, get_account_summary, or get_portfolio. No mention of prerequisites or behavior when the optional account parameter is omitted.
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 full burden. It successfully discloses that the operation enriches contracts by filling the conId field, but omits critical operational details like whether this requires an active broker connection, if it validates against the exchange, or what happens if multiple contracts match the input criteria.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words and front-loaded verb. However, extreme brevity is inappropriate given the complete absence of schema documentation and the technical complexity of financial contract qualification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four undocumented parameters, no annotations, no output schema, and domain-specific complexity (Interactive Brokers API), a single sentence is inadequate. Missing crucial context like error conditions, whether the operation is idempotent, and what the return payload contains (presumably the qualified contract with conId).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fails to compensate by documenting the four parameters (contract_type, symbol, exchange, currency). It does not explain valid values for contract_type (e.g., 'STK', 'OPT'), required symbol formats, or the significance of the 'SMART' default exchange.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'qualify' and resource 'contracts', and explains the concrete effect (filling in missing fields like conId). However, 'qualify' assumes domain knowledge of IB API terminology and doesn't explicitly differentiate from sibling 'create_contract' or 'get_contract_details'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like 'create_contract' (local object creation) or 'get_contract_details'. Does not mention typical prerequisite scenarios like having partial contract information that needs resolution.
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 carries full disclosure burden. It only states the basic retrieval action without describing return format, whether results are cached, or that this is a prerequisite discovery call for other news tools. It implies read-only behavior but lacks essential 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at four words with no wasted language. However, the brevity borders on under-specification given the tool's role in the broader news workflow; a single additional clause about its relationship to other tools would improve utility without sacrificing structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks necessary context for a discovery endpoint with no output schema. Given siblings `get_news_article` and `get_historical_news`, the description should explain that this returns provider identifiers used as input parameters for those other functions. Without this, the agent cannot understand the operational workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, establishing baseline 4 per rubric guidelines. With an empty input schema, there are no parameter semantics to describe beyond confirming none are required, which the description implicitly conveys through its simplicity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Get) and resource (available news providers), clearly indicating it retrieves a list of news sources. However, it fails to differentiate from siblings like `get_news_article` and `get_historical_news`, which also operate on news data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to invoke this tool versus other news-related functions. Given the presence of `get_historical_news` and `get_news_article`, the description should indicate this is typically called first to discover valid provider IDs for subsequent filtering.
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, leaving full burden to description. Fails to disclose whether disconnect is graceful, requires authentication cleanup, affects pending operations, or what happens if called when already disconnected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief single sentence. Efficient for a parameterless operation, though brevity is excessive given lack of annotations and behavioral context that should have been included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for identifying the operation but insufficient given the stateful nature implied by siblings (connect/is_connected). Missing prerequisite warnings and effect descriptions that would complete the definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present; baseline score of 4 applies per evaluation rules. Schema coverage is vacuously 100% with empty properties object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (Disconnect) and target resource (TWS/Gateway). Implicitly distinguishes from sibling 'connect' by describing opposite action, though explicit comparison would strengthen it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use versus 'is_connected' check, prerequisites (requires active connection), or cleanup behavior (e.g., handling open orders before disconnect).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden but fails to specify return format (ISO string, epoch timestamp, or object), timezone (UTC, local, or server time), or whether the call is cached or synchronous. The only behavioral hint is 'server time' implying a network dependency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four-word sentence is appropriately sized for a zero-parameter utility function. Every word earns its place: 'Get' (action), 'current' (temporal scope), 'TWS server time' (resource). No redundancy or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the absence of an output schema means the description should describe return value characteristics (format, timezone). It does not, leaving agents guessing whether they receive a string, number, or structured object. The 'TWS' term is also undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with 100% schema coverage (empty object) provides complete schema documentation by default, warranting the baseline score of 4 per rubric. The description appropriately makes no mention of parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' and resource 'current TWS server time' clearly identify the tool's function. However, it does not differentiate from sibling 'get_head_timestamp' (which returns the first available historical data timestamp) nor explain the 'TWS' acronym, slightly limiting clarity for agents unfamiliar with Trader Workstation terminology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus alternatives like 'get_head_timestamp', nor prerequisites such as requiring an active connection to the TWS server. The description assumes the agent inherently understands when current server time is needed versus historical timestamps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to clarify what 'open' means (pending, partially filled, submitted), whether the data is real-time or cached, or what return format to expect. It does not mention pagination, account scoping, or session requirements despite these being critical for trading APIs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at only four words, with no redundancy or filler content. The single sentence is front-loaded with the essential action and resource, making efficient use of space despite the resulting information gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high domain complexity and complete absence of output schema or annotations, the description is inadequate. It fails to compensate for missing structured metadata by describing expected return values, error conditions, or the specific definition of 'open' orders required to distinguish this from similar order-state queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, establishing a baseline score of 4. The description neither adds nor detracts from this baseline, as there are no parameter semantics to elaborate upon beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and specific resource ('open orders'), accurately describing the core function. However, it lacks explicit differentiation from similar sibling tools like 'get_open_trades', 'get_executions', or 'get_fills', which is critical in this trading domain with numerous overlapping retrieval functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_open_trades' (positions) or 'get_executions' (filled orders). In a complex trading API with 30+ sibling tools, the absence of contextual usage boundaries leaves the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full safety burden. It successfully discloses that no order is actually placed (critical for a trading tool), but fails to describe the return format, error conditions, or whether this requires market data connectivity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The six-word sentence is efficiently front-loaded with zero redundancy. However, given the high parameter count (8) and complex financial domain, the extreme brevity may hinder utility rather than help it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter trading tool with 0% schema coverage and no output schema, the description is insufficient. It omits parameter semantics, return value structure, and error scenarios necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for 8 parameters, requiring significant description compensation. While the description implies these parameters constitute an 'order' for margin checking, it provides no semantic mapping for domain-specific fields like 'action', 'contract_type', or 'order_type' (e.g., BUY/SELL, STK/OPT).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Check') and resource ('margin impact'), clearly indicating this simulates order effects. The phrase 'without placing order' implicitly distinguishes it from sibling 'place_order', though it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without placing order' implies the use case (previewing before execution), but lacks explicit guidance on when to prefer this over 'place_order' or calculation tools like 'calculate_option_price'. No prerequisites or rate limits 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 disclosure burden. While 'cancel' implies mutation, there is no mention of irreversibility, handling of partially filled orders, error behavior if no orders exist, or success indicators—critical omissions for a destructive bulk operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief at four words with no redundancy. However, given the high-stakes destructive nature of the operation, this brevity borders on under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive bulk operation with no output schema and no annotations, the description is dangerously minimal. It lacks safety warnings, scope clarification (all accounts vs. specific), and behavioral expectations that would prevent accidental misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, establishing baseline 4. The description requires no parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cancel all open orders' provides a specific verb (cancel), clear resource (orders), and scope modifier (all/open) that effectively distinguishes it from sibling tool 'cancel_order' (singular).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this versus the singular 'cancel_order', nor warnings about the bulk irreversible nature of the operation. The 'all' implies scope but doesn't guide decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies read-only behavior through 'Get', but fails to mention prerequisites (connection state), side effects (none expected), or the structure of the returned list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at six words. Front-loaded with the verb 'Get', immediately communicating intent without filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple parameterless tool, but lacks important contextual clues given the sibling ecosystem: should mention that results feed into get_account_values/get_account_summary and likely requires prior connection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present; baseline score applies. The description does not need to compensate for missing schema documentation, as there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Get') and resource ('managed account names'), distinguishing it from sibling tools like get_account_summary and get_account_values which imply detailed data retrieval rather than a simple name listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus alternatives, or prerequisites (e.g., requiring an active connection given the 'connect' sibling tool). Missing indication that returned account names are likely needed for other account-specific operations.
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 description carries full disclosure burden. States connection is established but omits critical behavioral details: failure modes, timeout behavior, whether idempotent/reentrant, what indicates success, and that it establishes persistent stateful session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first establishes action/target, second states critical prerequisite. No redundancy, appropriately front-loaded with action verb. Every word serves selection or invocation clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a connection primitive given good schema coverage, but minimal for complexity involved. Acknowledges prerequisite nature but omits error conditions, lifecycle management (timeouts/reconnects), and side effects expected of a stateful network connection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline applies. Description mentions 'TWS or IB Gateway' which contextualizes the connection targets, but does not elaborate on parameter interactions or required vs optional usage beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (Connect) and resources (TWS or IB Gateway). Distinguishes from siblings 'disconnect' and 'is_connected' by specifying it establishes the connection to these specific trading platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states critical sequencing constraint: 'Must be called before using other tools.' This clearly establishes the prerequisite relationship with the 30+ sibling trading operations. Lacks explicit guidance on when not to use (e.g., if already 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?
No annotations provided, so description carries full burden. Only states what is checked (connection status) but omits critical behavioral details: return value type (boolean? object?), behavior when disconnected (returns false vs raises error?), or whether this performs an active ping vs passive cache check. Similar to the 'update_drive' example in the rubric which scored 2 for lacking permissions/reversibility details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of appropriate length. Front-loaded with action verb ('Check'). Zero redundancy or waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple state-checking tool with zero parameters, so extensive description is not required. However, lacks output specification (bool vs status object) which would be helpful given no output_schema exists and sibling tools have varied return patterns. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, so baseline score of 4 applies per rubric. No parameters require semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Check') and resource ('connected to TWS/Gateway'). Effectively distinguishes from siblings 'connect' (establish connection) and 'disconnect' (terminate connection) by using 'Check' to indicate a status query rather than state modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit 'when to use' guidance provided (e.g., 'call before placing orders to verify connection'). However, the contrast with sibling tools 'connect'/'disconnect' implies this is for status checking rather than connection management. Clear gaps remain regarding specific usage patterns or prerequisites.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/nadavgb-atom/ib-async-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server