The MCP Paradex Server acts as a bridge between AI assistants (like Claude) and the Paradex perpetual futures trading platform, enabling AI-driven trading and analysis. With this server, you can:
Retrieve Market Data: Access price, volume, 24h change, funding rates, BBO, orderbooks, candlestick data (klines), and recent trades
Manage Trading Accounts: Track and manage accounts, vaults, balances, positions, trade fills, and funding payments
Place and Manage Orders: Create, cancel, and monitor trading orders with various order types
Monitor System State: Check system health, operational status, and maintenance schedules
Perform Advanced Analysis: Access historical data and conduct trading/risk analysis
Integration with AI Assistants: Seamlessly integrate with AI platforms like Claude via Smithery.ai
Access Documentation: Retrieve Paradex documentation as needed
Integrates with the Ethereum blockchain through the Paradex perpetual futures trading platform, requiring Ethereum private keys for authentication and trading functionality
Click on "Install 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., "@MCP Paradex Server show me the current orderbook for ETH-PERP"
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.
Up to date supported version can be found here https://github.com/tradeparadex/mcp-paradex-py
Model Context Protocol (MCP) server implementation for the Paradex trading platform.
This project provides a bridge between AI assistants (like Claude) and the Paradex perpetual futures trading platform. Using the MCP standard, AI assistants can:
Retrieve market data from Paradex
Manage trading accounts and vaults
Place and manage orders
Monitor positions and balance
Related MCP server: MCP Paradex Server
Python 3.10+
Click to automatically configure this MCP server in Cursor:
claude mcp add paradex uvx mcp-paradexnpx -y @smithery/cli install @sv/mcp-paradex-py --client claudepip install mcp-paradexuvx mcp-paradexClone the repository:
git clone https://github.com/sv/mcp-paradex-py.git
cd mcp-paradex-pyInstall development dependencies:
uv sync --dev --all-extrasRun locally:
uv run mcp-paradexSet these environment variables for authentication:
PARADEX_ENVIRONMENT: Set to prod, testnet, or nightly (default: prod)
PARADEX_ACCOUNT_PRIVATE_KEY: Your Paradex account private key
cp .env.template .env
# Edit .env with your credentialsAdd to your claude_desktop_config.json:
{
"mcpServers": {
"paradex": {
"command": "uvx",
"args": ["mcp-paradex"],
"env": {
"PARADEX_ENVIRONMENT": "testnet",
"PARADEX_ACCOUNT_PRIVATE_KEY": "your_private_key"
}
}
}
}# Build image
docker build . -t sv/mcp-paradex-py
# Run (public only)
docker run --rm -i sv/mcp-paradex-py
# Run with trading capabilities
docker run --rm -e PARADEX_ACCOUNT_PRIVATE_KEY=your_key -i sv/mcp-paradex-pyUse Dockerfile.aws for remote deployments via AWS Lambda with the
Lambda Web Adapter.
The adapter bridges Lambda invocations to the server's HTTP endpoint,
so no Lambda-specific code is needed.
# Build
docker build -f Dockerfile.aws -t sv/mcp-paradex-py-aws .
# Test locally (mirrors Lambda config)
docker run --rm -p 8080:8080 \
-e MCP_TRANSPORT=streamable-http \
-e MCP_STATELESS=true \
-e MCP_PORT=8080 \
-e PARADEX_ENVIRONMENT=prod \
sv/mcp-paradex-py-awsThe server will be available at http://localhost:8080/mcp.
Deploying to Lambda:
Push the image to ECR
Create a Lambda function from the container image
Set the Lambda Function URL invoke mode to RESPONSE_STREAM
Set environment variables on the Lambda function:
MCP_TRANSPORT=streamable-http
MCP_STATELESS=true
PARADEX_ENVIRONMENT=prod (or testnet)
PARADEX_ACCOUNT_PRIVATE_KEY=your_key (optional, for trading)
paradex://system/config - Get Paradex system configuration
paradex://system/time - Get current system time
paradex://system/state - Get system operational state
paradex://markets - List of available markets
paradex://market/summary/{market_id} - Detailed market information
paradex://vaults - List all vaults
paradex://vaults/config - Global vault configuration
paradex://vaults/balance/{vault_id} - Vault balance
paradex://vaults/summary/{vault_id} - Comprehensive vault summary
paradex://vaults/transfers/{vault_id} - Deposit/withdrawal history
paradex://vaults/positions/{vault_id} - Current trading positions
paradex://vaults/account-summary/{vault_id} - Trading account information
paradex_system_config - Get global system configuration
paradex_system_state - Get current system state
paradex_markets - Get detailed market information
paradex_market_summaries - Get market summaries with metrics
paradex_funding_data - Get historical funding rate data
paradex_orderbook - Get current orderbook with customizable depth
paradex_klines - Get historical candlestick data
paradex_trades - Get recent trades
paradex_bbo - Get best bid and offer
paradex_account_summary - Get account summary
paradex_account_positions - Get current positions
paradex_account_fills - Get trade fills
paradex_account_funding_payments - Get funding payments
paradex_account_transactions - Get transaction history
paradex_open_orders - Get all open orders
paradex_create_order - Create new order
paradex_cancel_orders - Cancel existing orders
paradex_order_status - Get order status
paradex_orders_history - Get historical orders
paradex_vaults - Get detailed vault information
paradex_vaults_config - Get global vault configuration
paradex_vault_balance - Get vault balance
paradex_vault_summary - Get comprehensive vault summary
paradex_vault_transfers - Get deposit/withdrawal history
paradex_vault_positions - Get current vault positions
paradex_vault_account_summary - Get vault trading account info
market_overview - Comprehensive crypto market overview
market_analysis - Detailed technical and microstructure analysis
position_management - Comprehensive position analysis
create_optimal_order - Design optimal order parameters
hedging_strategy - Develop effective hedging strategies
portfolio_risk_assessment - Thorough portfolio risk analysis
liquidation_protection - Identify and mitigate liquidation risks
vault_analysis - Comprehensive vault analysis for investment decisions
funding_rate_opportunity - Identify funding rate arbitrage opportunities
trading_consultation - Interactive trading advice and consultation
Enhanced results with Paradex documentation access:
"paradex-docs-mcp": {
"command": "uvx",
"args": [
"--from",
"mcpdoc",
"mcpdoc",
"--urls",
"Paradex:https://docs.paradex.trade/llms.txt",
"--transport",
"stdio"
]
}Please see CONTRIBUTING.md for information on how to contribute to this project, development setup, and our coding standards.
Get the current best available prices for immediate execution decisions.
Use this tool when you need to:
- Make quick trading decisions without full orderbook depth
- Calculate current spread costs before placing orders
- Monitor real-time price changes efficiently
- Get a snapshot of current market conditions
- Determine fair mid-price for calculations
The BBO provides the most essential price information with minimal data,
perfect for quick decisions or when full orderbook depth isn't needed.
Example use cases:
- Calculating current trading spreads before placing orders
- Monitoring real-time price movements efficiently
- Determining execution prices for immediate market orders
- Calculating mid-price for order placement strategies
- Setting appropriate limit order prices to improve fill chances
| Name | Required | Description | Default |
|---|---|---|---|
| market_id | Yes | Market symbol to get BBO for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that the tool provides minimal data for quick decisions, which is consistent and provides additional context beyond the annotation.
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?
The description is well-structured with bullet points and examples, and front-loaded with the main purpose. However, it is slightly verbose with some repetition (e.g., the first sentence is restated later).
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?
Given the tool's simplicity (1 param, read-only, no output schema), the description covers purpose, usage, examples, and context completely. No gaps remain for an agent to understand when and how to use it.
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?
Input schema has 100% coverage with a single parameter 'market_id' already described as 'Market symbol to get BBO for.' The description does not add further semantic meaning beyond the schema, so baseline score of 3 is appropriate.
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 clearly states the tool gets the best available prices for immediate execution decisions. It distinguishes itself from sibling tools like paradex_orderbook (full depth) and paradex_market_summaries by emphasizing minimal data for quick decisions.
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 explicitly lists when to use (quick trading decisions, calculate spread costs, etc.) and provides example use cases. It implies when not to use by stating 'when full orderbook depth isn't needed' but does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed schema information to build precise data filters.
Use this tool when you need to:
- Understand exactly what fields are available for filtering
- Learn the data types and formats for specific fields
- Build complex JMESPath queries with correct syntax
- Create sophisticated filtering and sorting expressions
Knowing the exact schema helps you construct precise filters that
return exactly the data you need, avoiding trial and error.
Example use cases:
- Learning what fields exist in market data responses
- Finding the correct property names for filtering
- Understanding data types for numerical comparisons
- Building complex multi-criteria filters for large datasets
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | The name of the tool to get the filters for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's behavioral addition is limited to stating it returns schema information. No contradictions noted, but the description does not add significant behavioral context beyond what annotations provide.
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?
The description is concise, front-loads the primary purpose, and uses bullet points for clarity. Every sentence serves a purpose without 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?
The description covers the tool's purpose and use cases well. It lacks explicit detail about the output format (no output schema provided), but given the tool's meta-nature, the gap is minor.
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 input schema has 100% description coverage for its single parameter (tool_name). The description does not add extra meaning beyond the schema, so the baseline score of 3 is appropriate.
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 clearly states it provides detailed schema information for building precise data filters. It lists specific use cases and distinguishes itself from sibling data retrieval tools like paradex_bbo and paradex_klines, which are operational rather than meta-tools.
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 explicitly lists when to use the tool (e.g., understanding fields, data types, building JMESPath queries). However, it does not mention when not to use it or provide direct alternatives, though the sibling context implies alternatives for data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze funding rates for potential funding arbitrage or to understand holding costs.
Use this tool when you need to:
- Calculate expected funding payments for a position
- Find markets with extreme funding rates for potential arbitrage
- Understand historical funding patterns for a market
- Evaluate the cost of holding a position over time
This data is critical for perpetual futures traders to assess the carrying cost
of positions and identify potential funding arbitrage opportunities.
Example use cases:
- Finding markets with negative funding for "paid to hold" opportunities
- Calculating the funding component of a trade's P&L
- Comparing funding rates across different assets for relative value trades
- Analyzing funding rate volatility to predict potential rate changes
| Name | Required | Description | Default |
|---|---|---|---|
| market_id | Yes | Market symbol to get funding data for. | |
| start_unix_ms | Yes | Start time in unix milliseconds. | |
| end_unix_ms | Yes | End time in unix milliseconds. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description appropriately focuses on analytical use cases without contradicting annotations, but does not elaborate on additional behavioral traits like rate limits or data granularity.
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?
The description is well-structured with clear bullet points and example use cases. It is concise and front-loaded with the main purpose, making it easy for an agent to quickly understand.
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?
Given an output schema exists, the description does not need to detail return values. It covers typical use cases and provides sufficient context for accurate tool invocation, though it lacks details on data limits or pagination.
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?
Input schema has 100% description coverage for all three parameters. The description does not add new syntax or format details beyond the schema, but provides context on how parameters relate to use cases (e.g., time range for historical patterns).
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 clearly states the tool's purpose (analyzing funding rates for arbitrage and holding costs) and lists specific use cases, distinguishing it from sibling tools like orderbook or trades.
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 explicitly lists when to use the tool (calculating funding payments, finding extreme rates, etc.) and provides example use cases, though it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze historical price patterns for technical analysis and trading decisions.
Use this tool when you need to:
- Perform technical analysis on historical price data
- Identify support and resistance levels from price history
- Calculate indicators like moving averages, RSI, or MACD
- Backtest trading strategies on historical data
- Visualize price action over specific timeframes
Candlestick data is fundamental for most technical analysis and trading decisions,
providing structured price and volume information over time.
Example use cases:
- Identifying chart patterns for potential entries or exits
- Calculating technical indicators for trading signals
- Determining volatility by analyzing price ranges
- Finding significant price levels from historical support/resistance
- Measuring volume patterns to confirm price movements
| Name | Required | Description | Default |
|---|---|---|---|
| market_id | Yes | Market symbol to get klines for. | |
| resolution | No | The time resolution of the klines. | |
| start_unix_ms | Yes | Start time in unix milliseconds. | |
| end_unix_ms | Yes | End time in unix milliseconds. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds behavioral context by explaining that the tool provides structured price and volume data over time, and lists example use cases that reinforce its read-only nature. No contradictions.
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?
The description is well-structured with a clear opening, bullet-pointed usage scenarios, and a concluding paragraph. It is front-loaded with purpose and concise enough, though some sentences could be trimmed.
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?
Given the presence of an output schema, the description does not need to explain return values. It covers purpose, usage guidelines, and behavioral context thoroughly for a read-only data retrieval tool.
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% with descriptions for all parameters. The description does not add parameter-specific details beyond what the schema provides, so it meets the baseline but provides no extra value.
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 clearly states the tool analyzes historical price patterns for technical analysis and trading decisions, listing specific use cases like support/resistance, indicators, and backtesting. It distinguishes itself from sibling tools (e.g., orderbook, trades) by focusing on historical candlestick data.
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 explicitly outlines when to use the tool with a bulleted list of scenarios (technical analysis, support/resistance, indicators, backtesting, visualization). It does not explicitly mention when not to use it, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find markets that match your trading criteria or get detailed market specifications.
Use this tool when you need to:
- Understand exact tick sizes and minimum order sizes before placing trades
- Find all markets for a specific asset (e.g., all BTC-based markets)
- Compare contract specifications across different markets
- Identify markets with specific characteristics for your trading strategy
Retrieves comprehensive details about specified markets, including
base and quote assets, tick size, minimum order size, and other
trading parameters. If "ALL" is specified or no market IDs are provided,
returns details for all available markets.
Example use cases:
- Finding the minimum order size for a new trade
- Identifying markets with the smallest tick size for precise entries
- Checking which assets are available for trading
`asset_kind` is the type of asset in the market. It can be `PERP` or `PERP_OPTION`.
You can use JMESPath expressions (https://jmespath.org/specification.html) to filter, sort, or limit the results.
Use the `paradex_filters_model` tool to get the filters for a tool.
Examples:
- Filter by base asset: "[?base_asset=='BTC']"
- Sort by 24h volume: "sort_by([*], &volume_24h)"
- Limit to top 5 by volume: "[sort_by([*], &to_number(volume_24h))[-5:]]"
| Name | Required | Description | Default |
|---|---|---|---|
| market_ids | No | Market symbols to get details for. | |
| jmespath_filter | No | JMESPath expression to filter, sort, or limit the results. | |
| limit | No | Limit the number of results to the specified number. | |
| offset | No | Offset the results to the specified number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds behavioral context: retrieves comprehensive details, supports JMESPath filtering and returned fields. No contradiction.
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?
Well-structured with bullet points and examples, but somewhat lengthy due to repeated phrases. Could be slightly more concise without losing clarity.
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?
No output schema, but description adequately explains return data includes base/quote assets, tick size, etc. Covers essential use cases and filtering capabilities.
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% with all parameters documented. The description adds value by explaining asset_kind (though not a parameter) and providing JMESPath examples, enhancing understanding beyond 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?
The description clearly states the tool finds markets matching trading criteria or gets detailed specifications, and distinguishes itself from siblings like paradex_market_summaries by focusing on tick sizes, minimum order sizes, and contract specifications.
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?
Explicitly lists when to use: before placing trades, for specific assets, comparing specs, identifying markets for strategy. Does not mention when not to use or alternatives, but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify the most active or volatile markets and get current market conditions.
Use this tool when you need to:
- Find the most active markets by volume for liquidity analysis
- Discover markets with significant price movements for momentum strategies
- Compare current prices across multiple assets
- Identify markets with unusual behavior for potential opportunities
Retrieves current market summary information including price, volume,
24h change, and other key market metrics. If "ALL" is specified or no market IDs
are provided, returns summaries for all available markets.
Example use cases:
- Finding high-volatility markets for short-term trading
- Identifying top gainers and losers for the day
- Comparing volume across different markets to find liquidity
- Getting the current price and 24-hour range for price analysis
You can use JMESPath expressions (https://jmespath.org/specification.html) to filter, sort, or limit the results.
Use the `paradex_filters_model` tool to get the filters for a tool.
Examples:
- Filter by high price: "[?high_price > `10000`]"
- Sort by volume: "sort_by([*], &volume)"
- Get top 3 by price change: "[sort_by([*], &to_number(price_change_percent))[-3:]]"
| Name | Required | Description | Default |
|---|---|---|---|
| market_ids | No | Market symbols to get summaries for. | |
| jmespath_filter | No | JMESPath expression to filter, sort, or limit the results. | |
| limit | No | Limit the number of results to the specified number. | |
| offset | No | Offset the results to the specified number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds context: retrieves current market summary, can return all, supports JMESPath filtering. No contradictions.
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?
Description is long with multiple sections (use cases, examples, JMESPath). Well-structured and front-loaded, but could be more concise without losing key information.
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?
No output schema; description mentions 'price, volume, 24h change, and other key market metrics' but lacks explicit return format. Complete for most use cases but could be more detailed.
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%. Description explains default behavior for market_ids, JMESPath filtering with examples, limit, and offset. Adds meaning beyond schema, especially for JMESPath.
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?
Description clearly states the tool retrieves current market summary information including price, volume, 24h change, etc. It distinguishes from siblings by focusing on summaries and active/volatile markets, not orderbooks or klines.
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?
Explicitly lists when to use: find most active markets by volume, discover significant price movements, compare prices, identify unusual behavior. Provides example use cases. Does not explicitly state when not to use, but guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze market depth and liquidity to optimize order entry and execution.
Use this tool when you need to:
- Assess true liquidity before placing large orders
- Identify potential support/resistance levels from order clusters
- Determine optimal limit order prices for higher fill probability
- Detect order imbalances that might signal price direction
Understanding the orderbook is essential for effective trade execution,
especially for larger orders or in less liquid markets.
Example use cases:
- Finding the optimal limit price to ensure your order gets filled
- Estimating potential slippage for market orders of different sizes
- Identifying large resting orders that might act as support/resistance
- Detecting order book imbalances that could predict short-term price moves
| Name | Required | Description | Default |
|---|---|---|---|
| market_id | Yes | Market symbol to get orderbook for. | |
| depth | No | The depth of the orderbook to retrieve. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint: true. The description adds behavioral context by detailing how the orderbook data supports trade execution decisions, reinforcing the read-only nature without contradiction.
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?
The description is well-structured with an opening sentence and bullet points, but it includes some motivational language ('Understanding the orderbook is essential...') that adds length without critical value. Could be more concise.
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?
Given the tool's read-only nature, existing parameter descriptions, and presence of an output schema, the description covers use cases and interpretation comprehensively, making it contextually complete for an agent.
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% for both parameters, and the description does not add significant new details beyond confirming their roles in depth analysis. Baseline of 3 is appropriate.
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 clearly states the tool analyzes market depth and liquidity to optimize order entry, with specific use cases. However, it does not explicitly differentiate from sibling tools like paradex_bbo, which might also relate to market data.
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 provides a clear bullet list of when to use the tool, including assessing liquidity, identifying support/resistance, and detecting imbalances. It does not explicitly state when not to use it or compare to alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Understand the exchange's global parameters that affect all trading activity.
Use this tool when you need to:
- Check fee schedules before placing trades
- Verify trading limits and restrictions
- Understand exchange-wide parameters that affect your trading
- Keep up with changes to the exchange's configuration
This information provides important context for making trading decisions and
understanding how the exchange operates.
Example use cases:
- Checking current fee tiers for different markets
- Verifying maximum leverage available for specific markets
- Understanding global trading limits or restrictions
- Checking if any exchange-wide changes might affect your trading strategy
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| starknet_gateway_url | Yes | |
| starknet_fullnode_rpc_url | Yes | |
| starknet_fullnode_rpc_base_url | Yes | |
| starknet_chain_id | Yes | |
| block_explorer_url | Yes | |
| paraclear_address | Yes | |
| paraclear_decimals | Yes | |
| paraclear_account_proxy_hash | Yes | |
| paraclear_account_hash | Yes | |
| oracle_address | Yes | |
| bridged_tokens | Yes | |
| l1_core_contract_address | Yes | |
| l1_operator_address | Yes | |
| l1_chain_id | Yes | |
| liquidation_fee | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds context about the nature of the data (global parameters affecting trading) and usage scenarios (fee tiers, leverage, limits), enhancing transparency beyond annotations.
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?
The description is well-structured with bullet points and example use cases. It is slightly verbose but front-loaded with the main purpose, and every sentence adds value.
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?
Given no parameters and an available output schema, the description sufficiently covers the tool's purpose and usage context. It could be more detailed about the output structure, but the schema handles that.
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 input schema has no parameters, so schema coverage is 100%. The description goes beyond by explaining what the tool returns (global parameters) and when to use it, providing full context despite no parameters.
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 clearly states the tool's purpose: 'Understand the exchange's global parameters that affect all trading activity.' It is specific about the resource (global parameters) and distinguishes it from sibling tools focused on market data or trading operations.
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 provides explicit use cases (check fee schedules, verify limits, understand parameters) and example scenarios. It lacks explicit 'when not to use' guidance, but the context is clear enough to differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the exchange is fully operational before executing trades.
Use this tool when you need to:
- Check if Paradex is functioning normally before placing important orders
- Verify system status if you encounter unexpected behavior
- Confirm that maintenance periods are not in effect
- Check exchange clock synchronization with your own systems
This is especially important before executing critical trades or when
experiencing unexpected behavior from other API calls.
Example use cases:
- Verifying the exchange is operational before executing a trading strategy
- Checking if maintenance mode is active when experiencing delays
- Confirming exchange status during periods of market volatility
- Diagnosing API issues by checking system health
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| timestamp | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
ReadOnlyHint already indicates no side effects. Description adds value by detailing what is checked (maintenance, clock sync) and emphasizing importance before critical trades, going beyond annotation.
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?
Fairly organized but slightly verbose with bullet points and examples. Could be trimmed to core sentences without losing meaning.
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 and a simple status check, the description fully covers why and when to use the tool. The existence of an output schema further reduces need for return value details.
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?
No parameters in schema (100% coverage), so description doesn't need to add param info. It still justifies the tool's role, which is sufficient.
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 clearly states the tool checks if the exchange is operational, with a specific verb ('verify') and resource ('exchange system state'). It distinguishes itself from sibling tools by focusing on system readiness, not market data or configuration.
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?
Explicitly lists when to use (e.g., before trades, on unexpected behavior, check maintenance, clock sync). Lacks explicit when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze actual market transactions to understand market sentiment and liquidity.
Use this tool when you need to:
- Detect large trades that might signal institutional activity
- Calculate average trade size during specific periods
- Identify buy/sell pressure imbalances
- Monitor execution prices vs. order book prices
- Understand market momentum through trade flow
Trade data provides insights into actual market activity versus just orders,
helping you understand how other participants are behaving.
Example use cases:
- Detecting large "whale" transactions that might influence price
- Analyzing trade sizes to gauge market participation
- Identifying periods of aggressive buying or selling
- Understanding trade frequency as an indicator of market interest
- Comparing executed prices to orderbook mid-price for market impact analysis
| Name | Required | Description | Default |
|---|---|---|---|
| market_id | Yes | Market symbol to get trades for. | |
| start_unix_ms | Yes | Start time in unix milliseconds. | |
| end_unix_ms | Yes | End time in unix milliseconds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds value by explaining what trade data reveals about market activity. It does not contradict annotations and provides context beyond the hint.
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?
The description is well-structured with multiple paragraphs and bullet points, front-loading the purpose. Each sentence adds value, though slightly longer than minimal.
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 trade query tool with three well-described parameters and without output schema, the description covers purpose, usage, and examples. It lacks mention of potential limitations like maximum time range but is largely complete.
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% with clear param descriptions. The tool description does not add extra parameter semantics beyond what the schema provides, so baseline score of 3 is appropriate.
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 clearly states the tool analyzes actual market transactions to understand sentiment and liquidity, with specific verb and resource. It implicitly distinguishes from siblings by contrasting 'actual market activity versus just orders'.
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 explicitly lists when to use the tool (detecting large trades, calculating average trade size, etc.) and contrasts with orderbook data, providing clear guidance and example use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive overview of a vault's trading account status.
Use this tool when you need to:
- Check account health and available margin
- Monitor total exposure and leverage
- Understand risk metrics and account status
- Assess trading capacity before placing new orders
- Get a consolidated view of account performance
This provides essential information about account standing and
trading capacity to inform risk management decisions.
Example use cases:
- Checking available margin before placing new orders
- Monitoring account health during market volatility
- Assessing total exposure across all markets
- Understanding maintenance margin requirements
- Planning position adjustments based on account metrics
| Name | Required | Description | Default |
|---|---|---|---|
| vault_address | Yes | The address of the vault to get account summary for. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description adds context about risk metrics, margin, exposure, and leverage without contradiction. Adds value beyond annotations by detailing the kind of information returned.
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?
Well-structured with bullet points and examples, but slightly verbose with redundant phrasing ('Essential information about account standing'). Front-loaded purpose is good.
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?
Adequately covers purpose and usage for a single-parameter tool with output schema. Does not cover prerequisites or potential errors, but sufficient for effective use.
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%, so baseline is 3. Description does not add meaning beyond the schema's parameter description ('The address of the vault...').
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?
Clear verb ('Get a comprehensive overview') and resource ('vault's trading account status'). Distinguishes from sibling vault tools like vault_balance, vault_positions, and vault_summary by focusing on overall account health and trading capacity.
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?
Explicit 'Use this tool when you need to' list and example use cases. Lacks when not to use or comparison with siblings, but provides strong positive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current balance of a specific vault.
Retrieves the current balance information for a specific vault, including available funds, locked funds, and total balance. This is essential for understanding the financial state of a vault before executing trades or withdrawals.
| Name | Required | Description | Default |
|---|---|---|---|
| vault_address | Yes | The address of the vault to get balance for. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms it's a read operation. It adds detail about what the balance includes (available, locked, total), providing useful behavioral context beyond the annotation.
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?
The description is concise and front-loaded with the main action. It uses three brief sentences to convey purpose, result content, and use context, with no unnecessary words.
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?
Given the tool has an output schema (not shown but indicated in context signals), the description does not need to detail return values. It covers the single parameter, purpose, and usage context. It appears complete for this simple tool.
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 input schema has one parameter (vault_address) with a description, and schema description coverage is 100%. The tool description does not add extra meaning to this parameter beyond what the schema already provides.
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 clearly states 'Get the current balance of a specific vault' and lists the types of balance info retrieved (available, locked, total). However, it does not explicitly differentiate from sibling vault tools like paradex_vault_summary or paradex_vault_account_summary.
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 says this tool is 'essential for understanding the financial state of a vault before executing trades or withdrawals,' implying a use case, but it does not provide explicit guidance on when to use this vs. other vault tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor active trading positions to track performance and manage risk.
Use this tool when you need to:
- Get a complete view of all open positions for a vault
- Monitor unrealized P&L across all positions
- Check liquidation prices and margin requirements
- Assess position sizing and leverage across markets
- Track entry prices and position duration
Position monitoring is fundamental to risk management and provides
the necessary information for trade management decisions.
Example use cases:
- Checking the current status of all open trades
- Monitoring unrealized profit/loss across positions
- Assessing liquidation risk during market volatility
- Comparing performance across different markets
- Planning adjustments to position sizes or leverage
| Name | Required | Description | Default |
|---|---|---|---|
| vault_address | Yes | The address of the vault to get positions for. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description aligns by emphasizing monitoring and tracking rather than modification. The description adds behavioral context by specifying the types of data available (unrealized P&L, liquidation prices, entry prices). No contradictions.
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?
The description is concise yet comprehensive, using bullet points and example use cases to convey information efficiently. It is front-loaded with the main purpose and every sentence adds value without 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?
Given the presence of an output schema, the description does not need to detail return values. The single parameter is well-documented, annotations are clear, and the description covers all essential usage scenarios for a monitoring tool. No gaps.
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 input schema contains one parameter (vault_address) with a clear description. Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that the tool returns position data for that vault, including specific metrics like P&L and leverage, enhancing semantic understanding.
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 clearly states the tool monitors active trading positions to track performance and manage risk. It lists specific use cases (e.g., get open positions, monitor unrealized P&L, check liquidation prices) that distinguish it from sibling tools like vault_balance and vault_summary.
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 provides explicit use cases and example scenarios (e.g., checking status of open trades, monitoring P&L, assessing liquidation risk). While it does not explicitly state when not to use the tool, the listed use cases effectively guide the agent. Sibling differentiation is implied by the focus on positions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific vault or all vaults if no address is provided.
Retrieves comprehensive details about a specific vault identified by its address,
including configuration, permissions, and other vault-specific parameters.
Use jmespath_filter to reduce the number of results as much as possible as number of vaults can be large.
You can use JMESPath expressions to filter, sort, or limit the results.
Examples:
- Filter by owner: "[?owner_account=='0x123...']"
- Filter by status: "[?status=='ACTIVE']"
- Find vaults with specific strategy: "[?contains(strategies, 'strategy_id')]"
- Sort by creation date: "sort_by([*], &created_at)"
- Limit to newest vaults: "sort_by([*], &created_at)[-5:]"
- Select specific fields: "[*].{address: address, name: name, kind: kind, status: status}"
| Name | Required | Description | Default |
|---|---|---|---|
| vault_address | No | The address of the vault to get details for or empty string to get all vaults. | |
| jmespath_filter | No | JMESPath expression to filter, sort, or limit the results. | |
| limit | No | Limit the number of results to the specified number. | |
| offset | No | Offset the results to the specified number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's job is lighter. It adds value by stating the tool retrieves 'comprehensive details... including configuration, permissions, and other vault-specific parameters,' which is behavioral context beyond the annotation.
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?
The description is front-loaded with the core purpose and then provides examples. It is efficient but includes several JMESPath examples that are valuable, though slightly lengthy. Every sentence 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?
Given the tool has no output schema, the description sufficiently explains the tool's behavior, input parameters, and filtering capability. It covers the main use case and provides necessary constraints (large number of vaults). It is complete for a list/detail retrieval tool.
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 baseline is 3. The description adds meaning by explaining that vault_address can be empty to get all vaults, and provides examples for jmespath_filter usage, going beyond the schema descriptions.
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 states 'Get detailed information about a specific vault or all vaults if no address is provided,' clearly identifying the verb and resource. It distinguishes between fetching a specific vault or all vaults, and among sibling vault-related tools, this one is uniquely about vault details.
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 includes explicit guidance to 'Use jmespath_filter to reduce the number of results as much as possible as number of vaults can be large,' providing clear context for when to use filtering. However, it does not specify when to prefer this tool over alternatives like paradex_vault_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive summary of a specific vault or all vaults if no address is provided.
Retrieves a summary of all important information about a vault,
including balance, positions, recent activity, and performance metrics.
This provides a high-level overview of the vault's current state.
Use jmespath_filter to reduce the number of results as much as possible as number of vaults can be large.
You can use JMESPath expressions to filter, sort, or transform the results.
Examples:
- Filter by TVL: "[?to_number(tvl) > `10000`]"
- Filter by performance: "[?to_number(total_roi) > `5.0`]"
- Sort by TVL (descending): "reverse(sort_by([*], &to_number(tvl)))"
- Get top performers: "sort_by([*], &to_number(total_roi))[-3:]"
- Filter by recent returns: "[?to_number(roi_24h) > `0.5`]"
- Extract specific metrics: "[*].{address: address, tvl: tvl, total_roi: total_roi, volume_24h: volume_24h}"
| Name | Required | Description | Default |
|---|---|---|---|
| vault_address | No | The address of the vault to get summary for or None to get all vaults. | |
| jmespath_filter | No | JMESPath expression to filter or transform the result. | |
| limit | No | Limit the number of results to the specified number. | |
| offset | No | Offset the results to the specified number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true) align with the description. The description adds useful behavioral context: it returns a high-level overview including performance metrics, and implies no side effects. No contradictions.
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?
Description is mostly concise but has repetition ('Get a comprehensive summary' appears twice). JMESPath examples are extensive, though valuable. Slight redundancy could be trimmed.
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?
Covers vault_address optionality, JMESPath filtering with examples, and pagination parameters. Lacks details on return value structure (though output schema missing) and error handling. Adequate for a read-only summary tool.
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%, but description adds extensive value: clarifies vault_address is optional, provides detailed JMESPath expression examples for filtering/sorting, and explains limit/offset pagination. Examples are highly instructive.
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?
Description clearly states it retrieves a comprehensive summary of a specific vault or all vaults, listing included metrics (balance, positions, activity, performance). This distinguishes it from sibling tools like paradex_vault_balance or paradex_vault_positions.
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?
Explicitly advises using jmespath_filter to reduce results for large vault sets. However, it does not contrast with siblings like paradex_vault_account_summary or paradex_vault_summary_vs_detail tools, leaving some ambiguity on when to use this high-level overview vs specific detail tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track deposit and withdrawal history for auditing and reconciliation.
Use this tool when you need to:
- Verify deposits have completed and are available for trading
- Track withdrawal status and confirm transaction settlement
- Audit the complete fund flow history for a vault
- Reconcile on-chain transactions with platform records
- Understand historical capital allocation patterns
Complete transfer history is essential for proper accounting and provides
a clear audit trail of all capital movements.
Example use cases:
- Confirming that a recent deposit was credited to your account
- Tracking the status of pending withdrawals
- Creating transaction reports for accounting or tax purposes
- Verifying the total amount deposited over time
- Analyzing deposit/withdrawal patterns for strategy insights
| Name | Required | Description | Default |
|---|---|---|---|
| vault_address | Yes | The address of the vault to get transfers for. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description primarily adds context about auditing and reconciliation purposes. It does not disclose behaviors beyond that, such as pagination, rate limits, or data freshness. The additional context is useful but not extensive.
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?
The description is well-structured with bullet points and example use cases, front-loading the primary purpose. While it is somewhat lengthy, every sentence adds value. A slightly more concise version would be ideal, but it remains effective.
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?
Given the tool's simplicity (1 parameter, output schema present, annotations complete), the description provides comprehensive context for usage, including multiple use cases and a clear audit/reconciliation framing. It is fully adequate for the tool's complexity.
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% (vault_address described). The description does not add significant meaning beyond the schema for the single parameter, as it focuses on the tool's overall purpose. Baseline of 3 is appropriate since schema covers the parameter adequately.
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 clearly states the tool tracks deposit and withdrawal history for auditing and reconciliation. It uses specific verbs ('track', 'verify', 'audit') and resource ('deposit and withdrawal history'). It effectively distinguishes from sibling tools like paradex_vault_balance or paradex_vault_summary by focusing on historical movements.
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 lists specific when-to-use scenarios (verify deposits, track withdrawal status, audit fund flow, reconcile, understand patterns) and provides concrete example use cases. However, it does not explicitly state when not to use or mention alternative tools, which is a minor gap.
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. Dates show when Glama detected each change.
v0.1.1paradex_account_fillsparadex_account_funding_paymentsparadex_account_positionsparadex_account_summaryparadex_account_transactionsparadex_cancel_ordersparadex_create_orderparadex_open_ordersparadex_order_statusparadex_orders_historyparadex_system_config2 fields changedOutput schema / properties / starknet_fullnode_rpc_base_urlAdded value: +{
+ "title": "Starknet Fullnode Rpc Base Url",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "starknet_gateway_url",
- "starknet_fullnode_rpc_url",
- "starknet_chain_id",
- "block_explorer_url",
- "paraclear_address",
- "paraclear_decimals",
- "paraclear_account_proxy_hash",
- "paraclear_account_hash",
- "oracle_address",
- "bridged_tokens",
- "l1_core_contract_address",
- "l1_operator_address",
- "l1_chain_id",
- "liquidation_fee"
-]New value: +[
+ "starknet_gateway_url",
+ "starknet_fullnode_rpc_url",
+ "starknet_fullnode_rpc_base_url",
+ "starknet_chain_id",
+ "block_explorer_url",
+ "paraclear_address",
+ "paraclear_decimals",
+ "paraclear_account_proxy_hash",
+ "paraclear_account_hash",
+ "oracle_address",
+ "bridged_tokens",
+ "l1_core_contract_address",
+ "l1_operator_address",
+ "l1_chain_id",
+ "liquidation_fee"
+]v1.0.0paradex_account_fillsparadex_account_funding_paymentsparadex_account_positionsparadex_account_summaryparadex_account_transactionsparadex_bboparadex_cancel_ordersparadex_create_orderparadex_filters_modelparadex_funding_dataparadex_klinesparadex_market_summariesparadex_marketsparadex_open_ordersparadex_order_statusparadex_orderbookparadex_orders_historyparadex_system_configparadex_system_stateparadex_tradesparadex_vault_account_summaryparadex_vault_balanceparadex_vault_positionsparadex_vault_summaryparadex_vault_transfersparadex_vaultsEach tool has a clearly distinct purpose. Market data tools (bbo, orderbook, klines, trades, markets, summaries, funding_data) cover different aspects. Vault tools (vault_account_summary, vault_balance, vault_positions, vaults, vault_summary, vault_transfers) each provide unique account information. System tools (system_config, system_state) and filters_model serve separate needs. No significant overlap.
All tool names follow the pattern 'paradex_' followed by a domain noun or compound noun (e.g., 'bbo', 'filters_model', 'vault_account_summary'). The naming structure is consistent, though some names use a single noun (e.g., 'paradex_markets') and others use multiple nouns (e.g., 'paradex_market_summaries'). This is a minor deviation from a strict pattern, but overall it is clear and predictable.
With 16 tools, the count is on the higher side for a data-oriented server, but each tool serves a distinct data retrieval purpose (market, system, vault). No tool seems superfluous. The number is appropriate for the scope of providing comprehensive read access to exchange data and account information.
The tool set is missing critical trading execution tools such as place_order, cancel_order, or modify_order. Given that the tools extensively support pre-trade analysis and account monitoring, the lack of order management creates a significant gap for actual trading. This suggests an incomplete surface for a server named 'Paradex Server'.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sv/mcp-paradex-py'
If you have feedback or need assistance with the MCP directory API, please join our Discord server