MCP Paradex Server

by sv

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count4/5
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.
Completeness2/5
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'.
Average 4.2/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-paradex-py MCP server](https://glama.ai/mcp/servers/sv/mcp-paradex-py/badges/card.svg)](https://glama.ai/mcp/servers/sv/mcp-paradex-py)

Score Badge

Copy to your README.md:

[![mcp-paradex-py MCP server](https://glama.ai/mcp/servers/sv/mcp-paradex-py/badges/score.svg)](https://glama.ai/mcp/servers/sv/mcp-paradex-py)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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