Skip to main content
Glama
Sign In
MCP Pionex Management

MCP Pionex Management

by Eurobertics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check spot grid parameters

pionex_bot_check_spot_grid_params
Read-only

Validate spot grid bot parameters and estimate investment without creating an order; errors return min/max investment and slippage for correction.

Instructions

Check spot grid parameters

Validate spot grid bot creation parameters and estimate investment values without creating an order. Weight: 1.

Pass a positive quote_total_investment to receive full estimate fields. The current market price is fetched automatically — open_price is not required.

FailedWithData: For errors marked "Yes" below, the response includes a data field even when result=false, containing min_investment, max_investment, and slippage so the client can display the valid investment range.

Validation error messages (returned in message when result is false):

Message

Cause

Includes data

number invalid: {value}

top or bottom is not a valid numeric string

No

number int too long: {value}

Integer part of top or bottom exceeds 15 digits

No

number decimal too long: {value}

Decimal part of top or bottom exceeds 15 digits

No

invalid quote total investment

quote_total_investment must be >= 0

No

bottom must be less than top

bottom must be strictly less than top

No

row must be between 2 and 1000

row must be in the range [2, 1000]

No

invalid grid_type

grid_type must be arithmetic or geometric

No

grid price duplicated: reduce row or widen range

Grid range too narrow or row too large — adjacent grid prices are identical

Yes

quote_total_investment not match quote precision: max {N} decimal places

quote_total_investment exceeds the allowed decimal precision

Yes

less than min investment

quote_total_investment is "0" or less than min_investment

Yes

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "base": "<base>",
      "quote": "<quote>",
      "buOrderData": "<buOrderData>"
    },
    "name": "pionex_bot_check_spot_grid_params"
  }
}

Input Schema

NameRequiredDescriptionDefault
baseYesBase currency
quoteYesQuote currency
buOrderDataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description is consistent with these. Beyond that it discloses the weight (1), the FailedWithData behavior (a `data` field with min/max investment and slippage even on result=false), automatic market price fetching, and a detailed table of validation error messages and causes.

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-loads the core purpose and key rules before the error table. The validation-error table is long but each row carries distinct, actionable information; minor redundancy between prose and table.

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?

With no output schema, the description carries the return-shape burden and does so for the failure path (data field, min/max investment, slippage). It is largely complete for a validation/estimation tool, though the success-path estimate fields are only summarized.

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

Parameters4/5

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

Schema coverage is 67%, and the description richly compensates: it specifies that quote_total_investment must be positive, that `top`/`bottom` have numeric/k-digit constraints, the row range [2,1000], grid_type enum values, and precision limits. It adds meaning beyond the schema, though the description could more directly tie these constraints to the named parameters.

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+resource+scope: 'Validate spot grid bot creation parameters and estimate investment values without creating an order.' This distinguishes it from the sibling pionex_bot_create_spot_grid_order by making clear it is a non-mutating dry run.

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?

Clearly implies when to use it (pre-flight validation before creating a spot grid bot) and notes it does not create an order. However, it does not explicitly name the alternative sibling (e.g., create_spot_grid_order or check_futures_grid_params) or state when NOT to use this tool.

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