IG Trading MCP

Server Quality Checklist

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

Latest release: v0.8.5
Disambiguation5/5
Each tool targets a distinct resource and action, with clear separation between positions, working orders, market data, and account history. Even similar-sounding tools like get_activity and get_transactions are differentiated by their descriptions (account activity vs. financial transactions).
Naming Consistency5/5
All tools follow the ig_ prefix followed by a consistent verb_noun pattern (e.g., list_positions, get_market, create_position, cancel_working_order). The naming is uniform and predictable.
Tool Count4/5
20 tools is a bit above the typical 3-15 range, but the breadth of the IG trading domain (accounts, markets, positions, working orders, history) justifies the count. Each tool serves a distinct purpose with no redundancy.
Completeness5/5
The tool set covers the full lifecycle for positions (create, get, list, update, close) and working orders (create, list, update, cancel), plus market data and account history. There are no obvious dead ends; operations like get_deal_confirmation support post-submission workflows.
Average 3/5 across 20 of 20 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely restates the tool's function without mentioning side effects, whether confirmation is required, reversibility, or impact on positions. This is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, which is appropriate in length but lacks structure. It does not organize information or emphasize key details, and the brevity results in under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no parameter descriptions) and the presence of an output schema, the description is severely incomplete. It fails to provide any operational context beyond the basic action, leaving the agent without enough information to successfully invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description provides no explanation of parameters such as deal_id, timezone, confirm, or live_confirmation. The agent receives no guidance on how to populate these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel) and the object (OTC working order). It distinguishes from sibling tools like ig_create_working_order and ig_update_working_order, so the agent can tell this is the cancellation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, what prerequisites exist, or how it compares to alternatives. It only states the action, leaving the agent to infer usage solely from the tool name.
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 does mention a critical risk—'This may execute a leveraged trade'—but omits other significant behaviors such as confirmation requirements, account impact, position sizing implications, or whether a deal reference is returned. This is minimal at best.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no filler words. However, it is under-specified for a tool with four parameters and a nested request object; the brevity appears to be a lack of substance rather than disciplined conciseness. It is not clearly 'appropriately sized' for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, low schema description coverage, a complex open-ended request object, and an output schema. The description fails to provide enough context for an agent to invoke the tool safely: no OTC definition, no confirmation flow, no trade execution details, and no relationship with other position/order tools. The only added context is the leveraged trade warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of the parameters: request, timezone, confirm, or live_confirmation. The request object is open-ended (`additionalProperties: true`) and especially needs explanation, but the description is silent. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Create an OTC position.' It conveys the primary action without ambiguity. However, it does not distinguish this from related siblings like create_working_order beyond the 'OTC' qualifier, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ig_create_working_order, ig_update_position, or ig_close_position. There is no mention of prerequisites, supported scenarios, or exclusions, leaving the agent to infer usage.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only implies mutation via the verb 'update' but provides no details on side effects, confirmation behavior, live_confirmation, permissions, rate limits, or return handling. This is severely insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded and concise, though its brevity contributes to under-specification in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, nested objects, and an output schema, this description is completely inadequate. It provides no contextual information about how to use the tool, what the request object should contain, or what the expected outcome is, leaving the agent without essential guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description mentions no parameter names, types, or meanings. The schema has five parameters including a nested 'request' object and confirm/live_confirmation, but no explanation is provided to help the agent construct a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update') and the resource ('OTC working order'), distinguishing it from sibling tools like create_working_order and cancel_working_order. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, context, or exclusions. It is a bare statement of purpose.
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 adds one useful detail—'offset-aware ISO-8601 datetime inputs'—but does not mention pagination behavior, the effect of the 'detailed' flag, whether the operation is read-only, or any rate limits. The lack of safety or side-effect disclosures is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It states what the tool does and one key input requirement, earning its place. While more detail could be added, the structure is appropriately concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema, the description is too brief to be complete. It lacks usage context, alternative tool guidance, and behavior details. The output schema covers return shape, but the description still leaves major contextual gaps for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that the date/time inputs should be ISO-8601 with timezone offsets, covering from_date, to_date, and timezone implicitly. However, it says nothing about 'detailed' or 'page_size', leaving two of the five parameters semantically unexplained. Partial compensation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return active-account history' uses a specific verb and resource, clearly indicating what the tool does. It could better distinguish from sibling tools like ig_get_transactions or ig_get_historical_prices, but 'active-account history' implies a distinct concept, so it is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not state any exclusions, prerequisites, or scenarios where a different tool would be more appropriate. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states that it searches. It doesn't mention the return format, whether it's read-only, pagination, or any limitations. The existence of an output schema offloads some return-value details, but the description itself adds minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It's concise and easy to parse, though its brevity borders on under-specification rather than efficient completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (2 required parameters) and the absence of annotations or parameter descriptions, the description is insufficient for an agent to understand when to use this tool, what the timezone parameter does, or what the output represents. The output schema exists but doesn't alleviate the need for usage context in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It vaguely implies 'search_term' is a name or symbol, but it completely omits explanation of 'timezone'—why it's required or how it affects results. The description adds only marginal meaning over the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and resource ('IG instruments') with a specific scope ('by a market name or symbol'). It is distinct from siblings like ig_get_market (which likely retrieves a specific instrument) and ig_list_category_instruments (which lists by category), though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention scenarios where searching by name/symbol is preferred over browsing categories or fetching a specific market, leaving the agent to guess.
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?
There are no annotations, so the description bears full responsibility for behavioral disclosure. It only states the return action, but fails to disclose the role of the required timezone parameter, potential authentication requirements, or any side effects. The reader cannot infer the tool's exact behavior beyond a generic read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant wording, making it concise. However, it does not provide any structural aids (e.g., distinct sections) to help the agent parse critical information, but it is appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter that is entirely unexplained, and no annotations are present. The output schema exists, so return values need not be described, but the parameter gap and lack of usage context leave the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines a single required parameter, timezone, but the description does not mention it or explain its purpose. With 0% schema description coverage, the agent has no information about this parameter's expected format, values, or effect on the returned preferences.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: returning preferences for the active IG account. It uses a specific verb and resource, and the resource ('preferences') distinguishes it from sibling tools related to positions, orders, and market 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or how it relates to alternatives. It does not mention any prerequisites, such as the need for an active account or session, nor does it contrast with other account-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions that closing may realize profit or loss, but omits critical details such as the need for confirmation, irreversibility, partial-close mechanics, or preconditions. This leaves significant gaps for a financial 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded, with two short sentences. It contains no redundant information and the profit/loss note adds value. However, the extreme terseness sacrifices informative content, though that is more a completeness issue than a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex, high-stakes trading tool with five parameters, a nested request object, and an output schema. The description is far too sparse, lacking usage context, parameter guidance, confirmation requirements, and operational flow. It is wholly inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions no parameter names or formats. The phrase 'all or part' hints at the request object but does not explain deal_id, timezone, confirm, or live_confirmation. An agent cannot construct a valid request from this information alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('close') and the resource ('OTC position'), including the scope ('all or part'). This distinguishes it from sibling tools like create/update position, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for closing positions but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or exclusions. An agent can infer the use case but gets no direct guidance on context or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It states the core action (create) but omits important behavioral traits such as whether confirmation is required, how the timezone affects execution, what happens to the working order when opened, or how errors are surfaced. The mention of 'later' implies delayed execution, but no details on reliability or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It efficiently conveys the primary purpose, though its brevity leaves critical details absent; nonetheless, for what it does contain, it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, a nested request object, an output schema, and many siblings), the description is severely under-specified. It does not explain the request payload, timezone format, confirmation semantics, or return value, leaving the agent unable to invoke the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It provides no meaning for 'request', 'timezone', 'confirm', or 'live_confirmation', nor does it explain the expected structure of the 'request' object. An agent cannot correctly construct the required parameters from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies the exact resource ('OTC working order'), clarifying its deferred execution purpose ('can open a leveraged position later'). This distinguishes it clearly from sibling tools like ig_create_position, which executes immediately, and ig_update_working_order or ig_cancel_working_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to place a working order that will later become a leveraged position, rather than an immediate position. However, it does not explicitly state exclusions or alternatives, and no guidance is given on conditions like when a working order would be preferable or prerequisites like account permissions.
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. It mentions 'authenticated' as a prerequisite but does not explicitly state that the operation is read-only, safe, or free of side effects. It also lacks details about response shape, pagination, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's purpose. It contains no redundant words or unnecessary elaboration, earning its place effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has an output schema, the description fails to explain the required timezone parameter or any behavioral details. For a tool with zero schema coverage and no annotations, the description is insufficient to invoke it correctly, especially given the ambiguity around timezone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, timezone, with no description (schema coverage is 0%). The description does not mention timezone at all, leaving its purpose and format entirely unexplained. This is a critical gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists accounts for the authenticated IG client, using a specific verb ('list') and resource ('accounts'). This distinguishes it from sibling tools like ig_get_account_preferences, which focuses on preferences rather than account enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as ig_get_account_preferences or other IG tools. It does not mention prerequisites beyond authentication or any scenarios where this account list is particularly useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states a list operation with no mention of permissions, rate limits, pagination, or return format. It does not add context beyond what the name implies, leaving the agent without information about potential edge cases or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's primary function. It is front-loaded, contains no filler, and is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 required parameters, output schema exists but no annotations or parameter descriptions), the description is too sparse to be fully complete. It does not explain how to obtain a category_id, what the timezone parameter is used for, or what the instruments list contains. The agent is left to infer critical usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention either parameter. The schema only provides parameter names (timezone, category_id) without explanations. The description fails to clarify what values these parameters expect or how they affect the output, offering no compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List the instruments within an IG category.' It clearly distinguishes from sibling tools like ig_list_categories (which lists categories) and ig_search_markets (which searches markets). The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not list prerequisites (e.g., obtaining category_id from ig_list_categories) or mention when to choose it over ig_search_markets. The only hint is the tool name, which is not explicit usage guidance.
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 only says 'List open positions', which implies a read operation but does not disclose any behavior such as pagination, error conditions, or how the timezone parameter affects results. There is no contradiction with annotations, but the description adds very little beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the action and object. There is no redundant information or filler, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple list operation, the description is incomplete. It does not explain the timezone parameter, any filtering or ordering capabilities, or whether the results represent the full set of open positions. An output schema exists, so return values are covered, but the description leaves out important context for a tool in a trading API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, timezone, but provides no description (coverage 0%). The tool description does not explain what timezone is for or how it affects the results. The agent is left to guess the valid format or meaning, which is a significant gap especially since it is the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (List), the resource (open positions), and the scope (active account). This distinguishes it from siblings like ig_get_position (single position) and ig_list_working_orders (orders, not positions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that ig_get_position is for individual positions or that this lists all open positions, nor any conditions that affect usage. With several similar list/detail siblings, explicit differentiation would be expected.
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 states the action and identifier, but does not disclose that the timezone parameter affects the confirmation, what the confirmation contains, or how errors are handled. This is minimal disclosure beyond the obvious 'Get' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the verb and resource. There is no redundance or filler, making it an appropriately sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is incomplete because it does not explain the purpose of the required timezone parameter or provide any usage context. For a tool with two required parameters and no schema descriptions, this one-sentence description is insufficient for an agent to invoke it correctly without additional guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'deal reference' but does not explain that it is a required identifier. It entirely omits the 'timezone' parameter, which is also required, and provides no format or usage context. Since the schema has zero description coverage, the description fails to compensate for the missing parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'confirmation of a submitted deal', with a specific identifier 'deal reference'. This distinguishes it from sibling tools like get_position or get_activity, which deal with other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as get_activity or get_transactions. There is no mention of prerequisites or typical scenarios, leaving the agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Return,' which implies a read operation, but omits details about pagination, rate limits, permissions, or handling of invalid datetime inputs. No behavioral traits are disclosed beyond the basic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and it is perfectly concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, and an output schema, but the description fails to provide essential context: no usage guidelines, minimal parameter semantics, and no discussion of behavior beyond a read operation. Despite the output schema's existence, the description is too sparse for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the 5 parameters. The description adds only a hint about datetime format ('offset-aware ISO-8601') and does not explain transaction_type, page_size, or the exact meaning of from_date/to_date/timezone beyond the date range. This is insufficient compensation for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' with the resource 'transactions' and a clear scope ('offset-aware ISO-8601 datetime range'), which distinguishes it from sibling tools like ig_get_activity or ig_list_positions. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name and description.
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 available, the description must carry the full burden. It does disclose that the list is scoped to the active account, which is useful behavioral context. However, it does not mention pagination, timezone relevance, or any potential side effects. For a read-only list operation, this marginal transparency is neither contradictory nor severely lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. Every word contributes meaning, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered. However, the required timezone parameter is entirely unexplained, and there are no usage guidelines. This creates a significant gap in the agent's ability to use the tool correctly, despite the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, timezone, with 0% description coverage. The tool description completely omits any mention of timezone, leaving the agent with no understanding of what the parameter does, its format, or why it is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('instrument categories'), and the scope ('enabled for the active account'). It distinguishes itself from sibling tools like 'ig_list_category_instruments' by focusing on categories rather than instruments within a category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or exclusions. It is a bare statement with no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action (list open working orders) with no mention of limitations, side effects, or required permissions. The 'active account' concept is unexplained, and there is no context about pagination or filtering behavior beyond 'open'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose without any wasted words. It is front-loaded and immediately informative, embodying conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (which presumably documents return values), the description lacks essential context about the required timezone parameter and when to use this tool relative to siblings. The missing parameter semantics and usage guidance make the tool incomplete for an agent to select and invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'timezone' is required but has no description in the schema, and the tool description does not mention it at all. With 0% schema description coverage, the description completely fails to explain why timezone is needed or what format it should be in, leaving the agent unable to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists open working orders in the active account, using specific verb and resource. The name and description distinguish it from sibling tools like ig_list_positions, which list regular positions. This is a precise and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving working orders but provides no explicit guidance on when to prefer this over alternatives like ig_list_positions or ig_cancel_working_order. There are no exclusions or alternative tool mentions, making the guidance helpful but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states what data is returned (dealing rules, snapshot, details) but does not mention whether the operation is read-only, any permission requirements, rate limits, or side effects. The word 'get' implies read-only, but this is not explicitly stated, and no additional behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely states the tool's purpose without unnecessary words. It is well-suited for quick scanning and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 required parameters, output schema present), and the description adequately covers what data is returned. However, it misses key contextual details such as when to use this tool versus siblings, what the timezone parameter expects, and any prerequisites. The presence of an output schema reduces the need to describe return values, but the lack of usage guidance and parameter semantics leaves noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (epic and timezone) with 0% description coverage. The description only mentions 'instrument epic,' which provides a minimal hint that the epic parameter refers to the market identifier, but it does not explain the timezone parameter or its intended format. With no descriptions in the schema, the description fails to compensate adequately for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to retrieve dealing rules, snapshot, and details for a specific instrument epic. This distinguishes it from sibling tools like ig_search_markets (which searches for epics) and ig_get_historical_prices (which retrieves price history). The verb 'get' and the specific resource (market details for an epic) make the purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for retrieving a full market snapshot after you already know the epic, nor does it contrast with ig_get_current_candle or other market-related tools. There is no implied context beyond the tool name and basic 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, the description carries the full burden. It discloses that the position must be open, but provides no behavior for invalid or closed deal IDs, no error semantics, and no explanation of the required timezone parameter's role.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no unnecessary words; it is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits critical context: why timezone is required, what happens when no open position exists, and how this differs from listing positions. The tool is simple but the required timezone parameter creates ambiguity not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description only mentions deal ID by name but not format or semantics. The timezone parameter is entirely unexplained, despite being required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' with a resource 'specific open position' and qualifier 'by deal ID', clearly distinguishing from list_positions (all positions) and get_deal_confirmation. It is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use when a specific open position's deal ID is known, but does not explicitly mention alternatives like ig_list_positions or state when not to use it. The context is clear but no exclusions are given.
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 burden of behavioral disclosure. It states a key consequence ('This changes account risk'), which adds transparency about the tool's impact. However, it does not disclose other behavioral traits such as whether confirmation is required, how the request object is structured, or what happens on failure. Partial disclosure is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource. Every word contributes value; 'This changes account risk' adds context without redundancy. It is appropriately sized for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested object, output schema), the description is too sparse. It omits essential details about the request structure, the role of timezone, confirmation behavior, and how this tool fits with sibling tools. While an output schema exists, it does not compensate for missing parameter semantics and usage guidance. The description is insufficient for an agent to correctly invoke the tool in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with no descriptions (0% coverage). The description does not mention any parameters or add meaning to deal_id, request, timezone, confirm, or live_confirmation. It entirely fails to compensate for the lack of schema descriptions, leaving the agent without guidance on how to populate the request object or the purpose of the timezone field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and the specific resource ('an OTC position's stops or limits'), distinguishing it from sibling tools like ig_close_position and ig_create_position. It also hints at the trading context, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to modify stops or limits on an OTC position. However, it does not explicitly state when not to use this tool or mention alternatives like ig_update_working_order for working orders. The context is clear but lacks exclusions or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses two behavioral traits: offset-aware range (timezone handling) and reusable cached periods. This is more transparent than typical minimal descriptions, though it does not mention rate limits or return format nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the action and resource, followed by two key qualifiers. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 required parameters and no annotations, but the description provides no context for correct invocation. While an output schema exists, the input side is underspecified, leaving the user uncertain about parameter formats and allowed values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any parameters. The mention of 'offset-aware' vaguely suggests timezone's role, but it fails to clarify formats, valid resolutions, or date/time expectations. Parameters are left entirely to the user's domain knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action ('Get historical OHLC prices') with qualifiers ('offset-aware range', 'reusing cached periods') that distinguish it from siblings like ig_get_current_candle. It clearly identifies the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool is for retrieving historical prices. However, there is no explicit guidance on when to use it over alternatives or any exclusion criteria, though the mention of caching hints at repeated queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It openly explains the shared streaming subscription, the non-push snapshot limitation, and the derivation of resolutions from IG streaming candles. It doesn't address authorization or failure modes, but these are less critical for a read-only candle retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and every sentence adds value—covering resolutions, subscription context, and the polling limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the core use case (getting a forming candle) and the output schema covers return values, so that's not a gap. However, the missing parameter semantics for epic and timezone reduce overall completeness. It's a solid but not fully comprehensive description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must explain all parameters. It only documents the supported values for resolution and neglects to explain epic or timezone formats/meanings. This is a significant gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the latest forming IG chart candle, with a specific verb and resource. It distinguishes itself from sibling tools by explicitly mentioning the shared streaming subscription and derived resolutions, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: use for the latest forming candle, and instructs to call again for a newer snapshot due to MCP's non-push nature. It doesn't explicitly name alternatives like ig_get_historical_prices, but the context is sufficient for an informed agent to select this tool for current candle data.
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:

[![ig-integration-mcp MCP server](https://glama.ai/mcp/servers/MarkHorwell/ig-integration-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MarkHorwell/ig-integration-mcp)

Score Badge

Copy to your README.md:

[![ig-integration-mcp MCP server](https://glama.ai/mcp/servers/MarkHorwell/ig-integration-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MarkHorwell/ig-integration-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MarkHorwell/ig-integration-mcp'

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