Skip to main content
Glama
Eurobertics

MCP Pionex Management

by Eurobertics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create investment order

pionex_earn_dual_invest
Destructive

Creates a Dual Investment order on Pionex using a product ID, base currency, and one amount field; fetch current profit first because stale values are rejected.

Instructions

Create investment order

Creates a new Dual Investment order. Requires Earn permission. Weight: 1.

Provide either baseAmount (invest in base currency) or currencyAmount (invest in investment currency), not both.

Workflow: Call GET /api/v1/earn/dual/prices first to obtain the current profit value, then pass it unchanged to this endpoint. The profit field must match the live price — a stale or mismatched value will be rejected.

Example request body:

{
  "base": "BTC",
  "productId": "BTC-USDXO-260402-68000-P-USDT",
  "clientDualId": "my-order-001",
  "currencyAmount": "100",
  "profit": "0.0039"
}

Example response:

{
  "result": true,
  "data": {
    "clientDualId": "my-order-001",
    "state": "CONFIRMED"
  },
  "timestamp": 1775027817297
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseYesBase currency
profitNoExpected yield rate. Must match the current price from `/prices`.
productIdNoProduct ID to invest in
baseAmountNoInvestment amount in base currency (e.g. BTC). Mutually exclusive with `currencyAmount`.
clientDualIdNoClient-assigned order ID used as an idempotency key. Recommended to avoid duplicate orders.
currencyAmountNoInvestment amount in investment currency (e.g. USDT). Mutually exclusive with `baseAmount`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true. On top of that the description adds the permission requirement, the stale-profit rejection behavior, the weight, and the clientDualId idempotency recommendation — real operational context beyond the structured hints.

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?

Front-loaded with the action and constraints, with examples placed after the rules. Minor redundancy from repeating the title line, but the workflow callout and JSON examples each earn their space.

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 destructive, open-world order-creation tool with no output schema, the description covers permissions, prerequisites, mutual exclusivity, and even ships an example response showing state CONFIRMED, which compensates for the missing output schema.

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 all six parameters are already documented in the schema, including mutual exclusivity and the profit-matching rule. The description's example request body adds concrete syntax value but mostly restates schema content, so baseline 3 applies.

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?

States a specific verb and resource ('Creates a new Dual Investment order') and names the exact product family. It does not explicitly differentiate itself from sibling earn tools like earn_dual_collect or earn_arbitrage_stake, but the product-specific naming makes it reasonably unambiguous within the earn_dual cluster.

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?

Gives an explicit prerequisite workflow ('Call GET /api/v1/earn/dual/prices first to obtain the current profit value, then pass it unchanged'), states the required 'Earn' permission, and clarifies the mutual exclusivity of baseAmount vs currencyAmount. It does not state when NOT to use this versus other order-creation tools, so it falls short of a 5.

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