This server exposes read-only CEXY.io public market data and exchange metadata; no account or trading tools are present in this schema.\n\n- Check exchange status, server time, maintenance, API limits, and MCP server configuration.\n- List, filter, and search spot markets with compact tickers.\n- Get full trading rules and 24h ticker for one market.\n- Get a 24h ticker, order-book snapshot, or recent public trades for a market.\n- Fetch OHLCV candles with configurable interval and time window.\n- List assets and network details, including deposit/withdrawal status, maintenance, minimums, and fees.\n- Get the maker/taker fee schedule by 30-day volume tier.
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., "@@cexyio/mcp what's the BTC/USDT price and 24h volume right now?"
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.
The official Model Context Protocol server for the CEXY.io exchange. It lets an AI assistant (Claude Code, Claude Desktop, or any MCP client) read market data and, with your API key, your balances, orders and history.
Read-only by default. Trading tools do not exist unless you turn them on.
It never moves funds. There are no withdrawal, transfer or deposit-address tools, and CEXY API keys cannot withdraw anyway.
Runs locally over stdio. It opens no network port.
Built on the official TypeScript SDK, @cexyio/cexy.
Status: 0.x prerelease. Tool names and outputs may still change. Pre-release:
npx -y @cexyio/mcp@next;latestcurrently points at a pre-release until 1.0.
It needs Node.js 22 or newer. Nothing to install globally: MCP clients start it with npx.
Public market data only (no key):
claude mcp add cexy -- npx -y @cexyio/mcpWith your account (read-only key):
claude mcp add cexy \
-e CEXY_API_KEY=ak_your_key_here \
-e CEXY_API_SECRET=your_secret_here \
-- npx -y @cexyio/mcpWith trading enabled and guardrails (see Safety first):
claude mcp add cexy \
-e CEXY_API_KEY=ak_your_key_here \
-e CEXY_API_SECRET=your_secret_here \
-e CEXY_MCP_ENABLE_TRADING=true \
-e CEXY_MCP_MAX_ORDER_NOTIONAL=100 \
-e CEXY_MCP_ALLOWED_MARKETS=BTC/USDT,ETH/USDT \
-- npx -y @cexyio/mcpAdd this to claude_desktop_config.json (Settings, Developer, Edit Config) and restart Claude Desktop:
{
"mcpServers": {
"cexy": {
"command": "npx",
"args": ["-y", "@cexyio/mcp"],
"env": {
"CEXY_API_KEY": "ak_your_key_here",
"CEXY_API_SECRET": "your_secret_here"
}
}
}
}Leave out the env block for public data only. Add "CEXY_MCP_ENABLE_TRADING": "true" (and the
guardrails) only if you want the assistant to place orders.
Run npx -y @cexyio/mcp as a stdio server and pass the configuration as environment variables.
Related MCP server: Trading MCP Server
Variable | Default | Meaning |
| unset | API key id ( |
| unset | API key secret. Optional; must be set together with the key. It is used only to sign requests locally and is never sent. |
|
| API base URL. Must be |
| unset |
|
|
| Exactly |
| unset | Per-order cap, in the market's quote currency (e.g. |
| unset (all) | Comma-separated markets |
|
|
|
The server refuses to start when only one of the key and the secret is set, when the base URL
is not https:// (outside the loopback exception above), or when CEXY_MCP_ENABLE_TRADING has an
unrecognised value such as tru. It never echoes
either of them in tool output, errors or logs.
Every read tool is annotated readOnlyHint: true and openWorldHint: true. The trading tools
are annotated destructiveHint: true.
Public (always available, no key):
Tool | What it returns |
| Server time and clock skew, maintenance state, page sizes, candle intervals, and this server's own settings |
| Markets with a compact ticker; filters |
| One market's trading rules (tick/lot size, minimums, order types) and 24h ticker |
| Compact 24h ticker for one market |
| Order-book snapshot, |
| Recent public trades; |
| OHLCV rows; |
| Assets and, per network, deposit/withdrawal status, maintenance, minimums and fees |
| Maker/taker fee tiers |
Read key (registered only when CEXY_API_KEY and CEXY_API_SECRET are set; the key needs the read scope):
Tool | What it returns |
| Balances per asset (with |
| Balances of one of your sub-accounts, by |
| Your open orders; optional |
| One order, by |
| Your orders, paged with |
| Your fills, paged |
| Your deposit history, paged (read only) |
| Your withdrawal history, paged (read only) |
| Every balance change, paged |
Trade (registered only when CEXY_MCP_ENABLE_TRADING=true and a key is set; the key needs the trade scope):
Tool | What it does |
| Places a real order. Always sends a |
| Cancels one order, by |
| Cancels up to 20 orders in one request, each by |
| Cancels your open orders in one market. |
Never available: withdrawals, transfers (including sub-account transfers), any other sub-account action (reading a sub-account's balances is the only one), liquidity-pool join/exit, deposit-address lookup (the API creates an address on first use), API-key management, login/2FA, exports and any admin function. A test asserts that none of these ever appear.
Results are compact JSON (structuredContent), plus a text block with a one-line summary followed
by the same JSON, for clients that read only text. Amounts are decimal strings (never floats) and
timestamps are ISO 8601. Lists default to 10-50 items; paged tools return next_cursor (or
next_offset) to fetch more. No result is larger than about 20 KB: longer lists are trimmed and
marked truncated: true with a note.
Errors come back as MCP tool errors with a structured body:
{ "error": { "code": "FORBIDDEN", "message": "...", "retryable": false, "request_id": "..." } }code is the API error code (e.g. INSUFFICIENT_FUNDS, RATE_LIMITED), or one of this server's:
GUARDRAIL_REJECTED, INVALID_INPUT, TIMEOUT, CONNECTION_ERROR, ORDER_STATE_UNKNOWN,
INTERNAL_ERROR. Quote the request_id when you contact support.
Read-only by default. Without CEXY_MCP_ENABLE_TRADING=true the trading tools are not
registered at all, so the assistant cannot see or call them.
Use a read-only key unless you want trading. Create the key with only the read scope and
restrict it to your IP address with allowed_ips.
Trading is opt-in, with caps. If you enable it, also set CEXY_MCP_MAX_ORDER_NOTIONAL and
CEXY_MCP_ALLOWED_MARKETS. With a notional cap set, place_order refuses any order whose value
it cannot bound: limit buys use price x quantity, limit sells use the higher of the price and the
best bid, market buys are priced by walking the current asks (or use quote_quantity, a budget
that includes the taker fee), market sells use the best bid, and stop orders whose fill price depends on a future book are refused.
The check is made against the book at the time of the call; fast markets can move.
Orders are real and irreversible once filled. Ask your assistant to confirm each order with you; most MCP clients also ask for approval before calling a tool marked destructive.
No withdrawal tools exist, and CEXY API keys cannot withdraw or transfer funds anyway.
The server runs locally over stdio, opens no port and sends no telemetry.
The exchange allows about 120 requests per minute per IP without a key, and about 600 per minute
per API key. The SDK underneath throttles itself below that (100/min without a key, 300/min with
one) and adapts to the server's X-RateLimit-* headers. Most tools make one request;
get_server_status and list_assets make two, and place_order with a notional cap may read the
order book first. A RATE_LIMITED error includes retry_after_ms.
npm install
npm run lint && npm run typecheck && npm test
npm run build # dist/cli.js (the bin) and dist/index.js
npm run test:live # opt-in: a few unauthenticated GETs to api.cexy.ioThe server depends on the published SDK, pinned to an exact version (@cexyio/cexy 0.1.0-dev.19).
See SECURITY.md. Never paste real API keys or secrets into issues.
MIT, see LICENSE.
OHLCV candles for one market, returned as rows of [open_time, open, high, low, close, volume]. Use from/to (ISO 8601) to pick a window; the count is capped at 200.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Window end, ISO 8601 | |
| from | No | Window start, ISO 8601 | |
| limit | No | Items to return (1-200, default 50) | |
| symbol | Yes | Market symbol as BASE/QUOTE, e.g. BTC/USDT | |
| interval | Yes | Candle interval |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the exact return row format ([open_time, open, high, low, close, volume]) and the 200-count cap. It does not cover auth, rate limits, or pagination, but it is a meaningful addition.
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 compact sentences with zero waste. The return format and window guidance are front-loaded, and every clause 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 simple read-only OHLCV tool with 100% schema coverage and annotations covering safety, the description is complete enough. It explains the output row shape (critical since no output schema exists) and the count cap, so an agent has everything needed 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?
Schema description coverage is 100%, so the schema already documents all five parameters in detail. The description mentions from/to and the 200 cap, but adds no syntax, format, or constraints beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 a specific verb+resource ('OHLCV candles for one market') and the exact row shape, making it clear this tool returns candle data rather than trades, ticker, or orderbook. However, it does not explicitly name or distinguish against any sibling tool, so it falls short of the top score.
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 parameter-level guidance ('Use from/to (ISO 8601) to pick a window; the count is capped at 200'), but offers no guidance on when to choose this tool over siblings like get_recent_trades or get_ticker. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The trading fee schedule: maker and taker rates (percent) by 30-day USD volume tier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds useful content detail (maker/taker, percent, 30-day volume tiers) but does not state whether results are public/global or personalized to the caller, nor how often the schedule changes.
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 front-loaded sentence that names the resource first and then enumerates the returned fields. No filler, no repetition of the title or annotations.
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?
With no parameters, no output schema and annotations covering the safety profile, the description's job is to convey what comes back, which it does. It could be marginally stronger by noting that the schedule is a global reference rather than account-specific.
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 takes zero parameters, so per the rubric the baseline is 4. The description correctly implies no filtering input is required to obtain the full schedule.
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?
Names a specific resource (the trading fee schedule) and its exact contents: maker/taker rates in percent, keyed by 30-day USD volume tier. It is readily distinguished from siblings like get_ticker, get_orderbook and get_candles. The only shortfall is the absence of an explicit verb (get/list), which the title partially supplies.
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?
Usage is only implied: the resource itself makes clear this is the lookup for the exchange's fee tiers, and no overlapping sibling offers the same data. There is no explicit when-to-use statement, no mention of prerequisites, and no guidance on whether the schedule is account-specific or global.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details of one market: trading rules (tick size, lot size, min/max quantity, min notional, decimals, supported order types and time-in-force) and its 24h ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Market symbol as BASE/QUOTE, e.g. BTC/USDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the useful fact that the response mixes static trading rules with a dynamic 24h ticker, but says nothing about error behavior when a symbol is unknown or about rate 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?
One front-loaded sentence with no filler; the parenthetical field list is dense but each item earns its place by previewing the return payload. Slightly list-heavy for a single-sentence 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?
With no output schema, the description carries the burden of describing returns and does so by enumerating the rule fields plus the ticker. For a single-parameter read-only tool whose annotations cover safety, this is close to complete, missing only failure behavior.
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 100%: the single symbol parameter is documented with its BASE/QUOTE format and a validating pattern. The description adds no syntax or semantics beyond that, so baseline 3 applies.
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?
States a specific verb+resource ('Full details of one market') and enumerates exactly what those details are, which separates it from the plural list_markets. However, it never names or contrasts any sibling, and its inclusion of the 24h ticker overlaps with get_ticker without acknowledging the overlap.
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 when-to-use statement, no prerequisites, and no routing to alternatives. The overlap with get_ticker (which also returns ticker data) is left unresolved, so an agent gets no help deciding between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order-book snapshot for one market, aggregated by price: bids and asks as [price, quantity] pairs, best first.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Price levels per side (1-50, default 10) | |
| symbol | Yes | Market symbol as BASE/QUOTE, e.g. BTC/USDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is a point-in-time snapshot (not a stream), prices are aggregated by level, and results are ordered best-first, which matters for interpretation with no output schema present.
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 dense sentence with zero filler; the resource and its scope are front-loaded and the return shape follows immediately. Every clause 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 read-only market-data tool with full schema coverage and annotation-declared safety, the description supplies the one thing structured fields lack: the shape and ordering of the returned book. Minor gaps remain around error behavior for unknown symbols, but nothing an agent needs to call it correctly 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?
Schema coverage is 100%, including the depth range/default and the BASE/QUOTE pattern with an example, so the schema does the heavy lifting. The description adds nothing about depth semantics (e.g., that depth truncates rather than paginates) or symbol case handling, so it stays at the baseline.
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?
States a specific verb+resource (order-book snapshot for one market) and precisely characterizes the payload: aggregated by price, bids and asks as [price, quantity] pairs, best first. This clearly separates it from get_recent_trades and get_candles, though it never names a sibling explicitly.
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 when-to-use or when-not-to-use guidance and no mention of alternatives such as get_ticker or get_candles for price views. The only usage signal is the implicit 'for one market', which the required symbol parameter already conveys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent public trades in one market (price, quantity, taker side, time), newest first by default.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items to return (1-50, default 20) | |
| cursor | No | next_cursor from a previous page | |
| symbol | Yes | Market symbol as BASE/QUOTE, e.g. BTC/USDT | |
| direction | No | Sort order (default: newest first) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds two useful behavioral facts: the data is public (no auth implied) and results are ordered newest-first by default, but it says nothing about rate limits, page size behavior, or cursor lifetime.
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 with the resource front-loaded, followed by a parenthetical field list and the default ordering. Every clause earns its place and there is no filler.
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 4-parameter read-only tool with no output schema, the description usefully enumerates the returned fields and states the default sort, which compensates for the missing return-value documentation. Pagination semantics are left entirely to the cursor field's schema description, which is the only minor gap.
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 100%, so all four parameters (limit, cursor, symbol, direction) are already documented in the schema. The phrase 'newest first by default' reinforces the direction default but adds no format or usage detail beyond what the schema provides; baseline 3 applies.
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?
States a specific verb and resource ('Recent public trades in one market') and enumerates the returned fields (price, quantity, taker side, time), which distinguishes it from get_candles/get_orderbook/get_ticker by content. It stops short of explicitly naming a sibling or contrasting scope, so it is clear but not maximally differentiated.
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 when-to-use guidance, no exclusions, and no mention of the obvious alternative (get_candles for aggregated OHLCV). The only implicit signal is 'newest first by default', which hints at the direction parameter rather than at tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CEXY.io server time, maintenance state, API limits (page sizes, candle intervals) and this MCP server's own configuration (authenticated or not, trading enabled or not, guardrails). Call this first when unsure what is available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly/idempotent/non-destructive, and the description adds real value beyond them by disclosing the categories of status returned (auth state, trading enabled, guardrails) and that it acts as a capability-discovery entry point. It does not cover failure modes (e.g., behavior when the exchange is down), which keeps it short of a 5.
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 dense sentence listing what is returned, followed by a one-clause directive on when to call it. Front-loaded with the resource and free of filler; the enumerated items all earn their 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?
With no parameters, no output schema, and annotations covering the safety profile, the description carries the remaining burden by enumerating what a caller learns from the response. An agent can decide whether to call this first without any further 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?
The tool takes zero parameters, so the baseline is 4 and there are no semantics the description could add or omit. Nothing in the description misrepresents the parameter surface.
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?
States a specific resource enumeration: server time, maintenance state, API limits (page sizes, candle intervals), and this MCP server's own auth/trading/guardrail configuration. This is clearly distinguishable from market-data siblings like get_ticker or get_candles, which return market data rather than environment/bootstrap metadata.
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?
Gives an explicit positive trigger: 'Call this first when unsure what is available,' which is strong routing guidance for a discovery tool. It does not name exclusions or alternatives, but for a zero-param bootstrap tool there is little ambiguity to resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compact 24h ticker for one market: last price, best bid/ask, 24h change, high, low and volume.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Market symbol as BASE/QUOTE, e.g. BTC/USDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is fully covered. The description's only added behavioral signal is 'Compact', hinting at response size, plus the field list; it says nothing about rate limits, error behavior for unknown symbols, or staleness of the 24h window.
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?
One sentence, front-loaded with the resource and scope, followed immediately by the returned fields. Every clause carries information; nothing is padding.
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?
With no output schema, enumerating the returned fields is exactly the compensation needed, and it is done. The remaining gap is minor: nothing about invalid-symbol handling or how the 24h window is computed, but for a simple read-only snapshot tool this is close to sufficient.
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 coverage is 100%: the single 'symbol' parameter is documented with a BASE/QUOTE pattern and a BTC/USDT example. The description's 'for one market' merely restates the single-argument scope, adding no syntax or format detail beyond the schema, so the baseline of 3 applies.
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?
States a specific verb+resource ('ticker for one market') and enumerates the payload (last price, bid/ask, 24h change, high, low, volume), which separates it from get_orderbook (depth), get_candles (history) and get_recent_trades (prints). It never names a sibling, so differentiation is inferable rather than explicit.
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?
Usage is implied by the content list: an agent can infer this is the quick 24h snapshot call for a single market. There is no explicit when-to-use statement, no exclusion, and no pointer to alternatives such as get_orderbook for full depth or get_market for static metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assets listed on CEXY.io with, for each network, whether deposits and withdrawals are enabled, whether deposit detection is operational, any maintenance, minimums and the withdrawal fee.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | Only this asset, e.g. USDT | |
| limit | No | Items to return (1-50, default 30) | |
| offset | No | Assets to skip (for paging) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description earns credit for disclosing the payload shape (deposit/withdrawal enablement, deposit detection status, maintenance windows, minimums, withdrawal fee) in the absence of an output schema. It stops short of noting pagination or staleness characteristics.
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 sentence that front-loads the resource ('Assets listed on CEXY.io') before the attribute list. The trailing enumeration gets slightly list-heavy, but nothing is wasted.
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 three-optional-parameter read tool with no output schema, the description carries the return-value explanation well, which is the main gap it needs to fill. It lacks only minor operational detail such as caching or refresh cadence.
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 100%: the asset pattern, limit range/default and offset paging semantics are all documented in the schema itself. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
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?
Names a specific resource (assets listed on CEXY.io) and enumerates the per-network attributes returned, so an agent knows exactly what this tool produces. It does not distinguish itself from siblings like list_markets or get_market, but the resource noun is distinct enough to separate them in practice.
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 when-to-use guidance and no mention of alternatives, despite the sibling set containing market/instrument tools an agent might confuse this with. The only implicit signal is that it is a listing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists CEXY.io spot markets with a compact ticker (last price, 24h change, 24h quote volume, best bid/ask). Filter by quote asset, status or search text; page with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Items to return (1-50, default 20) | |
| quote | No | Only markets quoted in this asset, e.g. USDT | |
| offset | No | Markets to skip (for paging) | |
| search | No | Case-insensitive text matched against the symbol | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond them: the exact ticker fields returned per market (last, 24h change, 24h quote volume, best bid/ask), which matters because there is no output schema. It does not disclose ordering, rate limits, or how paging interacts with filtering.
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 tight sentences: the first front-loads what is listed and what each row contains, the second covers filtering and paging. No filler, no redundancy.
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?
With no output schema, the description adequately compensates by naming the returned ticker fields, and annotations cover the safety profile. Minor gaps remain around result ordering, the meaning of status values, and how many markets exist overall, but nothing blocks a correct call.
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 coverage is 80%, so the schema already documents limit, quote, offset and search precisely; the description adds only a grouped restatement ("filter by quote asset, status or search text; page with offset"). It never mentions the limit parameter, its default, or the status enum values, so it adds little 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?
States a specific verb and resource ("Lists CEXY.io spot markets") and even summarizes the payload it returns (last price, 24h change, volume, best bid/ask). It separates itself from data-fetching siblings like get_ticker/get_orderbook by framing itself as a market-list, but never explicitly contrasts with the singular get_market, leaving that distinction to the name.
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?
"Filter by quote asset, status or search text; page with offset" tells the agent how the filters combine, which implies when to reach for this tool (browse/filter markets). It gives no explicit when-not guidance, no alternative tool named, and no note on default ordering or whether filtering is server-side, so usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0-dev.9get_candlesget_feesget_marketget_orderbookget_recent_tradesget_server_statusget_tickerlist_assetslist_marketsScored across 9 tools
Each tool targets a distinct data type (trades, ticker, orderbook, server status, market list, market details, candles, assets, fees). The only overlap is that get_market and list_markets include ticker data, but descriptions clearly differentiate scope, so an agent can reliably choose the right tool.
All tools follow a consistent snake_case verb_noun pattern: get_* for single-resource data and list_* for collections. There are no naming deviations or mixed conventions.
Nine tools is well-scoped for a market data server, covering all major public data types without bloat. Each tool has a clear, non-redundant role.
The surface covers markets, assets, ticker, orderbook, recent trades, candles, fees, and server status, which is comprehensive for public market data. However, notable gaps exist: get_candles lacks an interval parameter (despite server status mentioning candle intervals), there is no single-asset lookup, and no historical trades beyond the most recent.
Read-only access to your own crypto portfolio across 11+ exchanges and 20+ chains: holdings, full history, FIFO cost basis and P&L, fees and income. Ask Claude or ChatGPT about your portfolio; the connector can never trade, move funds or act as a login.
Trade 16 crypto exchanges + MetaTrader 5 from your AI assistant via one MCP connection.
OpenFinance gives any AI agent easy trading across every major market through one hosted MCP server. Trade crypto spot and perpetuals on Hyperliquid with market, limit and TWAP orders, leverage and margin control. Trade stocks, indices, commodities, forex and pre-IPO names as Hyperliquid HIP-3 perps. Trade Polymarket prediction markets with odds, order books, positions, PnL and trader leaderboards. Swap and bridge across 40+ EVM chains and Solana with Relay and Jupiter, find memecoins across 200+ chains, launch tokens on Robinhood Chain and Solana, and buy crypto with card, bank or UPI. Write actions are designed to ask for your confirmation first. Connect with OAuth (sign in to OpenFinance and approve) or an API key. Works with Claude, ChatGPT, Cursor, VS Code, Codex and any MCP client. No install. Home: https://openfinance.tech/agents · Docs: https://docs.openfinance.tech · GitHub: https://github.com/openfinance-tech/mcp
Live crypto + IDX stock market intelligence for AI agents — 19 tools, no API key.
