Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gmocoin-fx-mcp place a market buy order for 1000 USD/JPY"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Register the server with an MCP client by using either stdio or HTTP.
The local checkout example below uses /path/to/gmocoin-fx-mcp; replace it with the absolute path to this repository.
The recommended setup is to run the published Docker image from GitHub Container Registry over stdio.
Add the following entry to your MCP client configuration:
{
"mcpServers": {
"gmocoin-fx": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"--env",
"GMO_API_KEY",
"--env",
"GMO_SECRET_KEY",
"--env",
"ORDER_SIZE_LIMIT",
"--env",
"ORDER_SYMBOL_LIMITS",
"--env",
"ORDER_CLIENT_ORDER_ID_PREFIX",
"ghcr.io/rikitonoto/gmocoin-fx-mcp:latest"
],
"env": {
"GMO_API_KEY": "your-api-key",
"GMO_SECRET_KEY": "your-secret-key",
"ORDER_SIZE_LIMIT": "10000",
"ORDER_SYMBOL_LIMITS": "USD_JPY,EUR_JPY",
"ORDER_CLIENT_ORDER_ID_PREFIX": "mcp"
}
}
}
}Only GMO_API_KEY and GMO_SECRET_KEY are required. Remove optional environment variables when you do not need order-size, symbol, or client-order-id limits.
The --env options pass those values from the MCP client process into the Docker container.
Do not set MCP_TRANSPORT for stdio; the server uses stdio by default.
The -i option is required because the MCP client communicates with the container over standard input/output.
Use this setup when you want to run the server from a local checkout instead of the published image:
{
"mcpServers": {
"gmocoin-fx": {
"command": "uv",
"args": [
"--directory",
"/path/to/gmocoin-fx-mcp",
"run",
"src/main.py"
],
"env": {
"GMO_API_KEY": "your-api-key",
"GMO_SECRET_KEY": "your-secret-key",
"ORDER_SIZE_LIMIT": "10000",
"ORDER_SYMBOL_LIMITS": "USD_JPY,EUR_JPY",
"ORDER_CLIENT_ORDER_ID_PREFIX": "mcp"
}
}
}
}Use HTTP when your MCP client supports remote or URL-based servers. Start the server:
docker run --rm \
--env MCP_TRANSPORT=http \
--env MCP_HTTP_HOST=0.0.0.0 \
--env MCP_HTTP_PORT=8000 \
--env MCP_HTTP_PATH=/mcp \
--env GMO_API_KEY=your-api-key \
--env GMO_SECRET_KEY=your-secret-key \
-p 8000:8000 \
ghcr.io/rikitonoto/gmocoin-fx-mcp:latestThen register the server URL in your MCP client:
http://localhost:8000/mcpRelated MCP server: Alpaca Trading MCP Server
Name | Required | Description |
| Yes | GMO Coin FX API key. |
| Yes | GMO Coin FX secret key. |
| No | Maximum order size accepted by the |
| No | Comma-separated list of symbols accepted by the |
| No | ASCII alphanumeric prefix used to auto-generate |
| No | MCP transport to use. Defaults to |
| No | Host/interface for HTTP transports. Defaults to |
| No | Port for HTTP transports. Defaults to |
| No | Optional endpoint path for HTTP transports, such as |
The server still starts with the standard stdio MCP transport by default:
uv run src/main.pyTo expose the MCP server over HTTP, set MCP_TRANSPORT=http before starting it:
MCP_TRANSPORT=http MCP_HTTP_HOST=0.0.0.0 MCP_HTTP_PORT=8000 uv run src/main.pyWhen running with Docker Compose, the compose file loads .env but does not force a transport. Leave MCP_TRANSPORT unset to use stdio, or set MCP_TRANSPORT=http in .env to use the published port 8000.
Name | Description |
| Places a new GMO Coin FX order. |
| Places a GMO Coin FX close order. Supports optional |
| Places a GMO Coin FX IFD order using |
| Places a GMO Coin FX IFDOCO order using |
| Changes prices for an existing GMO Coin FX IFDOCO order. Specify exactly one of |
| Changes prices for an existing GMO Coin FX IFD order. Specify exactly one of |
| Changes limit/stop prices for an existing GMO Coin FX OCO order. |
| Changes the price of a GMO Coin FX normal order. Specify exactly one of |
| Cancels up to 10 GMO Coin FX orders at once. Specify exactly one of |
| Cancels GMO Coin FX orders in bulk by required |
| Retrieves active GMO Coin FX orders. Supports optional |
| Retrieves the latest GMO Coin FX executions for a required |
| Retrieves all GMO Coin FX open positions. Supports an optional |
URI | Description |
| Retrieves GMO Coin FX account asset balances as JSON. Asset balances are exposed as an MCP resource because they are read-only account state with a stable URI and no invocation parameters. |
GMO Coin FXの有効注文一覧を取得します。
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| symbol | No | ||
| prev_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as pagination (implied by count and prev_id parameters), rate limits, authentication, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is appropriately sized for a simple purpose, though additional detail would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no annotations, the description is incomplete. It omits pagination details and does not leverage the output schema for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema; it does not explain what the parameters do. Schema description coverage is 0%, and the tool description provides no help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of active orders for GMO Coin FX, with a specific verb and resource, distinguishing it from siblings like cancel_orders_api or order_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like order_api or close_order_api. The description only states what it does, lacking context on use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXの注文を銘柄などの条件で一括キャンセルします。
| Name | Required | Description | Default |
|---|---|---|---|
| side | No | ||
| symbols | Yes | ||
| settle_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions bulk cancellation but omits details like whether it cancels only open orders, what happens if no matching orders exist, permission requirements, or any destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Japanese. While brief, it could be better structured with bullet points, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of bulk cancellation with multiple conditions, the description lacks important details: what return values to expect (despite an output schema existing), whether cancellation is synchronous, and clarification of the supported conditions (symbol, side, settle_type). Incomplete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes descriptions for each parameter (e.g., side, symbols, settle_type), so the schema coverage is effectively high. The description does not add extra meaning beyond what the schema already provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels GMO Coin FX orders in bulk by conditions like symbol. It is specific about the action and resource, but does not distinguish from sibling tools like cancel_orders_api which might target individual orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as cancel_orders_api or close_order_api. There are no exclusions or context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXの注文を最大10件までまとめてキャンセルします。
| Name | Required | Description | Default |
|---|---|---|---|
| root_order_ids | No | ||
| client_order_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It mentions max 10 but omits side effects, error handling, authentication needs, or what happens if orders are already canceled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It fails to organize information like parameter details or usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two optional parameters, no annotations, and an output schema (unseen), the description is highly incomplete. It misses critical information for correct invocation, such as how to specify order IDs or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the two parameters (root_order_ids, client_order_ids). An AI cannot determine how to specify which orders to cancel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel), resource (orders), and constraints (up to 10, GMO Coin FX). It differentiates from siblings like change_order_api but not explicitly from cancel_bulk_order_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-not or alternative guidance is provided. With multiple cancellation-related siblings (cancel_bulk_order_api, close_order_api), the description should specify when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXのIFDOCO注文を変更します。
| Name | Required | Description | Default |
|---|---|---|---|
| first_price | No | ||
| root_order_id | No | ||
| client_order_id | No | ||
| second_stop_price | No | ||
| second_limit_price | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 only states the action ('change') without any details on idempotency, side effects, authentication requirements, rate limits, or consequences of invocation. The agent cannot assess safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but front-loads the core action. However, it sacrifices necessary detail, resulting in under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters, no annotations, and an output schema (not shown), the description is severely lacking. It provides no context about expected behavior, parameter relationships, or what the output represents. The agent would need to infer too much from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate for parameter meaning. It does not explain any of the five parameters (first_price, root_order_id, etc.). While parameter names are somewhat self-explanatory, the description adds no value to understanding parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: changing an IFDOCO order for GMO Coin FX. It uses a specific verb ('変更する' = change) and resource ('IFDOCO注文' = IFDOCO order), which distinguishes it from siblings like change_ifd_order_api and change_oco_order_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description does not specify prerequisites, context, or when not to use it. Siblings offer similar functionality for different order types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXのIFD注文を変更します。
| Name | Required | Description | Default |
|---|---|---|---|
| first_price | No | ||
| second_price | No | ||
| root_order_id | No | ||
| client_order_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as idempotency, side effects, or required permissions. It merely states the action without elaboration on what changes are possible or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence), but it lacks critical information that would justify its brevity. It does not earn its place as it omits essential details, making it insufficient rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies IFD orders with 4 nullable parameters and no annotations, the description is severely incomplete. It fails to clarify parameter roles, order identification, or result expectations, even with an output schema present but not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (first_price, second_price, root_order_id, client_order_id). Their meaning and usage remain entirely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes IFD orders for GMO Coin FX, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like change_ifdoco_order_api or change_oco_order_api, leaving the distinction to the tool name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any prerequisites or conditions for use. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXのOCO注文変更を実行します。
| Name | Required | Description | Default |
|---|---|---|---|
| stop_price | No | ||
| limit_price | No | ||
| root_order_id | No | ||
| client_order_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'execute change' without revealing any side effects, permissions, failure conditions, or whether the operation is destructive. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. However, this brevity sacrifices essential information needed for correct tool invocation. It is not a model of efficiency because it omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, many siblings, no annotations, no param descriptions), the description is incomplete. It does not define OCO orders, explain the meaning of root_order_id vs client_order_id, or describe expected outcomes. Although an output schema exists, the description fails to provide enough context for an agent to use this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description does not explain any of the four parameters (stop_price, limit_price, root_order_id, client_order_id). While some are self-explanatory for a trading domain, the description adds no semantic value beyond what a user might guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'execute' and resource 'OCO order change' for 'GMO Coin FX', clearly identifying the tool's action and domain. However, it does not distinguish this tool from siblings like change_order_api or change_ifd_order_api, which change other order types. A specific differentiation is missing for a trading context with 13 siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when an OCO order is already active or how it differs from changing non-OCO orders. No prerequisites or context are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXの通常注文価格を変更します。
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | ||
| order_id | No | ||
| client_order_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It does not disclose side effects, required permissions, rate limits, or what happens on failure (e.g., order not found). Only the basic action is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words, but it lacks structure (e.g., no separation of purpose from usage). It is minimal but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema (not shown), the description omits crucial details like parameter format, prerequisites, or return behavior. It is insufficient for an agent to correctly invoke the tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no explanation for the three parameters (price, order_id, client_order_id). It fails to clarify the distinction between order_id and client_order_id or provide any context for how price is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes the price of a regular order in GMO Coin FX, specifying the verb ('change') and resource ('regular order price'). It implicitly distinguishes from sibling tools like change_ifd_order_api and change_oco_order_api by specifying 'regular order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Sibling tools like cancel_orders_api or order_api are not mentioned, and there are no context or prerequisites described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXの決済注文を実行します。
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | 売買区分 BUY: 売 SELL: 買 | |
| size | No | ||
| symbol | Yes | 銘柄 | |
| stop_price | No | ||
| limit_price | No | ||
| lower_bound | No | ||
| upper_bound | No | ||
| execution_type | Yes | 注文タイプ | |
| client_order_id | No | ||
| settle_position | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It only states the action ('executes'), with no mention of side effects, required permissions, error handling, or state changes. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but far too short for a tool with 10 parameters and complex optional fields. It sacrifices necessary detail for brevity, resulting in under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count and presence of an output schema, the description is severely incomplete. It does not explain the tool's role in a multi-step FX trading workflow, how to specify positions to close, or interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, yet the description adds zero information about any parameters. It fails to explain key parameters like settle_position, execution_type, or side, leaving the agent without meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool executes settlement orders for GMO Coin FX, which is a specific verb and resource. While it differentiates from sibling tools (e.g., order_api for opening orders) by name and context, the phrase 'settlement order' may not be immediately clear to all users, but overall purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as needing open positions or prerequisites. It does not mention any context or exclude any scenarios, leaving the agent to infer usage from surrounding tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXのIFDOCO注文を実行します。
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | ||
| first_side | No | ||
| first_size | No | ||
| first_price | No | ||
| second_size | No | ||
| client_order_id | No | ||
| second_stop_price | No | ||
| second_limit_price | No | ||
| first_execution_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether the order is destructive, requires authentication, or has side effects. A one-line execution description is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but severely underspecified. It lacks important details that every sentence should provide, making it too minimal for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and an output schema not shown, the description is incomplete. It does not explain IFDOCO order mechanics, parameter relationships, or constraints, leaving the agent without enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% (despite some Japanese descriptions in the schema), and the tool description adds no meaning beyond the parameter names. With 9 parameters, the agent receives no guidance on how to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it executes IFDOCO orders for GMO Coin FX, which adds context beyond the tool name. However, it does not explain what IFDOCO means or differentiate it from sibling tools like 'ifd_order_api' and 'order_api', leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as 'ifd_order_api' or 'change_ifdoco_order_api', nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXのIFD注文を実行します。
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | ||
| first_side | No | ||
| first_size | No | ||
| first_price | No | ||
| second_size | No | ||
| second_price | No | ||
| client_order_id | No | ||
| first_execution_type | No | ||
| second_execution_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authorization needs, rate limits, or error behavior. The single sentence offers no transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence, which is concise but lacks structure and fails to provide enough detail. It could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no annotations, no parameter descriptions), the description is grossly incomplete. It does not explain IFD order mechanics, parameter roles, or return values, leaving the agent without sufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, meaning the schema provides no parameter explanations. The description adds zero semantic information about the 9 parameters, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as executing an IFD order for GMO Coin FX, specifying the resource and action. It distinguishes from sibling tools like order_api and ifdoco_order_api, but lacks explanation of what an IFD order entails, which may reduce clarity for unfamiliar agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description does not mention context, prerequisites, or situations where another tool might be preferable, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXのKline APIです。ローソク足、OHLC、価格履歴、為替レート履歴、チャート用の時系列データを取得します。price_typeは必須です（BID/ASK）。dateはYYYY-MM-DD形式で指定してください。
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| symbol | Yes | 銘柄 | |
| interval | Yes | ||
| price_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It specifies that price_type is required and date format is YYYY-MM-DD, which are helpful constraints. However, it does not mention that the tool is read-only, nor does it describe any rate limits, pagination, or error behavior. Being a data retrieval tool, the read-only nature is expected but not 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the core purpose and then adding essential parameter hints. Every sentence adds value: identification, data types, parameter requirements. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (4 parameters, all with enums or format constraints) and the presence of an output schema (not shown but indicated), the description covers the key inputs and purpose. It does not address time zone or data range, but these are secondary and often inferable. For an agent, this is largely sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 25% (only symbol has a description). The tool's description adds the date format (YYYY-MM-DD) and clarifies that price_type is required (though it is already listed as required in the schema). It does not elaborate on interval or symbol beyond the schema's enum lists. Overall, it provides moderate additional value for one parameter but does not fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies it as a Kline API for GMO Coin FX and lists the types of data retrieved (candlestick, OHLC, price history, etc.). The verb '取得' (retrieve) is specific, and the resource ('Kline API') and domain (FX) are explicit. The sibling tools are all order/position management, so this tool's data retrieval purpose is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical price data retrieval, and the sibling tools (all order-related) provide implicit contrast. However, it does not explicitly state when not to use this tool (e.g., for placing orders) or provide alternatives. The context is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXの最新約定一覧を取得します。
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| symbol | Yes | 銘柄 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'retrieve latest executions' without any behavioral details such as mutability, rate limits, or whether it's read-only. This is insufficient for understanding side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Japanese, effectively communicating the core purpose without verbosity. However, it lacks front-loaded structure or additional breakdown.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (not detailed), the description need not explain return values. However, for a tool with only 2 parameters, the description is too sparse—it does not acknowledge that symbol is required or that count is optional, which a complete description should hint at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 50% description coverage (symbol has a generic label, count has none). The description does not mention parameters or add semantic meaning beyond the schema, failing to clarify their purpose or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (retrieve) and resource (latest execution list) for GMO Coin FX. It distinguishes from sibling tools, which are mostly order-related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent executions, but does not explicitly state when to use this tool versus alternatives like active_orders_api or open_positions_api. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXの建玉一覧を取得します。
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions retrieval but omits details like authentication requirements, rate limits, or whether it returns all positions without pagination. The output schema exists but the description adds no behavioral 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct Japanese sentence that efficiently conveys the tool's purpose. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and an output schema, the description adequately identifies the resource but lacks details on response format or special behaviors. It is minimally complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the single parameter 'symbol' at all. With schema description coverage at 0%, the description should compensate but fails to add any meaning beyond what the schema provides (minimal). This leaves the agent without guidance on how to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb '取得' (get/retrieve) and resource '建玉一覧' (open positions list) for 'GMO Coin FX', making the tool's purpose specific and unambiguous. It distinguishes itself from sibling tools like order and execution operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description simply states what it does, leaving the agent to infer context from the tool name and sibling tools. No exclusions or when-not-to-use information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GMO Coin FXの新規注文を実行します。
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | 売買区分 BUY: 売 SELL: 買 | |
| size | Yes | ||
| symbol | Yes | 銘柄 | |
| stop_price | No | ||
| limit_price | No | ||
| lower_bound | No | ||
| upper_bound | No | ||
| execution_type | Yes | 注文タイプ | |
| client_order_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'execute new order' without mentioning authentication needs, rate limits, side effects (e.g., order placed on exchange), or error handling. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but overly terse for a tool with 9 parameters. It establishes purpose but lacks structure and additional details that would fit in a brief description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count and sibling tools, the description is incomplete. It does not explain order types, parameter relationships, or return value behavior. Although an output schema exists, its presence is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only side, symbol, execution_type have descriptions). The tool description adds no parameter information, so it fails to compensate for the low coverage. Many parameters like size, stop_price, limit_price remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'new order for GMO Coin FX' with the verb 'execute', clearly indicating the tool places a new order. This distinguishes it from siblings like cancel_orders_api or change_order_api.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ifd_order_api or ifdoco_order_api. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1active_orders_apicancel_bulk_order_apicancel_orders_apichange_ifd_order_apichange_ifdoco_order_apichange_oco_order_apichange_order_apiclose_order_apiifd_order_apiifdoco_order_apikline_apilatest_executions_apiopen_positions_apiorder_apiMost tools have clear distinct purposes (cancel, change, order types, market data). However, there is potential confusion between cancel_orders_api and cancel_bulk_order_api, and the absence of an OCO creation tool alongside change_oco_order_api may cause ambiguity.
Tool names are mostly snake_case and share the '_api' suffix, but there are inconsistencies: 'kline_api' uses a noun instead of verb_noun, and while most tools follow 'verb_noun', some like 'active_orders_api' use adjective_noun. The naming pattern is not uniformly applied.
With 14 tools covering order management, market data, and position tracking, the number is well-suited for an FX trading server. It's neither too sparse nor overly complex.
The tool set covers core trading operations (orders, modifications, cancellations, market data, positions). However, the lack of an OCO order creation tool is a notable gap, and there is no specific order detail retrieval tool beyond listing active orders.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Trade 16 crypto exchanges + MetaTrader 5 from your AI assistant via one MCP connection.
Trade across 22+ exchanges and brokers from any MCP-capable AI agent, no install required.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Live & historical FX rates and currency conversion for AI agents. No API keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RikitoNoto/gmocoin-fx-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
