Skip to main content
Glama

resume_copy_trade

Destructive

Resume a paused Solana copy trade to reactivate trading. Trades executed during the pause are not replayed.

Instructions

Resume a paused Solana copy trade (isActive=true). No-op if already active. Trades made while paused are not replayed.

Input Schema

NameRequiredDescriptionDefault
apiKeyNoAPI key
userIdNoControl wallet address
accountRefNoConnected account from gdex_connect. Supplies session key, wallet address, API key and session data so no secret is passed in chat
copyTradeIdYesCopy trade ID (from get_copy_trade_list)
sessionPrivateKeyNoSession private key

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv5.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnly=false, destructive=true, openWorld=true). The description adds genuinely useful behavior beyond that: idempotency ('No-op if already active') and the important fact that 'Trades made while paused are not replayed'. It does not explain that resuming re-enables live fund-spending execution, a minor gap given destructiveHint.

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

Conciseness5/5

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

Three tight sentences, each earning its place, with the core action front-loaded. No redundant restatement of the title or name.

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 mutation tool with no output schema, the description covers the key state transition, idempotency, and the non-replay rule, while annotations carry the safety profile. It stops short of noting auth/session prerequisites or the fund-spending implication of resuming, but is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so all five parameters (including copyTradeId and accountRef) are already documented in the schema. The description's mention of isActive=true is a state note rather than parameter guidance, so baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Resume a paused Solana copy trade') and includes the resulting state (isActive=true). The 'Solana' qualifier distinguishes it from the sibling resume_hl_copy_trade (Hyperliquid), so an agent can route correctly without opening the schema.

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

Usage Guidelines3/5

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

Usage is implied by 'Resume a paused ... trade', but the description never states when to prefer this over pause_copy_trade/update_copy_trade or what prerequisite state is required. No explicit when-not or alternative guidance is given, so this is minimum viable.

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

Deploy Server

Other Tools