IG Integration MCP

by MarkHorwell

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation3/5
Most tools target distinct resources (positions, working orders, watchlists, markets, accounts), but the generic ig_request tool can call any REST endpoint, creating overlap with all other tools. Some tools also combine multiple operations (e.g., account_preferences, mutate_watchlist), but descriptions clarify their dual purpose.
Naming Consistency3/5
The server uses snake_case, but mixes noun-only names (accounts, watchlists) with verb_noun names (create_position, switch_account). The outlier ig_request breaks the pattern, and some read tools use verbs (search_markets, stream_updates). Overall, the naming is readable but not fully consistent.
Tool Count4/5
21 tools is on the heavier side but appropriate for a comprehensive IG integration covering accounts, market data, positions, working orders, watchlists, sentiment, and streaming. The generic ig_request tool reduces the need for many specialized endpoint wrappers.
Completeness4/5
Core trading workflows are well covered: positions have create/read/update/close, working orders have create/read/update/delete, and watchlists have full CRUD. Minor gaps include no specific get-by-ID for working orders and no transaction history, but ig_request can fill these.
Average 3.6/5 across 21 of 21 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the tool retrieves a confirmation, but does not disclose potential errors, response structure, or any side effects. This is minimal and does not assure the agent of safety or failure modes.
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, clear sentence with no redundant or filler words. It is compact, front-loaded, and easy to parse, making it an appropriately concise definition for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple tool, the description lacks usage guidance, parameter semantics, and behavioral context. While an output schema is indicated, it is not provided in the visible context, so the description must cover more ground. The one-liner is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the 'deal_reference' parameter. The description adds only the word 'submitted', which hints at a requirement but does not explain the format, source, or validation of the reference. This is insufficient to fully understand the parameter.
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 the specific verb 'Get' and clearly identifies the resource as 'confirmation' for a submitted deal reference. This distinguishes it from sibling tools focused on orders, positions, or market data, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The phrase 'submitted deal reference' implies it is for post-submission scenarios, but there are no exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the confirmation requirement but fails to mention that deletions are destructive, whether the tool has side effects beyond the mutation, or what happens after a create/delete. No detail on permissions or reversibility.
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 concise sentence, front-loaded with the core function. However, it is under-specified rather than efficiently complete, which slightly reduces the score, but there is no wasted text.
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?
This is a multi-action mutation tool with 5 parameters and no annotations. The description omits critical context like parameter combinations, the confirm flag's role, and whether actions are irreversible. An output schema exists but does not compensate for missing operational context. For the complexity, the description is incomplete.
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% description coverage, so the description must explain parameters. It only says 'add/remove a market' without mapping parameters (epic, watchlist_id) to actions. The enum `action` is self-explanatory, but the description does not clarify which parameters are needed for each action, leaving the agent to infer.
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 verbs and resources: create/delete a watchlist or add/remove a market. It distinguishes from sibling tools like watchlists (presumably read-only) and create_working_order by focusing solely on watchlist mutation.
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 when-to-use or alternative guidance is provided. The only hint is 'Requires confirm=true,' which is a prerequisite rather than context about when to choose this tool over siblings. The description does not mention that watchlists is for viewing or that this tool is for mutations.
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?
The description adds the requirement for confirm=true, implying a sensitive/destructive operation. Since no annotations are provided, this is helpful, but it does not disclose other behavioral traits like irreversibility, permissions, or side effects on existing positions.
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 concise sentence with no fluff, front-loading the action and resource. However, it is too sparse, omitting crucial parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters (one a nested object) and no schema descriptions, the description is insufficient for safe and correct invocation. The output schema exists but does not clarify the close_order parameter structure or usage.
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 explains that confirm must be true, but gives no information about close_order, which is a free-form object. This is a significant gap for correct invocation.
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 positions'), specifying scope ('one or more'). It distinguishes the tool from siblings like create_position and update_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The confirmation requirement ('confirm=true') is a prerequisite, but there is no mention of exclusions or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses a key behavioral trait: that confirm=true is mandatory. However, it does not explain what happens if confirm=false, whether the order is actually submitted, or any side effects, leaving significant behavioral ambiguity.
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 core purpose and the key requirement. Every word earns its place; there is no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a state-changing order with an open-ended nested object), the description is far too minimal. It lacks details on the order structure, the confirm behavior beyond requiring true, and any guidance on how this fits with sibling tools. An agent would struggle to invoke this correctly based solely on this 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 coverage is 0%, so the description must compensate. It clarifies the 'confirm' parameter (requires true) but provides no meaning for the 'order' object, which is a required, unstructured nested object. The agent cannot infer how to construct a valid order, making the main parameter semantically empty.
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 (create) and the resource (OTC working order), using a specific verb+resource pair. It distinguishes this tool from siblings like update_working_order and delete_working_order by emphasizing creation and the OTC scope.
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 a requirement ('Requires confirm=true') but no guidance on when to use this tool versus alternatives. It does not mention any preconditions, contexts, or when-not-to-use, leaving the agent without decision-making help.
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 discloses that POST/PUT/DELETE require confirm=true, which is an important behavioral constraint. However, it omits other behavioral traits such as authentication requirements, rate limits, and side effects of mutating calls.
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 exceptionally concise: two sentences with no superfluous information. The critical purpose and the key constraint are front-loaded and clear.
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 description gives the core purpose and confirm rule, it lacks contextual integration with sibling tools. It does not explain when to fall back to this generic endpoint caller, how paths should be constructed, or any request/response conventions. The presence of an output schema covers return formatting, but the description still feels incomplete for a 6-parameter generic 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?
The input schema has 0% description coverage, and the description only adds meaning for the 'confirm' parameter by stating that mutating methods require it. Other parameters like body, params, path, and version are left entirely to their names, which may be ambiguous for constructing requests.
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: 'Call any documented IG REST endpoint.' This specifies the verb (call), resource (IG REST endpoints), and differentiates from siblings, which target specific 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?
No guidance is given on when to use this generic tool versus the many dedicated sibling tools. It does not state that this is a fallback for undocumented or custom endpoints, nor does it exclude cases where a specialized tool should be preferred.
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. It mentions supported resolutions but does not explicitly state that this is a read-only operation, nor does it disclose any potential side effects, rate limits, or data adjustments. The verb 'Get' implies read-only, but this is not clearly articulated.
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 sentences, front-loaded with the primary action, and contains no filler. Every sentence adds value: the first defines the tool's purpose, the second provides key parameter context. It is concise without being terse to the point of being unhelpful.
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?
For a 3-parameter tool with 0% schema coverage, the description is too sparse. It lacks usage context, parameter semantics for epics and num_points, and behavioral details. Although an output schema exists, it does not compensate for the missing guidance on how to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to the 'resolution' parameter by listing MINUTE, HOUR, DAY, WEEK, but leaves 'epic' and 'num_points' unexplained. The description provides partial parameter clarification but not comprehensive.
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 with a specific verb+resource: 'Get historical prices for an EPIC.' It distinguishes itself from siblings like market_details or search_markets by focusing on historical price retrieval. It also mentions supported resolutions, adding concrete detail.
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: use this tool when you need historical prices. However, there are no explicit when-to-use/not-to-use guidelines or references to alternative tools. The context is understandable but relies on the user inferring the tool's role.
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 but offers no behavioral details such as read-only nature, response structure, or potential side effects. It simply restates the tool's function without adding context beyond the 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 with no unnecessary words. It front-loads the action and resource, making it highly concise and structured.
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 minimal and does not clarify when to use the tool versus siblings like search_markets or what exactly 'market details' includes. Although an output schema exists, the lack of usage context reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'by EPIC', which adds minimal meaning to the 'epic' parameter. It lacks an explanation of what an EPIC is or acceptable formats, failing to compensate for the schema gap.
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 ('Get'), the resource ('market details'), and the key identifier ('by EPIC'), making it easy to distinguish from sibling tools like search_markets (searching) and historical_prices (price history).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an EPIC is known but does not explicitly state when to prefer this over alternatives, nor does it mention exclusions. No comparison to sibling tools is 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 provided, so the description must disclose behavioral traits. It notes the confirm=true requirement, which is a useful prerequisite, but it does not explain the nature of the update (e.g., immediate vs. pending), potential side effects, or whether destructive changes are involved. The description is too sparse to adequately inform an agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences and efficiently communicates the core action and one critical prerequisite. It is not overly verbose, and every word serves a purpose, though it is less structured than more informative descriptions.
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 a nested update object, no annotations, and a low schema-coverage description. Although an output schema exists, the description lacks essential context about input requirements (deal_id, update structure) and the mutation semantics. It is not complete enough to ensure an agent can use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It loosely ties the update object to 'stops/limits' and highlights confirm=true, but it does not explain deal_id, the structure of the update object, or the meaning of confirm beyond a boolean. Given the nested update object allows additionalProperties, the lack of parameter detail is a significant gap.
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 'update,' the resource 'OTC position,' and the specific scope 'stops/limits.' This distinguishes it from sibling tools like update_working_order, which targets working orders rather than positions. The action and target are 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?
The description indicates the tool is used to modify stops/limits on OTC positions, and it explicitly warns that confirm=true is required. However, it does not mention when to use this vs. alternative tools (e.g., close_position or create_position), nor any exclusions or conditions beyond the confirmation requirement. This gives clear context but no comparative 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Search') without revealing whether the operation is read-only, whether it returns a list, whether pagination applies, or any authentication requirements. This is a significant transparency gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's core function. There is no filler or redundant information, making it optimally concise and efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and an output schema, the description is minimally acceptable but lacks any additional context. It does not mention the return format, read-only nature, or how this search relates to other market-related tools, making it feel incomplete in a broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description partially compensates by specifying that the search_term is used for matching by name or keyword. However, it does not explain the matching logic, case sensitivity, or result scope, leaving some ambiguity about the parameter's exact behavior.
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 'Search' with a clear resource ('IG markets') and an explicit qualifier ('by name or keyword'). This unambiguously distinguishes it from sibling tools like 'market_details' or 'historical_prices', which serve different purposes.
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 that the tool is used when you need to find markets by name or keyword, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'bounded' updates and supported types, but omits critical traits like whether this is a long-lived stream, how timeout/updates parameters affect behavior, or any side effects. This is insufficient for a tool with no annotation safety hints.
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, concise and front-loaded with the core action. Every word adds value: 'bounded' conveys scope, and the supported/excluded lists are relevant differentiators. No fluff.
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 tool has 6 parameters and no annotations. The description does not explain the streaming semantics, how to configure the number of updates or timeout, or the nature of the return value beyond 'updates'. This is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not explain any of the 6 parameters, only indirectly maps 'kind' via the subscription types. The meaning of 'epic', 'scale', 'updates', 'account_id', and 'timeout_seconds' is left to the reader's inference, which is inadequate given zero 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 clearly states the tool collects bounded Lightstreamer updates, a specific verb and resource. It distinguishes itself by listing supported subscription types (PRICE, ACCOUNT, TRADE, CHART) and explicitly excluding deprecated MARKET, making it unique among the sibling 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?
The description gives clear context on which subscription types are supported and that MARKET is excluded, providing a form of when-to-use guidance. It does not name specific alternative tools, but given the sibling list contains no other streaming tool, this is sufficient.
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 mentions the need for confirmation ('Requires confirm=true') but does not disclose side effects, reversibility, or impact on the current session. Switching accounts is a state-changing operation, and the description fails to explain what happens to existing sessions or whether the switch is permanent. This lacks sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences: 'Switch the active IG account. Requires confirm=true.' Every word earns its place, and the key information is front-loaded in the first sentence. There is no fluff or repetition, making it an example of effective minimalism.
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 that this is a state-changing tool with no annotations and an output schema (not detailed), the description is incomplete. It does not explain how to identify the target account, what 'default_account' does, or the consequences of switching. The single mention of confirm is not enough to fully guide an agent. A more complete description would cover account_id selection, default_account behavior, and potential side effects.
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 elaborate on the parameters. It mentions 'confirm' as required, but ignores 'account_id' (which is the only required parameter) and 'default_account'. The schema provides basic types and defaults, but the description does not explain what these parameters mean or how they relate. This leaves significant ambiguity for the agent.
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: 'Switch the active IG account.' It uses a specific verb (Switch) and resource (active IG account), which distinguishes it from sibling tools like 'accounts' or 'session_details'. The purpose is unambiguous and directly matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies a required precondition: 'Requires confirm=true.' This tells the agent that the operation cannot succeed without setting the confirm parameter. While it does not explicitly mention alternatives or exclusions, the context is clear: use this tool when you need to switch the active account. The guidance provided is more than a vague hint.
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 bears full responsibility for disclosing behavioral traits. It only states the condition for updating but does not explain side effects, what happens when updates are provided but confirm=false, or any permission/safety implications. The tool can mutate state but this is not highlighted beyond the conditional wording.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action (get) and clearly adds the update variant with a condition. Every word earns its place, with no unnecessary filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's dual get/update nature and lack of annotations, the description provides the core rule but omits important edge cases (e.g., behavior when updates are provided but confirm=false) and does not specify what account preferences are returned or modified. The output schema exists, so return values need not be detailed, but the tool's overall behavior is only partially specified, making it adequate but not fully complete.
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 explain parameter meaning. It mentions 'updates' and 'confirm' but only in the conditional context, not explaining the structure of updates (an object of preference fields) or the role of confirm (acknowledging/authorizing the update). This leaves the agent guessing on parameter formats and interplay.
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 dual purpose: retrieving account preferences, and updating them under a specific condition (updates provided and confirm=true). The verb 'get' and 'update' specify actions on the 'account preferences' resource, and the conditional logic distinguishes the two modes without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use the tool: by default it retrieves preferences; if updates are provided and confirm=true, it updates. However, it does not mention alternative tools (e.g., accounts or session_details for related account functions) or exclusion criteria, so it falls short of explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the confirm requirement as a behavioral prerequisite but does not state that deletion is irreversible, any permission needs, or what happens on success/failure. The confirm hint adds some value but leaves key side effects unstated.
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 contains no redundancy. Every word contributes to understanding the core purpose and a key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers the basics but omits important context such as irreversible effects, authorization requirements, or what happens after deletion. The presence of an output schema reduces the need to explain return values, but behavioral context is still incomplete.
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 description coverage is 0%, so the description must explain the parameters. It only mentions that confirm=true is required, but does not explain the meaning of deal_id or the purpose of confirm beyond being a flag. This is insufficient for a 2-parameter 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 action (delete) and the resource (OTC working order), distinguishing it from sibling tools like create_working_order or update_working_order. The specificity of 'OTC working order' narrows the 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?
The description implicitly indicates when to use the tool (for deleting OTC working orders) and mentions the confirm requirement. However, it does not explicitly contrast with alternatives such as close_position or mention any scenarios where deletion is not appropriate.
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 full burden. It discloses that the update requires confirmation, a useful safety-related trait. But it omits other behavioral details such as permissions, what happens if confirm is missing, or side effects, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, making it highly concise. However, it is almost too terse, omitting essential details, which slightly reduces its score relative to a perfectly balanced 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?
Given it is a mutation tool with a nested arbitrary update object and no annotations, the description is far too incomplete. It provides no information on permitted update fields, expected behavior, or response format, making it inadequate for safe and correct invocation.
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 only clarifies the confirm parameter (must be true), while deal_id and the arbitrary update object are left entirely unexplained, forcing the agent to guess their structure and purpose.
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 'Update' and the clear resource 'an OTC working order', immediately distinguishing it from sibling tools like create_working_order and delete_working_order. It leaves no doubt about the tool's core function.
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 states a concrete prerequisite ('Requires confirm=true') that must be satisfied for the operation to work, giving clear invocation context. However, it does not explicitly contrast with alternatives or mention when not to use it, so it stops short of a 5.
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 convey behavioral traits. It only states 'Get' which implies a safe read operation, but does not disclose any side effects, permissions, rate limits, or response handling. This is minimal disclosure for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core action and scope. No wasted words, yet it conveys the key parameter distinctions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two optional parameters and an output schema, the description covers the main invocation patterns. It does not explain edge cases like parameter precedence, but the output schema likely covers return format. Overall, sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It does so by mapping the two parameters: 'all markets' corresponds to null market_id, 'one market' to a specific market_id, and 'related' to the related flag. This provides semantic clarity beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves client sentiment, with explicit scope variations ('all markets, one market, or related markets'). This distinguishes it from sibling tools like market_details or historical_prices, which focus on different data types.
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 when sentiment data is needed, but does not explicitly say when to prefer this over alternatives or provide exclusion criteria. The scope phrasing gives some context for parameter usage, but no formal guidance on when to use versus other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It warns that 'This can place a trade,' which signals irreversible financial action and confirms the need for the confirm flag. However, it does not explain what happens when confirm=false or describe any additional prerequisites or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning their place. The first states the core purpose, and the second flags the critical trade-execution behavior. No filler or redundant content.
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 complexity of a financial trade tool with an open-ended order object and no schema descriptions, the description is too sparse. It lacks guidance on the structure of the order payload, what happens without confirm=true, or error/validation conditions. While an output schema exists, the input side is under-specified for an agent to invoke reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to 'order' by labeling it an 'IG order payload' and clarifies the purpose of 'confirm' ('requires confirm=true'). However, the order object is open-ended with additionalProperties allowed, and the description does not detail its expected internal fields, leaving significant ambiguity.
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 precisely states the action ('Create an OTC position') and the input source ('from an IG order payload'), clearly distinguishing this from sibling tools like create_working_order or close_position. It also clarifies that this is a direct trade placement, not a scheduled order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'requires confirm=true,' which is a key usage condition: the agent must set confirm to true to actually place the trade. It implies that this tool is for immediate OTC positioning rather than alternative order types, though it does not explicitly contrast with siblings.
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 implies a read-only operation through 'list' and 'get', but does not explicitly state that it is non-mutating, nor does it mention authentication requirements, error handling, or any 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 immediately communicates the tool's function, with no wasted words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, output schema available), the description adequately covers the two modes of operation. It does not mention pagination or edge cases, but for a read-only list/get tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the role of watchlist_id: when present, it fetches a specific watchlist; when absent, it lists all. This adds meaning beyond the bare schema, which only shows an optional string parameter with no description.
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 watchlists or fetches a specific one by ID, using specific verbs ('List' and 'get') and a distinct resource. This distinguishes it from the sibling mutate_watchlist, which implies 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: providing watchlist_id retrieves one watchlist, omitting it lists all. However, there is no explicit guidance on when to prefer this tool over alternatives like mutate_watchlist, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys a read-only intent via the verb 'List' and scopes to the authenticated client, but it does not disclose details such as authentication requirements, possible empty results, or side effects. For a simple list operation, this is minimally adequate.
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 the verb and resource. It contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a present output schema, this simple one-sentence description fully identifies the tool's purpose. No additional context is necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already imposes no burden. The baseline of 4 applies because no parameter-specific description is needed and none is provided.
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') and the resource ('the authenticated client's IG accounts'), which distinguishes this from sibling tools like account_preferences or switch_account that deal with preferences and account switching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The agent is left to infer that this is the tool for listing accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of conveying behavior. It indicates a read-only operation ('list', 'get') but does not disclose response format, pagination, or behavior when no positions exist. The read-only nature is implied but not explicitly stated, and no additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys both main usage modes with no unnecessary words. It is an excellent example of concise, efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one optional parameter and an existing output schema, the description is nearly complete. It explains the two modes of operation. It slightly lacks clarity on the default behavior (listing all when deal_id is omitted), but the schema's default value helps fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explicitly explains that deal_id is used to retrieve a specific position, providing functional context beyond the raw schema. This sufficiently compensates for the lack of parameter documentation.
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+resource structure: 'List open positions' and also identifies the alternative use case 'get one by deal ID'. This clearly distinguishes it from sibling tools like create_position or working_orders.
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 (list all vs. get by ID) but provides no explicit exclusion or comparison with alternatives. It doesn't mention when to prefer this tool over working_orders or other position-related tools, leaving the agent to infer from the name and siblings.
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?
Without annotations, the description conveys that the tool seeds from REST and updates from stream data, but lacks details on side effects (e.g., whether it writes or only reads), lifecycle, or error handling. It does indicate data sources, but not the full behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that clearly state the workflow and when to use REST instead. It is front-loaded with the primary action and includes necessary context without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that combines REST and streaming, the description explains the seed-then-update flow and the completed-candle alternative, but lacks details on output format, subscription lifecycle, or error handling. Since no output schema or annotations are provided, the description covers the essential usage but leaves some implementation specifics undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives context that the stream data is 5-minute and that REST is used for completed candles, which infers some parameter meaning (like timeframe), but it does not explicitly explain 'epic' or other parameter nuances beyond what the schema likely states. It adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to seed an in-progress OHLC candle from REST data and then update it from 5-minute chart stream data. It distinguishes itself from sibling tools like stream_updates and historical REST price tools by specifying the combined approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: use REST for historical (completed) candles and seed/update from stream for in-progress candles. The description clearly delineates when to use this tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that no session tokens are requested, which is a useful behavioral trait. However, it does not detail whether the operation is read-only, if authentication is required, or what specific session information is returned. It adds some value but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose and its key distinguishing trait. No wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return values, and the tool's simplicity (no parameters) means the description is largely sufficient. It could benefit from noting prerequisites like being authenticated, but the overall context is adequately handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly implies no inputs are needed, and there is no parameter information to compensate for. This aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of the current IG session, using a specific verb ('Get') and resource ('current IG session'). It also distinguishes itself from sibling tools by noting it does not request session tokens, making its purpose 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?
The phrase 'without requesting session tokens' provides a clear usage context, indicating when this tool is appropriate (when you need session details but want to avoid token handling). However, it does not explicitly mention alternatives or exclusions, but given the simplicity, this is sufficient.
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 must convey behavior. It clearly states the tool lists open working orders for the active account, which implicitly indicates a read-only operation. There is no mention of pagination or side effects, but for a simple listing tool this is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the exact purpose without any filler words. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers the essential information needed for an agent to select and invoke it. It is complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description adds context by specifying the scope ('active account'). With no parameters to explain, the baseline of 4 is appropriate.
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 'List' with the resource 'open working orders' and scopes it to 'the active account.' This clearly distinguishes it from sibling tools like create_working_order, update_working_order, and delete_working_order, which are mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear read-only use case for listing open working orders in the current account context. It does not explicitly mention alternatives or exclusions, but the resource and action are distinct enough from siblings to guide selection.
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-simple MCP server](https://glama.ai/mcp/servers/MarkHorwell/ig-integration-mcp-simple/badges/card.svg)](https://glama.ai/mcp/servers/MarkHorwell/ig-integration-mcp-simple)

Score Badge

Copy to your README.md:

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

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-simple'

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