Click on "Deploy 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., "@ATAS MCP Bridge Show me the current order book depth and recent trades for NQ."
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.
Model Context Protocol (MCP) server connecting ATAS Platform (7.x) and ATAS X (8.x) to AI agents and development assistants.
ATAS MCP Bridge bridges the gap between institutional-grade order flow trading in ATAS and modern AI models. It exposes real-time market data, full order book depth (DOM), delta volume candles, account positions, open orders, trade executions, and automated order routing directly to AI assistants.
Compatible with all major AI coding agents and MCP clients:
OpenCode
Qwen Code
Kiro (CLI & IDE)
Claude Code
OpenAI Codex / Developers Platform
OpenClaw
Kimi Kode
Z Code
Google Antigravity (AGY CLI & IDE)
Cursor
Claude Desktop
Windsurf / VS Code (Cline & Roo Code)
Related MCP server: MetaTrader 5 MCP Server
+------------------------------------+ HTTP / SSE (127.0.0.1:8787) +----------------------+
| ATAS Platform | <------------------------------------------> | MCP Server (Py) |
| "MCP Bridge" | GET /api/* | server.py |
| (ChartStrategy in C# / .NET) | POST /api/order | (mcp 2.0) |
+------------------------------------+ GET /api/stream +----------------------+
^
| MCP (stdio)
v
+----------------------+
| AI Clients |
| - OpenCode |
| - Qwen Code |
| - Kiro |
| - Claude Code |
| - OpenAI Codex |
| - OpenClaw |
| - Kimi Kode |
| - Z Code |
| - Antigravity |
| - Cursor |
| - Claude Desktop |
+----------------------+C# Addon (ATAS.McpBridge): Runs inside the ATAS process as a native ChartStrategy. It hosts an embedded HTTP and Server-Sent Events (SSE) listener on 127.0.0.1:8787.
Thread Safety & Lock-Free Design: All ATAS API calls occur strictly on the main ATAS thread within OnCalculate(). Incoming HTTP execution requests are queued in a thread-safe ConcurrentQueue and processed on the next tick. Read requests are answered immediately from volatile in-memory JSON snapshots without interrupting market data processing.
Python MCP Server (server.py): Speaks Model Context Protocol over standard I/O (stdio), exposing 12 production-ready tools with robust structured error handling.
Python HTTP Client (atas_client.py): Zero-dependency client using Python standard library with automated port discovery and environment variable support.
Tool | Description | Parameters |
| Returns bridge connectivity status, symbol, portfolio account, tick size, activation state, and active port. | None |
| Live quote snapshot: last price, best bid and ask with volumes, DOM cumulative volume (order flow imbalance), spread, and tick size. | None |
| Full order book depth (DOM): sorted bids (highest first) and asks (lowest first) with exact price and size. |
|
| Historical bars (up to 2000 candles) for the chart: open, high, low, close, volume, delta, timestamp, and the current forming candle. | None |
| Current open position details: net volume, average entry price, direction (Buy/Sell), open PnL, and closed PnL. | None |
| Working orders: ID, direction, order type, price, trigger price, executed volume, remaining volume, and order state. | None |
| Execution log (fills) completed during the active session. | None |
| Consolidates status, quote, DOM, candles, orders, position, and trades in a single call. | None |
| Places an order through ATAS. Prices are automatically rounded and snapped to instrument tick size. |
|
| Cancels an open working order by its unique ID. |
|
| Closes (flattens) the current position using an opposing market order for the full or partial volume. |
|
| Retrieves recent diagnostic logs from the C# bridge inside ATAS for debugging. | None |
The C# addon serves the following endpoints locally at http://127.0.0.1:8787:
Endpoint | Method | Description |
| GET | Health check ( |
| GET | Metadata: platform version, instrument, security code, portfolio, and tick size. |
| GET | Live ticker, best bid/ask, and cumulative order book imbalance. |
| GET | Full depth of market book snapshot. |
| GET | Array of completed candles plus current active bar. |
| GET | List of working orders. |
| GET | Calculated net position and session PnL. |
| GET | Session trade executions (fills). |
| GET | All-in-one consolidated payload. |
| GET | Diagnostic log buffer. |
| POST | Submits a new order ( |
| POST | Cancels an existing order ( |
| POST | Flattens the open position ( |
| GET (SSE) | Real-time Server-Sent Events: |
Operating System: Windows 10 / 11 (x64)
Platform: ATAS Platform (7.x) or ATAS X (8.x) installed
.NET SDK: .NET 8 SDK or higher (winget install Microsoft.DotNet.SDK.8 or dotnet --version)
Python: Python 3.10 or higher with pip
git clone https://github.com/Ax3lsk3r3/atas-mcp.git
cd atas-mcp
pip install -r requirements.txtOptionally install as an editable package so the atas-mcp CLI command is globally available:
pip install -e .Run the build script:
build.batThe script compiles the project in Release mode and copies ATAS.McpBridge.dll to both ATAS strategy folders:
%APPDATA%\ATAS\Strategies\ (ATAS Platform 7.x)
%APPDATA%\ATAS X\Strategies\ (ATAS X 8.x)
Launch ATAS (or ATAS X).
Open a chart for the instrument you want to trade (e.g. NQ, ES, BTCUSDT, EURUSD).
Right-click the chart -> select Indicators (or Add Indicator).
Search for MCP Bridge and add it to the chart.
In the strategy properties panel:
Check the IsActivated checkbox.
Select your portfolio / account (simulation or demo accounts recommended).
Verify in your web browser:
Navigate to http://127.0.0.1:8787/api/health
Expected output: {"ok":true,"id":"atas-mcp-bridge","version":"1.0.0"}
Verify the Python client against a local mock bridge without launching ATAS:
python test_client.pyAll 13 automated tests should pass.
The server supports two primary modes:
Mode A: Stdio (for local desktop IDEs and CLIs):
start_mcp.bat
# or directly:
python server.py
# or if installed via pip:
atas-mcpMode B: Server-Sent Events (SSE) (for web applications, remote environments, cloud agents):
start_mcp_sse.bat
# or directly:
python server.py --transport sse --host 127.0.0.1 --port 8000
# or with Docker:
docker compose up -dThe SSE endpoint will be available at http://127.0.0.1:8000/sse for web chat UIs (LibreChat, Open WebUI, AnythingLLM) and remote agent runners (OpenClaw, LangChain, CrewAI, AutoGen).
Detailed setup guides for all supported clients are provided in mcp-config-examples.md.
Add to ~/.config/opencode/config.json or project opencode.json:
{
"mcp": {
"atas": {
"type": "stdio",
"command": "python",
"args": ["<PATH_TO_ATAS_MCP>/server.py"]
}
}
}Run via CLI:
qwen mcp add atas python "<PATH_TO_ATAS_MCP>/server.py"Run via CLI:
kiro mcp add atas python "<PATH_TO_ATAS_MCP>/server.py"Run via CLI:
claude mcp add atas -- python "<PATH_TO_ATAS_MCP>/server.py"Add to %USERPROFILE%\.gemini\config\mcp_config.json:
{
"mcpServers": {
"atas": {
"command": "python",
"args": ["<PATH_TO_ATAS_MCP>/server.py"]
}
}
}Add to %USERPROFILE%\.cursor\mcp.json:
{
"mcpServers": {
"atas": {
"command": "python",
"args": ["<PATH_TO_ATAS_MCP>/server.py"]
}
}
}Add to %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"atas": {
"command": "python",
"args": ["<PATH_TO_ATAS_MCP>\\server.py"],
"cwd": "<PATH_TO_ATAS_MCP>"
}
}
}ATAS 7.x and 8.x Compatibility:
Targets .NET 8, which runs natively on ATAS 7.x and forwards cleanly into ATAS X .NET 10 cross-platform runtime.
Uses IndicatorCandle for full access to volume and delta statistics.
Price rounding respects ShrinkPrice(price) to prevent exchange reject errors.
Full order book depth snapshot extracted via MarketDepthInfo.GetMarketDepthSnapshot().
Position Tracking:
In ChartStrategy, the net open volume and direction are computed from strategy-specific execution fills (MyTrades).
This ensures safe isolation: manual orders outside this strategy do not corrupt the algorithmic tracking of the strategy.
Dynamic Port Discovery:
If port 8787 is occupied, the C# bridge scans ports 8787 through 8807 automatically.
The selected port is stored in %APPDATA%\ATAS\McpBridge.port and %APPDATA%\ATAS X\McpBridge.port.
atas_client.py auto-discovers this file or falls back to the ATAS_MCP_PORT environment variable.
Issue | Likely Cause | Solution |
| .NET 8 SDK is missing or PATH is not refreshed. | Run |
| Strategy is not added to a chart or | Open ATAS, add |
Network Access Denied on port bind | Windows HTTP.sys reservation missing. | Run in an Administrator Command Prompt: |
AI Client cannot find | Incorrect path in client MCP configuration file. | Verify that the path in your client JSON points to the absolute path of |
Orders are rejected | Portfolio is not connected or demo connection inactive. | Verify in ATAS that your connector/broker status is green and select a valid portfolio in the strategy settings. |
This software connects directly to financial trading platforms and can place binding orders on financial markets. Trading futures, equities, forex, and cryptocurrencies involves substantial risk of loss and is not suitable for every investor.
Always test strategies, prompts, and tool calls thoroughly on simulated accounts (DEMO or Market Replay) before deploying capital.
This software is distributed strictly for educational and technical automation purposes, without warranty of any kind.
MIT License. See LICENSE for details.
Recent diagnostic logs from the ATAS bridge running inside ATAS. Useful when troubleshooting strategy activation, tick processing, or order issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 conveys that this is a read-only, diagnostic log view through the word 'logs' and 'recent', but it does not explicitly state that it has no side effects, nor does it mention log ordering, size, or recency limits.
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?
Two sentences with no wasted words. The resource is front-loaded, and the troubleshooting scenarios are stated efficiently. Every part of the description contributes to selecting and invoking the tool correctly.
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?
The description is sufficient for a simple, zero-parameter log fetch, especially since the output schema is available. It could be slightly more complete by defining the recency window or log format, but the core selection and invocation context is present.
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 has zero parameters and full coverage, so there are no parameters to explain. The description adds meaningful context beyond the schema by specifying the source (ATAS bridge) and the diagnostic use cases.
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 exact resource: recent diagnostic logs from the ATAS bridge. It also conveys the tool's role as a log-reading diagnostic, which distinguishes it from all sibling quote, order, and position tools, even though it uses a noun phrase rather than an explicit verb.
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 explicitly states when to use the tool: troubleshooting strategy activation, tick processing, or order issues. It does not name alternatives because no sibling log tool exists, so the absence of exclusion criteria is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a working order by its ID (see atas_orders for working order IDs).
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the action is a cancellation, but does not mention what happens for invalid or already-filled orders, whether the operation is reversible, or any side effects. Some of this may be covered by an output schema, but the description itself gives minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the action and target. It includes the necessary cross-reference to atas_orders without any redundant wording.
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?
For a single-parameter cancellation tool, the description is nearly complete: it defines the purpose, the target resource, and where to find valid IDs. The presence of an output schema reduces the need to describe return values. A small gap remains around edge cases and failure behavior, but overall the essential context is present.
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 only defines order_id as a string with no description (0% coverage), so the description must compensate. It does so meaningfully by explaining that the ID refers to a working order and directing the agent to atas_orders for valid IDs, which adds real semantic value 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 states a specific action ('Cancel'), a specific resource ('working order'), and the method of identification ('by its ID'). It also points to atas_orders for obtaining valid IDs, which distinguishes it from the order-listing sibling.
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 clearly indicates when to use the tool: when a working order needs to be cancelled. It also references atas_orders as the source for order IDs, providing helpful routing guidance. It does not explicitly discuss when not to use it or compare with other mutation tools, but the context is sufficient for this simple operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent candle history for the chart the strategy is attached to (up to 2000 bars): open, high, low, close, volume, delta, and time, plus the current forming candle. Essential for context and technical analysis.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 the burden of behavioral disclosure. It usefully states the 2000-bar limit, that the current forming candle is included, and that the history is tied to the chart the strategy is attached to. This goes beyond a generic 'get candles' statement, though it does not mention any latency, availability, or state assumptions.
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 compact sentence that front-loads the resource scope, states the bar limit, lists all returned fields, and gives a usage rationale. There is no filler or repetition of schema information.
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 are no parametersais, an output schema is present, and the tool is a straightforward read of candle history, the description covers the essential scope, limits, and output fields. Nothing critical is missing for an agent to select and invoke this 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 tool has zero parameters)Skip, so the description is not required to explain argument semantics. The baseline of 4 applies because there is nothing missing; the description focuses instead on the output content.
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 a specific resource (candle history for the attached chart) and lists the exact data fields returned. It is distinct from sibling tools like atas_quote or atas_trades because it focuses on historical OHLCV/delta/time bars rather than a single quote, DOM, or trade stream.
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 phrase 'Essential for context and technical analysis' gives a clear use case, but the description does not explicitly say when to prefer this over alternatives such as atas_snapshot or atas_quote. It implies usage but does not provide exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flatten the current position using a market order. If volume and direction are omitted, the strategy automatically calculates the opposite direction and entire volume to close the position completely.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | No | ||
| direction | 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 carries the behavioral disclosure burden. It reveals that execution uses a market order and that omitting both parameters triggers automatic calculation of opposite direction and full volume. This is meaningful behavior beyond the tool name, though it stops short of describing edge cases or failure conditions.
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?
A single, well-structured sentence delivers the core purpose and the key default behavior with no filler. Important information is front-loaded.
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?
The tool is relatively simple and has an output schema, so return-value documentation is not required. The description covers the normal close-position flow, but it omits exact direction value syntax and the behavior for partial omission, which an agent may need to call the tool correctly in edge cases.
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 provides no descriptions, so the description must compensate. It clarifies that volume and direction are optional and that omitting both closes the entire position automatically. However, it does not specify valid values for direction or what happens when only one parameter is omitted, leaving some ambiguity for the agent.
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 a specific action ('flatten the current position') using a specific method ('market order'). It clearly differentiates this from sibling tools like place_order and cancel_order, so an agent can understand its purpose immediately.
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 gives clear context: use this to close the current position, and when volume and direction are omitted, the strategy auto-calculates the full opposite close. It does not explicitly name alternatives or when-not-to-use, but the purpose is specific enough that the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current market depth (DOM / order book): asks (lowest price first) and bids (highest price first), each level with price and volume. The 'levels' argument limits how many levels are returned per side.
| Name | Required | Description | Default |
|---|---|---|---|
| levels | 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 the burden of behavioral disclosure. It explains the output composition, ordering of asks and bids, and per-side level limiting, which is meaningful for an order book 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?
Two concise sentences deliver the essential purpose and the key parameter behavior with no redundant wording. The main description is front-loaded with the resource and order semantics.
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?
For a straightforward one-parameter read-only tool with an output schema, the description provides enough context for an agent to invoke it correctly. It explains the input semantics and the expected structure of the order book response.
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?
Although schema coverage is 0%, the description clearly explains the only parameter, 'levels', as limiting the number of levels per side. This adds semantic meaning beyond the schema's minimal title and default value.
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 resource as current market depth (DOM / order book) and specifies both sides: asks and bids, along with their ordering. This differentiates it from sibling quote and candle tools even without naming them.
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 use when order book depth is needed and clarifies how the 'levels' argument affects output, but it does not explicitly state when to prefer this tool over atas_quote or atas_snapshot, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All working (active) orders with ID, direction, type, price, trigger price, filled quantity, unfilled quantity, and state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 the full burden of behavioral disclosure. It mentions 'working (active) orders' but does not state whether orders are filtered by symbol or any other implicit constraints, nor does it disclose potential latency or data freshness. It adds no context beyond what the tool name suggests.
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, concise and front-loaded with the core purpose ('All working (active) orders'). It lists fields efficiently without redundancy, but could be more structured for readability.
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 no parameters and an output schema exists (signaled by context), the description is fairly complete for a simple listing tool. However, it lacks details on typical use cases, such as checking order status before placing new orders, and does not clarify the scope (e.g., all markets or current account). This is adequate but not comprehensive.
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 tool has zero parameters, so the schema provides no parameter documentation. The description compensates by listing the fields returned, which is conceptually similar to documenting parameters. This establishes a baseline, as the description adds meaning about the output, which is useful for an agent.
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 tool lists all working (active) orders and enumerates the fields returned (ID, direction, type, price, etc.), which is a specific verb+resource. However, it does not explicitly differentiate from siblings like atas_trades or atas_position, though the focus on 'orders' suggests distinction.
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?
There is no explicit guidance on when to use this tool versus alternatives like atas_trades (for fills) or atas_position (for positions). The description implies it is for active orders, but does not state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an order through ATAS. Parameters: direction ('buy' or 'sell'); order_type ('limit', 'stop', 'market', or 'stoplimit'); qty (number of contracts/lots); price (required for limit and stoplimit); trigger_price (required for stop and stoplimit); comment (optional order label). Prices are automatically snapped to instrument tick size.
| Name | Required | Description | Default |
|---|---|---|---|
| qty | Yes | ||
| price | No | ||
| comment | No | ||
| direction | Yes | ||
| order_type | Yes | ||
| trigger_price | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 one behavioral trait (prices snapped to tick size) but does not state that this submits a live order, may execute, requires a connection, or what side effects or confirmations result.
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?
A single compact paragraph that front-loads the purpose and then lists parameters with their constraints. Every clause adds useful information, with no filler or repetition.
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?
All six parameters are covered and one key behavioral detail is given. The output schema exists, so return-format description is not necessary. It still omits order-lifecycle context such as live submission and execution risk, and does not route the agent to sibling tools, but it is largely sufficient for calling the 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?
Schema description coverage is 0%, and the description compensates thoroughly: it defines direction values, order_type values, qty meaning, conditional price/trigger_price requirements, and comment optionality. This adds meaningful conditional logic beyond the bare 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 opens with a specific verb and resource: 'Place an order through ATAS.' This clearly distinguishes it from sibling tools like atas_cancel_order and atas_orders, and the parameter list reinforces the core action.
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 gives explicit conditional usage rules for parameters (price required for limit/stoplimit, trigger_price required for stop/stoplimit), which helps correct invocation. However, it does not mention when to use this tool versus alternatives or state any exclusions, so tool-selection guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current open position details (volume, average price, direction, realized and unrealized PnL) derived from strategy fills.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully notes that data is derived from strategy fills and reflects current open position, implying a read-like operation info, but it does not mention behavior when no position exists, data freshness, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence front-loads the resource and enumerates the returned fields without filler. Every phrase earns its place.
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?
For a zero-parameter tool with an output schema, the description covers the essential calling contract: what the resource is and where the data comes from. It could add a brief pointer to when to prefer this over atas_snapshot or atas_orders, but nothing critical is missing.
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 zero properties, so there are no parameter semantics to document. The description adds no parameter detail, but none is required; this matches the baseline for a zero-parameter tool.
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 names the specific resource (current open position) and the derived fields returned (volume, average price, direction, realized and unrealized PnL). This clearly distinguishes it from sibling tools like atas_trades, atas_orders, and atas_close_position.
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 given about when to use this tool versus alternatives such as atas_snapshot or atas_orders. The description only says what the tool returns; it does not state exclusions, conditions, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live quote snapshot: last traded price, best bid/ask with sizes, cumulative DOM bid/ask volume (order flow imbalance), spread, and tick size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 the burden of behavioral disclosure. 'Live quote snapshot' clearly signals a read-only, non-mutating operation, and the description lists what data is returned. It does not mention rate limits or connectivity requirements, but for a parameterless snapshot tool these omissions are minor.
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 well-structured sentence with a front-loaded label followed by a concise list of included data fields. Every word adds value and there is no redundant or filler content.
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?
For a simple parameterless tool with an output schema, the description is complete: it names the data categories returned, signals the live/snapshot nature, and requires no parameter guidance. The presence of an output schema covers detailed return structure, so nothing essential is missing.
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 tool has zero parameters, so there are no parameter semantics for the description to clarify. The empty input schema is fully sufficient, and the description does not need to compensate for any undocumented inputs.
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 resource as a live quote snapshot and enumerates its contents: last traded price, best bid/ask with sizes, cumulative DOM volume, spread, and tick size. It is specific and unambiguous, though it does not explicitly contrast itself with sibling tools like atas_dom or atas_snapshot.
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 given on when to use this tool versus alternatives such as atas_dom, atas_candles, or atas_snapshot. It does not state exclusions, prerequisites, or a preferred use case beyond the implied 'get a quote' scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything at once: status, quote, DOM, candles, orders, position, and trades in a single call. Useful for full context on each turn.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It transparently discloses that the tool combines many data areas into one call, which is the main behavioral trait. The name 'snapshot' and the read-only contents (status, quote, DOM, candles, orders, position, trades) make the non-mutating nature reasonably clear.
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?
Two short sentences deliver the full scope and the intended usage without waste. The key idea, 'everything at once,' is front-loaded and immediately understandable.
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?
For a zero-parameter aggregate snapshot with an output schema available, the description is complete. It names what the tool returns, explains why an agent would use it, and needs no additional disambiguation.
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 tool has zero parameters, so there is no parameter information to add. A baseline of 4 is appropriate because parameter semantics are not a concern here.
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 an aggregate retrieval tool: it returns status, quote, DOM, candles, orders, position, and trades in a single call. This directly distinguishes it from the individual sibling tools that cover each area separately.
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 gives a clear usage context: 'Useful for full context on each turn.' It does not explicitly state when NOT to use it or name alternatives, but the implied contrast with the granular sibling tools is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connection status of the ATAS bridge: symbol, portfolio, tick size, whether the strategy is activated, bridge port, and current state. Call this first to verify the bridge is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 is the sole source of behavioral information. It implies a read-only health-check operation and lists returned contents, but it does not explicitly state non-destructiveness or explain behavior when the bridge is unreachable. The output schema covers return values, which softens the gap.
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 two short sentences: the first states what the tool returns, the second provides the key usage instruction. Every word earns its place, and the most important information is front-loaded.
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?
For a zero-parameter status tool with an output schema, the description is nearly complete. It identifies the resource, the returned fields, and the recommended first-call usage. Minor omissions, such as an explicit non-mutating statement or failure-mode description, don't undermine the agent's ability to call it 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 input schema has zero parameters, making schema description coverage trivially 100%. The baseline of 4 applies because no parameter documentation is needed; the description adds no parameter information, which is appropriate here.
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's function as returning the ATAS bridge connection status, enumerates the specific fields (symbol, portfolio, tick size, activation, port, state), and distinguishes it from sibling tools by instructing to call it first. It is specific and meaningful, not a tautology.
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?
'Call this first to verify the bridge is reachable' gives explicit, context-rich guidance for when to use this tool. It does not, however, describe when not to use it or name alternative tools, so it falls just short of full when/when-not/alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent executed trades (fills) of the current session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 bears the full burden of behavioral disclosure. It only states that it returns recent executed trades and does not disclose ordering, limits, whether it includes partial fills, or any session-specific caveats. This is minimal disclosure for a tool that returns a list of records.
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, front-loaded sentence with no filler. It conveys the essential function (recent fills) and context (current session) efficiently. Every word earns its place.
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?
While the tool has no parameters and an output schema exists (which presumably details the return structure), the description leaves out nuances such as whether the list is chronological, if it includes cancelled attempts, or how 'current session' is defined. For a zero-parameter tool, this is adequate but not thorough; a mention of ordering or scope would improve it.
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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because none exist, and the schema already covers everything (100% coverage). No additional semantic information is needed.
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 returns 'Recent executed trades (fills) of the current session.' This specifies the verb (executed trades) and resource (current session). It is distinct enough from siblings like atas_orders (which likely handles order status) and atas_position, though it does not explicitly name alternatives.
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?
There is no guidance on when to use this tool versus others. The description simply states what it returns without mentioning use cases, prerequisites, or exclusions. An agent would not know if it should prefer this over atas_orders for viewing trade history or atas_snapshot for a summary.
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.
v1.0.0atas_bridge_logatas_cancel_orderatas_candlesatas_close_positionatas_domatas_ordersatas_place_orderatas_positionatas_quoteatas_snapshotatas_statusatas_tradesScored across 12 tools
Each tool addresses a single, well-defined aspect: market data (quote, DOM, candles), account state (position, orders, trades), actions (place, cancel, close), and diagnostics (log, status). The aggregate snapshot overlaps by design but is explicitly presented as a convenience for full context. No two tools appear to perform the same function.
All tools share the 'atas_' prefix and use a consistent convention: noun-style names for data retrieval (quote, dom, position) and imperative verb_noun names for mutations (place_order, cancel_order, close_position). This read/write distinction makes the toolset predictable and easy to navigate. Minor variation like 'bridge_log' as a compound noun does not create confusion.
Twelve tools is well within the ideal range for a trading bridge application. Each tool serves a distinct purpose and the set feels neither bloated nor sparse. The inclusion of an aggregate snapshot is justified as a convenience for agents needing full state in one call.
The toolset covers the essential lifecycle: read market data, inspect position/orders/trades, place and cancel orders, and close positions. It lacks a dedicated order modification operation, but agents can cancel and re-place orders as a workaround. Basic connection diagnostics and status are also included, making the surface practical for automated trading.
Trade across 22+ exchanges and brokers from any MCP-capable AI agent, no install required.
Trade 16 crypto exchanges + MetaTrader 5 from your AI assistant via one MCP connection.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
A Model Context Protocol server exposing real-time and historical Colombo Stock Exchange (CSE) data to AI agents and LLM applications. Provides quotes and OHLCV price history, full financial statements (income, balance sheet, cash flow), pre-computed technicals (moving averages, RS ratings, volume signals), macroeconomic indicators, corporate actions, and rule-based screening across CSE stocks and sector indices, everything needed to build CSE-aware trading assistants, research tools, and market-analysis agents.
