HTS MetaTrader5 Trading MCP

by Yumin-Kim

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource/action: accounts, candles, positions, orders, and internal queues. Even similar tools like get_accounts vs get_account and get_candles vs get_bulk_candles are clearly differentiated by singular/plural and bulk/single scope.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_accounts, open_order, close_position). The naming is uniform and predictable, with no mixed styles or vague verbs.
Tool Count5/5
14 tools is well-scoped for a trading server, covering account info, market data, order management, position management, and internal queue monitoring. Each tool earns its place without feeling excessive or sparse.
Completeness4/5
Core trading lifecycle is covered: accounts (get), market data (candles), pending orders (open/modify/cancel/list), and open positions (close/modify/list). Minor gaps include lack of real-time price quotes and historical trade/deal history, but these are workaroundable.
Average 3.7/5 across 14 of 14 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. While the verb 'Get' and the word 'Shows' imply a read-only operation, there is no explicit statement about side effects, such as whether reading the queue consumes or clears entries, nor any information about rate limits or permissions. This is a notable gap for a queue-operation tool.
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 brief and front-loaded, with the core action stated first. The inclusion of a Korean translation is redundant but not harmful; it adds a few extra words without obscuring the meaning. Overall, it is concise and well-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?
For a simple parameterless tool, the description covers the basic purpose and content of the result, but it lacks context about the return format, pagination, or relationship to sibling tools like get_handler_result. Given the absence of an output schema and usage guidance, the description is only minimally adequate.
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 accepts zero parameters, so the description does not need to explain parameter details. The baseline for a parameterless tool is 4, and the description appropriately focuses on the tool's purpose rather than adding irrelevant parameter semantics.
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 identifies the tool as retrieving handler queue status and specifies that it shows command execution results from EA. This is more specific than a mere restatement of the name, though it does not explicitly contrast with sibling tools like get_handler_result or get_command_queue, so it stops 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?
The description offers no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or how it differs from get_handler_result or get_command_queue, leaving the agent without contextual selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the operation without disclosing behavioral traits such as read-only nature, error handling, or return format. For a read operation, it doesn't specify what happens if the command ID is not found or whether the result is always available.
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, concise and front-loaded with the core action. The redundant Korean translation in parentheses adds no information but doesn't significantly hurt readability. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should clarify what a handler result contains and how errors are handled, but it doesn't. The tool is simple with one parameter, but the lack of behavioral context makes it incomplete for an agent to fully understand invocation consequences.
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 input schema already describes commandId as 'Filter by command ID', and the description simply repeats this without adding extra meaning, format details, or constraints. With 100% schema coverage, the baseline of 3 applies.
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 'Get' with the resource 'handler result' and scope 'by command ID', making it clear what the tool does. It distinguishes itself from the sibling tool get_handler_queue, which likely lists the queue, by emphasizing retrieval of a specific result.
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 phrase 'by command ID' implies usage when a specific command ID is known, but it does not explicitly state when to use this tool over alternatives like get_handler_queue or when not to use it. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description only repeats the core action without disclosing side effects, failure modes, or behavior when the order is not pending. The qualifier 'pending' adds minimal scope but lacks detail about cancellation semantics, idempotency, or error handling.
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 unnecessary words. The Korean translation is redundant but not harmful, and the entire description earns its place by clearly stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter, but as a mutating operation with no annotations or output schema, the description would benefit from stating what happens if the order is not pending or whether cancellation is idempotent. It is adequate but leaves behavioral gaps.
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 input schema fully documents the single 'ticket' parameter with a clear description ('Order ticket number to cancel'). The description adds no additional parameter semantics, so the baseline of 3 is appropriate given full 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 ('Cancel') and resource ('a pending order'), clearly stating the tool's action. It differentiates from sibling tools such as open_order, modify_order, and close_position by specifying cancellation of pending orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like modify_order or close_position. The description does not mention prerequisites, exclusions, or context for choosing this tool.
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 discloses that it works on an open position and can be full/partial, but it does not mention side effects (e.g., irreversibility, impact on associated orders, asynchronous execution, or error conditions). This is a significant gap for a mutating trading operation.
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 in English and equivalent Korean, front-loading the key verb and resource. No wasted words, perfectly sized for an operation already well-documented by the schema.
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?
No output schema exists, and the description does not explain return values or execution flow. Sibling tools like get_command_queue and get_handler_result suggest this operation may be queued asynchronously, but the description omits such crucial context, leaving the agent without guidance on what to expect after invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for both parameters (ticket and volume) are fully explicit, with volume noting that it 'closes full position if not specified.' The description adds no additional parameter semantics beyond restating 'full or partial.' With 100% schema coverage, a baseline of 3 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 clearly states the tool's function: 'Close an open position (full or partial).' The verb 'close' is specific, the resource 'open position' is defined, and the scope (full/partial) is noted. This distinguishes it from siblings like open_order, modify_position, and cancel_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 provides clear context by indicating that the tool supports full or partial closure, implying when it should be used (e.g., to reduce exposure). However, it does not explicitly exclude alternatives like modify_position for partial reductions 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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the prerequisite that the position must be open, but does not explain consequences of modifying, whether partial updates are allowed, error conditions, or whether it requires special permissions. For a mutation tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one English sentence plus a Korean translation. It front-loads the essential purpose with no filler or unnecessary details. Every word earns its place.
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 3-parameter tool with no output schema, the description adequately states the core functionality. It clearly defines the scope (SL/TP only) and the target (open position). While it could mention error handling or the need for at least one of sl/tp, those are partially covered by the schema's required field ticket and optional flags. Overall, it is reasonably complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no meaningful meaning beyond the schema—it simply paraphrases the sl and tp parameters by saying 'stop loss and/or take profit', which the schema already defines as optional numbers. No credit for redundancy.
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 'Modify' and the resource 'open position', specifying the exact attributes (stop loss and/or take profit). It distinguishes itself from sibling tools like modify_order (orders vs positions) and close_position (closing vs modifying).
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 open positions via the phrase 'open position', but does not explicitly mention when not to use it or provide alternative tool names. It lacks explicit exclusions or alternative guidance, making it minimally 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 states the operation is 'Get', but does not explicitly confirm read-only behavior, describe what the returned information includes, or mention any error cases or prerequisites beyond the parameter. It adds no behavioral context beyond the name and parameter.
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 English sentence with a parenthetical Korean translation. It wastes no words and directly states the core purpose, though the bilingual addition is redundant but not harmful.
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 simple with one parameter and no output schema, so the description is adequate for basic understanding. However, it does not hint at the structure of the returned account information (e.g., fields like balance, margin), which would be useful in absence of an output schema. It meets the minimum viable level.
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 100% for accountNumber ('EA 계정 번호'), and the description redundantly mentions 'by account number'. It adds no extra meaning or format details beyond the schema, so baseline 3 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 a specific verb 'Get' with a clear resource 'specific trading account information' and explicitly scopes it by account number, distinguishing it from sibling tool get_accounts which suggests listing all accounts.
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 context is clear: use this tool when you need a specific account's information by its account number. It implies the need for a known accountNumber, and the 'specific' wording contrasts with the plural sibling, but it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the obvious 'get accounts' behavior without detailing return format, authentication requirements, or what 'all' encompasses. The description adds no behavioral context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the essential purpose. The bilingual translation is redundant but does not detract from clarity or efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should provide more context about the return value or behavior. It does not explain what information is returned or clarify the difference from 'get_account', leaving the agent with an incomplete picture.
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 description is not required to add parameter meaning. The baseline for 0-parameter tools is 4, and the description correctly avoids unnecessary parameter detail.
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 action ('Get') and resource ('all trading accounts information'). The word 'all' distinguishes it from the sibling 'get_account', which likely retrieves a single account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for retrieving all accounts but does not explicitly state when to use it versus 'get_account'. No alternatives or exclusion conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds meaningful context: it sends a command to an EA, blocks waiting for results up to 60 seconds, and returns OHLC data. This goes beyond a simple 'get' and alerts the agent to potential latency and synchronous behavior. It does not cover error handling or side effects, but the disclosed details are valuable.
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 compact with two clear sentences, and the main verb and object appear at the start. However, the Korean translation is a redundant duplicate for an English-language context, which prevents a perfect score. It is still concise and free of unnecessary filler.
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 relatively simple tool with 3 parameters and no output schema, the description provides sufficient context: what it does, the waiting behavior, and the response content. It does not detail the limit parameter's behavior, but the schema covers that. The absence of error-handling details is a minor gap, but overall the tool is understandable for selection and invocation.
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 description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics; it only mentions the return value (OHLC) which is not directly tied to a parameter. The schema already explains symbol, timeframe, and limit with examples, so the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Get historical candle data for a forex symbol.' It is specific about the data type (candles) and the domain (forex). However, it does not differentiate from the sibling tool get_bulk_candles, which also fetches candle data, so it loses a point for lack of sibling distinction.
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 guidance is implied rather than explicit. The description gives context that this tool sends a command to an EA and waits, but it does not explicitly state when to choose this tool over get_bulk_candles or other alternatives. No exclusions or alternative recommendations are provided.
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 explains execution behavior (immediate vs pending) and highlights the SELL_STOP constraint, which is useful. Yet it omits side effects (e.g., margin requirements), error conditions, and what the tool returns on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bulleted list that makes order types scannable. It front-loads the purpose and includes a Korean translation, though it duplicates schema content and the translation is extraneous for many users. Overall, it's efficient but slightly repetitive.
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?
With 8 parameters, no output schema, and no annotations, the description should provide more operational context. It covers order type semantics well but lacks return value details, error behavior, and prerequisites like account status or margin. The schema handles parameter explanations, so the description could have enriched the context further.
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 100%, so the description doesn't need to explain parameters. It adds a bit by emphasizing the SELL_STOP rule, but the rest of the order type details are already in the schema's type description. The description provides minimal added semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Open a new trading order (market or pending)' with a specific verb and resource. It distinguishes itself from siblings like cancel_order, modify_order, and close_position by focusing on creation, and the order type list further clarifies 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening line clearly indicates when to use this tool (to open a new order), and the order type explanations help choose the right type. However, it does not explicitly state alternatives for modifying or canceling existing orders, though the sibling names make this obvious.
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 it gets 'all' pending orders and supports optional symbol filtering, but it does not mention return format, pagination, or potential errors. This is acceptable for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the key action and resource front-loaded, followed by the optional filter. The bilingual repetition does not add unnecessary length or complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description adequately covers purpose and parameter. It could mention return structure, but the tool's simplicity and the word 'all' imply a complete list, making it reasonably complete.
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 already describes the symbol parameter with 100% coverage, and the description simply restates that filtering is optional. No additional meaning is added beyond what the schema provides, so the baseline score of 3 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 'Get' with the resource 'pending orders' and clearly states the optional symbol filter. This clearly distinguishes it from sibling tools like get_accounts and get_positions by specifying the pending order state.
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 clearly implies this tool is for retrieving pending orders, providing clear context for when to use it. However, it does not explicitly name alternatives or exclusion criteria, so it stops short of full usage 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?
No annotations are provided, so the description carries the full burden. The word 'Get' implies a read-only operation, but the description does not disclose any additional behavioral traits such as return format, potential errors, or lack of side effects. It is minimal but not misleading.
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 in English and Korean, front-loaded with the purpose. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is sufficiently complete. It states what the tool returns (open positions) and how to filter, which is adequate for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the schema already describing 'symbol' as 'Filter by symbol (optional).' The description restates this same information ('optionally filtered by symbol') without adding new meaning, so it relies on the schema for parameter depth.
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: 'Get all open positions, optionally filtered by symbol.' This clearly states the tool's function and distinguishes it from siblings like close_position and modify_position, which involve mutating positions rather than reading them.
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 provides clear context for when to use the tool: whenever open positions are needed, with an optional symbol filter. However, it does not explicitly state when not to use it or mention alternatives, but given the simple read-only nature, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key behavioral trait: 'Sends a command to EA and waits for the result (up to 120 seconds)', which is valuable for understanding latency and side effects. It also mentions the return of candle data, but lacks details on error handling or read-only nature.
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 three sentences, front-loaded with the main purpose. The Korean repetition duplicates content but is concise overall and does not contain unnecessary filler.
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 description explains the command-wait mechanism and states that it returns candle data for all requested timeframes. Since there is no output schema, this satisfies the need for return information. It is complete enough for the tool's complexity, though it omits potential error details.
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 100% with each property described in the schema. The tool description does not add extra parameter semantics beyond what the schema already provides, so the baseline score of 3 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 clearly states 'Get historical candle data for multiple timeframes at once' with a specific verb and resource. It distinguishes itself from the sibling tool 'get_candles' by emphasizing the multi-timeframe capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('for multiple timeframes at once') without explicit exclusions or alternatives. It provides clear context but doesn't explicitly say 'use this instead of get_candles when you need multiple timeframes'.
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 behavioral disclosure. It states that the tool shows pending commands, implying a non-mutating read operation, but does not explicitly confirm that it does not consume the queue, nor describe pagination, ordering, or error behavior. This is adequate but has gaps.
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 only two sentences plus a Korean translation, containing no filler. It is front-loaded and every sentence contributes meaning.
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 zero-parameter read-only query with no output schema, the description adequately explains the tool's purpose and what it returns. It lacks explicit detail about the response format or empty-queue behavior, but given the low complexity, it is reasonably complete.
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 description is not required to clarify parameter semantics. Its mention of 'pending commands waiting for EA' adds contextual meaning beyond the empty schema, though no params exist to elaborate on.
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 the current command queue status and lists pending commands waiting for the EA, using a specific verb and resource. It distinguishes from sibling get_handler_queue by explicitly referencing 'command queue' rather than 'handler queue'.
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 provides clear context: it is used to check pending commands that the EA will process. It does not explicitly mention when not to use it or point to alternatives like get_handler_queue, but the usage context is evident.
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 must disclose behavior on its own. It does this well by explaining the expiry auto-cancellation behavior, the Unix timestamp format, and the pending-order scope. It does not mention permissions or error scenarios, but these are less critical for a modification tool and the key behavioral side-effect is explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences (plus a Korean translation) that front-load the purpose and immediately list the modifiable fields and the critical expiry behavior. Every sentence adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description explains the operation, the modifiable fields, and the expiry side-effect clearly. It does not mention return values or error handling, but the schema covers all parameter semantics and the description gives sufficient context for an agent to select and invoke the tool correctly.
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 100%, and the schema already documents each parameter, including expiry behavior (auto-cancel) and types. The description adds minimal new meaning beyond rephrasing the schema fields, so a baseline score of 3 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 a specific verb 'Modify', identifies the resource as 'existing pending order', and explicitly lists the updatable fields (price, stop loss, take profit, expiration time). This clearly distinguishes it from sibling tools like modify_position or open_order, which operate on different resources.
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 provides clear context by restricting the operation to 'existing pending order' rather than new or filled orders, and enumerates the fields that can be updated. However, it does not explicitly name alternatives (e.g., 'use open_order for new orders') or state when not to use this tool, so it lacks the full 'when-not/alternatives' guidance for a 5.
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:

[![hts-mcp-server MCP server](https://glama.ai/mcp/servers/Yumin-Kim/hts-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Yumin-Kim/hts-mcp-server)

Score Badge

Copy to your README.md:

[![hts-mcp-server MCP server](https://glama.ai/mcp/servers/Yumin-Kim/hts-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Yumin-Kim/hts-mcp-server)

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/Yumin-Kim/hts-mcp-server'

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