Skip to main content
Glama

csid_copy_trading

Read-only
Copy trading on YOUR CabalSpy ID instance. Copy trading turns every trade of a
trader in a user's Trade Feed into a ready-to-execute instruction: token,
chain, side, the amount in USD (buys) or the share of the copied position to
sell (sells), and a price limit. Your platform executes it with the user's own
wallet and reports it back as executed, failed or skipped. CabalSpy never
holds keys and never trades. Instructions are meant to be executed within
120 seconds; a pending one past that reads as 'expired'.

view=instructions (default): the latest instructions of your platform, or of
one user (external_id or csid_id), optionally by status. Each: id, status,
created_at, user, trader, side, token, chain, mint, amount_usd or
sell_percent, price_usd and the max/min price limit, plus what your platform
reported (executed_amount_usd, tx_signature, note). Use for "Which copy
trades failed today?".
view=settings: one user's copy settings per trader (enabled, mode fixed_usd or
percent, amount_usd, percent, max_usd cap, sides buys or both, slippage_bps,
and managed_by_other_platform when another platform copies that trader).

Part of every CabalSpy ID instance (no extra needed); users need the
'trade_feed' consent (otherwise consent_required). Read-only: changing
settings and reporting status stays in the Data API. Needs your own CabalSpy
API key with a CabalSpy ID instance (no demo).

Input Schema

NameRequiredDescriptionDefault
viewNo'instructions' (default): the copy instructions sent to your platform, newest first. 'settings': one user's copy settings per trader in their Trade Feed (needs external_id or csid_id).instructions
limitNoHow many instructions (1-50, default 10).
cursorNoPagination cursor taken from the previous response. Leave empty for the first page.
statusNoview=instructions only: pending, executed, failed, skipped or expired. Leave empty for all.
csid_idNoOnly this user: their CabalSpy ID user id (UUID). Pass external_id or csid_id, not both; required for view=settings.
instanceNoYour CabalSpy ID instance (its client_id, e.g. 'csid_1a2b…'). Only needed when your account has several instances. Leave empty otherwise.
external_idNoOnly this user: their id on YOUR platform (external_id). Pass external_id or csid_id, not both; required for view=settings.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the 120-second execution window and that a pending instruction past it reads as 'expired', that CabalSpy never holds keys or trades, the consent_required failure mode, and the API-key/instance requirement. This is rich context annotations alone would not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The two view= blocks are well-structured and front-loaded with the concept, and each sentence carries operational meaning. It is somewhat long, and it enumerates return fields that the output schema already covers, which is minor waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, dual-mode tool with 100% schema coverage and an output schema, the description supplies the missing operational context: expiry semantics, consent gating, and instance/API-key prerequisites. Nothing an agent needs in order 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all seven parameters, including the view enum values and status options; the baseline is 3. The description adds mode intent (which view to pick for which question) but no syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete verb+resource ('Copy trading on YOUR CabalSpy ID instance') and clearly splits the tool into two modes, view=instructions and view=settings, each described in its own paragraph. It falls just short of 5 because differentiation from sibling tools is not addressed, though no sibling covers this resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a concrete triggering question ('Which copy trades failed today?') and states the dependency of view=settings on external_id/csid_id. It also names a precondition (users need the 'trade_feed' consent, otherwise consent_required). It stops short of explicitly saying when NOT to use it or naming an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources