MCP Paradex Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as paradex_account_fills for executed trades and paradex_account_positions for open positions. However, some overlap exists between paradex_account_summary and paradex_vault_account_summary, which could cause confusion in selecting the right tool for account overviews, and between paradex_markets and paradex_market_summaries for market information. The descriptions help clarify, but minor ambiguity remains.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a clear 'paradex_' prefix, and most use a verb_noun structure (e.g., paradex_create_order, paradex_cancel_orders). The naming is highly predictable and uniform across all 26 tools, making it easy for agents to understand and navigate the toolset without confusion.
Tool Count3/5
With 26 tools, the count is borderline high for a trading server, as it may feel heavy and overwhelming for agents to manage. While the tools cover a comprehensive range of trading functions (e.g., account management, order execution, market data), some could potentially be consolidated (e.g., multiple vault-related tools) to reduce complexity without losing functionality.
Completeness5/5
The toolset provides complete coverage for a trading platform, including CRUD operations (e.g., create_order, cancel_orders), account and vault management, market data analysis, and system monitoring. There are no obvious gaps; tools like paradex_filters_model support advanced filtering, and lifecycle coverage (e.g., from order creation to history) is thorough, ensuring agents can handle all typical trading workflows without dead ends.
Average 4.1/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving historical orders and lists included statuses (filled, canceled, expired), but does not cover critical aspects such as pagination, rate limits, authentication requirements, error handling, or the format of returned data. For a read operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 concise and well-structured with three sentences: a direct statement of purpose, elaboration on what is retrieved, and a usage note. Each sentence adds value without redundancy. However, it could be slightly more front-loaded by integrating the usage note into the purpose statement for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a historical orders retrieval tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., data format, pagination, limits) and does not explain return values, leaving the agent uncertain about what to expect. For a tool with 3 required parameters and no structured output information, more context is needed to be fully helpful.
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, with clear descriptions for each parameter (market_id, start_unix_ms, end_unix_ms). The description does not add any additional meaning beyond what the schema provides, as it does not explain parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents parameters without extra help from the description.
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's purpose: 'Get historical orders' and 'Retrieves the history of orders for the account, including filled, canceled, and expired orders.' It specifies the verb ('Get'/'Retrieves') and resource ('historical orders'/'history of orders'), but does not explicitly differentiate it from sibling tools like 'paradex_open_orders' or 'paradex_order_status', which might handle current or specific orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: 'This is useful for analyzing past trading activity and performance.' It implies usage for historical analysis but does not specify when to use this tool versus alternatives (e.g., 'paradex_open_orders' for current orders or 'paradex_account_fills' for trade executions). No explicit when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what information is retrieved ('available funds, locked funds, and total balance'), which adds some context. However, it doesn't describe key behavioral traits such as whether this is a read-only operation (implied by 'get' but not explicit), authentication requirements, rate limits, error conditions, or how the data is formatted in the output. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by elaboration and context. It uses three sentences efficiently, with no redundant information. However, the second sentence could be slightly more concise, and the structure is straightforward but not exceptionally polished.
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?
Given the tool's complexity (simple read operation with one parameter) and the presence of an output schema (which handles return values), the description is moderately complete. It covers the purpose and basic usage context but lacks details on behavioral aspects like authentication or error handling. With no annotations and an output schema, the description provides a foundation but doesn't fully address all contextual needs for a tool in a financial trading environment.
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, with the parameter 'vault_address' clearly documented in the schema. The description doesn't add any additional meaning beyond what the schema provides (e.g., it doesn't explain the format of the address or provide examples). Since schema coverage is high, the baseline score is 3, as the description doesn't compensate but also doesn't detract from the schema's documentation.
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's purpose: 'Get the current balance of a specific vault' and 'Retrieves the current balance information for a specific vault'. It specifies the verb ('get', 'retrieves') and resource ('vault'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'paradex_vault_summary' or 'paradex_vault_account_summary', which might offer overlapping or related information.
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 provides implied usage context: 'This is essential for understanding the financial state of a vault before executing trades or withdrawals.' This suggests when to use the tool (pre-trade or pre-withdrawal checks), but it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools (e.g., 'paradex_vault_summary' might provide broader vault details). The guidance is helpful but lacks explicit exclusions or comparisons.
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?
No annotations are provided, so the description carries the full burden. It describes behavioral aspects like analyzing historical data for technical analysis, backtesting, and visualization, which goes beyond the input schema. However, it lacks details on critical behaviors such as rate limits, authentication requirements, data freshness, or error handling. For a tool with no annotations, this is a moderate but incomplete disclosure.
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 front-loaded with a clear purpose statement, followed by bulleted lists for use cases and examples. However, it includes redundant phrasing (e.g., 'Candlestick data is fundamental...' adds little value) and could be more streamlined. Some sentences don't earn their place, making it slightly verbose rather than optimally 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 complexity (historical data analysis), the description covers purpose and usage well, and an output schema exists (per context signals), so it doesn't need to explain return values. With no annotations, it could improve by adding more behavioral context, but it's largely complete for guiding an agent on when and how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (market_id, resolution, start_unix_ms, end_unix_ms) with descriptions. The description doesn't add any specific parameter semantics beyond what's in the schema (e.g., it doesn't explain format details or constraints). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
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's purpose: 'Analyze historical price patterns for technical analysis and trading decisions.' It specifies the verb ('analyze') and resource ('historical price patterns'), making it distinct from siblings like account management or order execution tools. However, it doesn't explicitly differentiate from potential similar tools (e.g., 'paradex_trades' might also provide price data), so it doesn't reach the highest score.
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 bulleted list of specific use cases (e.g., 'Perform technical analysis on historical price data,' 'Calculate indicators like moving averages'), which gives clear context for when to use this tool. It implies usage for technical analysis rather than real-time trading or account management, aligning with sibling tools. However, it doesn't explicitly state when NOT to use it or name alternatives, preventing a score of 5.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains that funding payments impact P&L in perpetual futures trading, especially for longer-term positions or volatile markets. However, it doesn't disclose technical behaviors like rate limits, authentication requirements, pagination, or error conditions that would be important for an agent.
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 purpose statement followed by usage guidelines and example use cases. While comprehensive, some sentences could be more concise. The information is front-loaded with the core purpose first, and each section adds value without unnecessary repetition.
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 historical data tool with good schema coverage but no output schema, the description provides strong context about what the tool returns (funding payment history) and its business purpose. It adequately explains why this data matters for trading analysis, though it could benefit from mentioning the format or structure of returned data.
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%, providing good documentation for all 3 parameters. The description doesn't add specific parameter semantics beyond what's in the schema, but it implies the temporal filtering (start/end times) through its focus on payment history analysis. The baseline 3 is appropriate given the comprehensive schema coverage.
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's purpose as tracking funding payment history to understand P&L impact, using specific verbs like 'track' and 'calculate'. It distinguishes from siblings like paradex_account_transactions by focusing specifically on funding payments rather than general transactions, though it doesn't explicitly name alternatives.
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 provides explicit guidance on when to use this tool with a bulleted list of 5 specific scenarios, including 'calculate total funding costs', 'analyze performance impact', 'plan position timing', 'compare across markets', and 'account for funding in strategy'. It clearly differentiates this from other account tools by focusing on funding payment analysis.
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?
With no annotations provided, the description carries full burden. It discloses that the tool retrieves filtered history and mentions avoiding overwhelming results, which hints at performance considerations. However, it doesn't address authentication needs, rate limits, pagination behavior beyond the limit parameter, or whether this is a read-only operation (though 'Get' implies it).
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 appropriately sized and front-loaded with the core purpose in the first sentence. The bulleted use cases add helpful context without being redundant. However, the second paragraph about avoiding overwhelming results could be integrated more seamlessly.
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 moderate complexity (4 parameters, 2 required), 100% schema coverage, and presence of an output schema, the description provides adequate context. It covers purpose, usage scenarios, and filtering rationale. The main gap is lack of explicit behavioral details about authentication, rate limits, or pagination that would be helpful despite the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds marginal value by mentioning 'transaction_type and time filters' and the purpose of limiting results, but doesn't provide additional semantic context beyond what's in 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 clearly states the tool's purpose with specific verbs ('Get', 'Retrieves') and resources ('account transaction history', 'deposits, withdrawals, trades, funding payments, and other account activities'). It distinguishes from siblings by focusing on comprehensive transaction history rather than specific subsets like 'fills' or 'funding_payments' alone.
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 clear context for when to use this tool ('to limit results and avoid overwhelming the client') and lists valuable use cases (reconciliation, auditing, tracking, analyzing). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for more specialized queries.
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?
No annotations are provided, so the description carries the full burden. It describes the tool's function as tracking history for auditing, implying it's a read-only operation, but doesn't explicitly state behavioral traits like whether it requires authentication, has rate limits, or details on data freshness. It adds some context (e.g., 'complete transfer history') but lacks specifics on performance or constraints.
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 sentence, bulleted usage guidelines, and example use cases. It's appropriately sized and front-loaded, though it could be slightly more concise by avoiding repetition between guidelines and examples. Every sentence adds value, but there's minor 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?
Given the tool's complexity (read-only history tracking), no annotations, and an output schema exists (implying return values are documented), the description is fairly complete. It covers purpose, usage, and examples, but could improve by addressing behavioral aspects like data latency or access permissions to fully compensate for the lack of annotations.
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, with the parameter 'vault_address' clearly documented. The description doesn't add any meaning beyond what the schema provides, as it doesn't explain the parameter's role or format. With high schema coverage, the baseline is 3, and the description doesn't compensate with additional insights.
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's purpose as tracking deposit and withdrawal history for auditing and reconciliation, which is a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'paradex_account_transactions' or 'paradex_vault_account_summary', which might have overlapping functionality, so it misses full sibling differentiation.
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 provides explicit usage guidelines with a bulleted list of when to use this tool (e.g., verify deposits, track withdrawal status, audit fund flow, reconcile transactions, understand patterns). It clearly outlines specific scenarios, though it doesn't explicitly mention when not to use it or name alternatives among siblings.
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?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as providing 'real-time price changes' and 'minimal data' for efficiency, but lacks details on rate limits, authentication needs, or specific return formats. It adequately describes the tool's function but misses deeper operational context.
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 and front-loaded with the core purpose, followed by usage guidelines and examples. It is appropriately sized, but could be slightly more concise by avoiding repetition in the example use cases, which echo earlier points. Overall, it efficiently conveys 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?
Given the tool's complexity (a real-time price query), no annotations, and no output schema, the description is moderately complete. It covers purpose and usage well but lacks details on output format, error handling, or behavioral constraints like latency or data freshness, which are important for trading contexts.
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, with 'market_id' clearly documented. The description does not add parameter semantics beyond the schema, as it focuses on usage and context rather than parameter details. With high schema coverage, 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 the tool's purpose: 'Get the current best available prices for immediate execution decisions.' It specifies the verb ('Get') and resource ('current best available prices'), and distinguishes it from sibling tools like 'paradex_orderbook' by emphasizing minimal data for quick decisions versus full orderbook depth.
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 provides explicit usage guidelines, listing specific scenarios when to use this tool (e.g., 'Make quick trading decisions without full orderbook depth') and implicitly when not to use it (when full depth is needed). It also distinguishes it from alternatives by noting it's 'perfect for quick decisions or when full orderbook depth isn't needed,' contrasting with tools like 'paradex_orderbook'.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool provides 'important context for making trading decisions' and helps 'keep up with changes,' implying it's a read-only, informational tool without side effects. However, it lacks details on behavioral traits such as rate limits, authentication requirements, or data freshness, which are important for a trading context.
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 clear sections: purpose, usage guidelines, and example use cases. It's appropriately sized and front-loaded, starting with the core purpose. However, some sentences in the example use cases could be more concise, and the overall length is moderate but not excessive.
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 complexity (informational with 0 parameters), no annotations, and the presence of an output schema, the description is fairly complete. It explains the tool's role in trading decisions and provides usage examples, but it could benefit from more detail on output format or limitations, though the output schema mitigates this gap.
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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter semantics in the description. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any missing parameter info, and it appropriately focuses on usage and context without redundant details.
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's purpose: 'Understand the exchange's global parameters that affect all trading activity.' It specifies the verb 'understand' and resource 'global parameters,' making the intent explicit. However, it doesn't distinctly differentiate from sibling tools like 'paradex_system_state' or 'paradex_filters_model,' which might also relate to system-wide information, so it falls short of a perfect score.
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 provides explicit usage guidelines with a bulleted list of scenarios: 'Check fee schedules before placing trades,' 'Verify trading limits and restrictions,' etc. It clearly indicates when to use this tool by linking it to specific needs like understanding exchange-wide parameters and making trading decisions, though it doesn't explicitly mention when not to use it or name alternatives.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (analyzes trades for insights) and lists use cases, but lacks details on behavioral traits such as rate limits, authentication requirements, error conditions, or response format. For a tool with no annotations, this is a moderate gap, though the description does add value by explaining the analytical nature of the tool.
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 clear sections: purpose statement, usage guidelines, explanatory note, and example use cases. It is front-loaded with the main purpose. However, it could be more concise by integrating the explanatory note into the purpose or reducing redundancy in the example use cases (e.g., some overlap with usage guidelines).
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?
Given no annotations and no output schema, the description provides good purpose and usage context but lacks details on behavioral traits and return values. For a tool with 3 parameters and 100% schema coverage, the description is adequate for understanding when to use it, but incomplete for operational aspects like response format or error handling. It meets minimum viability with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (market_id, start_unix_ms, end_unix_ms) with clear descriptions. The description does not add any parameter-specific information beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
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: 'Analyze actual market transactions to understand market sentiment and liquidity.' It specifies the verb 'analyze' and resource 'market transactions,' distinguishing it from sibling tools like paradex_orderbook (which shows orders) or paradex_account_fills (which shows user-specific trades). The focus on actual transactions vs. orders is a key differentiator.
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 provides explicit usage guidelines with a bulleted list of when to use this tool (e.g., 'Detect large trades,' 'Calculate average trade size,' 'Identify buy/sell pressure imbalances'). It implicitly distinguishes from alternatives by emphasizing 'actual market transactions' versus 'just orders,' helping the agent choose this over tools like paradex_orderbook. The example use cases further clarify appropriate contexts.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior (retrieving details, handling large result sets with filtering) and provides practical guidance on using JMESPath expressions. However, it lacks information on potential rate limits, authentication requirements, or error conditions that would be important for a tool dealing with potentially large datasets.
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 and appropriately sized. It front-loads the core purpose, follows with detailed behavior explanation, then provides practical usage guidance with examples. While comprehensive, every sentence serves a clear purpose, though the JMESPath examples section is somewhat lengthy but necessary for clarity.
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?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description does a reasonable job but has gaps. It explains the tool's behavior and parameter usage well, but lacks information about return format, pagination behavior (beyond limit/offset parameters), error handling, or performance considerations for large datasets. The absence of an output schema increases the need for more complete behavioral description.
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?
With 100% schema description coverage, the baseline is 3. The description adds significant value beyond the schema by explaining the practical implications of parameters: it clarifies that vault_address being empty returns all vaults, emphasizes jmespath_filter's importance for managing large result sets, and provides concrete examples of JMESPath usage that go beyond the schema's basic description.
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 with specific verbs ('Get detailed information', 'Retrieves comprehensive details') and resources ('vault' or 'all vaults'). It distinguishes this tool from siblings like paradex_vault_summary or paradex_vault_balance by emphasizing detailed information retrieval rather than summaries or specific data subsets.
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 clear context for usage: 'if no address is provided' to get all vaults, and advises using jmespath_filter to reduce results 'as number of vaults can be large'. However, it does not explicitly mention when to use this tool versus alternatives like paradex_vault_summary or paradex_vault_account_summary, which could help differentiate use cases.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by explaining the tool's read-only nature (implied by 'Get' and 'Retrieves'), the potential for large result sets, and the use of filtering to manage this. However, it lacks details on rate limits, authentication requirements, error conditions, or pagination behavior beyond limit/offset parameters, leaving some behavioral aspects unclear for an AI agent.
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 and appropriately sized. It front-loads the core purpose, follows with detailed explanation of what the summary includes, then provides crucial usage guidance with concrete examples. While slightly longer due to the examples, every sentence earns its place by adding practical value for tool invocation. The examples are necessary but could be slightly more concise.
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?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is reasonably complete but has gaps. It covers the purpose, parameters, and usage context well, but lacks information about return format, error handling, or performance characteristics. Without an output schema, the agent doesn't know what structure to expect in the response, which is a significant omission for a summary tool that returns potentially complex data.
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 schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining the semantic meaning of vault_address ('specific vault or all vaults if no address is provided') and providing extensive, practical examples for jmespath_filter parameter usage. These examples transform abstract parameter descriptions into actionable guidance, though it doesn't add meaning for limit/offset beyond what the schema already covers.
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: 'Get a comprehensive summary of a specific vault or all vaults if no address is provided.' It specifies the verb ('Get'), resource ('vault'), and scope ('specific vault or all vaults'), distinguishing it from siblings like paradex_vault_balance or paradex_vault_positions which focus on specific aspects rather than comprehensive summaries.
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 clear context for usage: it explains when to use the tool (to get a high-level overview of vault state) and includes practical guidance on using jmespath_filter to handle large result sets. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among its siblings, such as paradex_vaults for basic listing or paradex_vault_account_summary for account-level details.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool is for analysis of executed trades, implying it's a read-only operation (no destructive actions mentioned). However, it lacks details on behavioral traits like rate limits, authentication needs, pagination, or error handling. The description adds some context (e.g., 'Detailed fill information is essential for performance analysis') but doesn't fully compensate for the absence of 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 a clear opening sentence, bulleted usage guidelines, and example use cases. It is appropriately sized for a tool with three parameters and no annotations, though it could be slightly more concise by integrating some bullet points. Every sentence adds value, such as explaining why fill information is essential, making it front-loaded and efficient.
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 complexity (analysis of executed trades), lack of annotations, and no output schema, the description does a good job of covering purpose and usage. It provides context on what the tool returns (e.g., execution quality, realized PnL) and use cases, compensating for missing structured data. However, it could improve by mentioning output format or limitations, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (market_id, start_unix_ms, end_unix_ms). The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain format constraints or relationships between parameters). Baseline 3 is appropriate as the schema handles parameter documentation 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's purpose: 'Analyze your executed trades to evaluate performance and execution quality.' It specifies the verb 'analyze' and resource 'executed trades,' distinguishing it from siblings like paradex_account_positions (current holdings) or paradex_orders_history (order status). The description is specific and avoids tautology.
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 provides explicit usage guidelines with a bulleted list of when to use this tool, including 'Review your trading history across specific markets' and 'Calculate your average entry price for multi-fill positions.' It implicitly distinguishes from siblings by focusing on executed trades (e.g., vs. paradex_open_orders for pending orders). The example use cases further clarify context, such as for tax purposes or strategy analysis.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only metadata tool (implied by 'get detailed schema information'), but doesn't specify response format, error conditions, or performance characteristics. The description adds value by explaining the tool's role in filter construction, but lacks complete behavioral context.
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 clear sections: purpose statement, usage guidelines, and example use cases. While slightly verbose with 8 sentences, every sentence adds value by clarifying different aspects of when and how to use the tool. The front-loaded purpose statement immediately communicates the tool's function.
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 moderate complexity (schema/metadata retrieval), no annotations, and no output schema, the description does a good job explaining the tool's purpose and usage context. It provides comprehensive guidance on when to use the tool and what benefits it offers, though it doesn't describe the return format or potential limitations.
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 the single parameter 'tool_name', which is adequately described in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, maintaining the baseline score of 3 for high schema coverage. No additional syntax or format details are provided for the parameter.
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 as 'Get detailed schema information to build precise data filters' with specific verbs ('get', 'build', 'learn') and resources ('schema information', 'data filters'). It distinguishes itself from sibling tools by focusing on metadata/schema retrieval rather than actual data operations like trading or account management.
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 provides explicit usage guidelines with a bulleted list of specific scenarios: 'when you need to understand exactly what fields are available for filtering', 'learn the data types and formats', 'build complex JMESPath queries', and 'create sophisticated filtering and sorting expressions'. It clearly defines the tool's purpose as preparatory/metadata-focused rather than for actual 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?
No annotations are provided, so the description carries the full burden. It discloses behavioral traits such as the tool's focus on analysis for traders, its critical role in assessing carrying costs and arbitrage, and example use cases like finding negative funding rates. However, it lacks details on rate limits, authentication needs, data freshness, or error handling, which are important for a data analysis tool with no annotation coverage.
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 and front-loaded with the core purpose, followed by usage guidelines, context, and examples. It uses bullet points for clarity and avoids redundancy. However, it could be slightly more concise by integrating some explanatory sentences, but overall, each section adds value without unnecessary verbosity.
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 complexity (funding rate analysis for trading), no annotations, and an output schema (which handles return values), the description is fairly complete. It covers purpose, usage scenarios, and examples, but lacks behavioral details like data sources or limitations. With output schema reducing the need to explain returns, the description provides adequate context for an agent to understand when and why to use the 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 schema description coverage is 100%, so the schema already documents all three parameters (market_id, start_unix_ms, end_unix_ms). The description does not add any parameter-specific semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score is 3, as the description relies on the schema for parameter details.
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: 'Analyze funding rates for potential funding arbitrage or to understand holding costs.' It specifies the verb ('analyze') and resource ('funding rates'), distinguishing it from siblings like paradex_account_funding_payments (which likely lists payments) or paradex_market_summaries (which may include broader market data). The focus on analysis for arbitrage and cost assessment is specific and actionable.
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 provides explicit usage guidelines with a bulleted list of scenarios: '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 clearly defines when to use it, and the context signals (e.g., sibling tools) suggest alternatives like paradex_account_funding_payments for payment details, though not explicitly named.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only status checking tool (implied by 'check', 'verify', 'track') and describes what information can be retrieved (acceptance status, fill details, cancellation status, execution timestamps). However, it doesn't mention potential limitations like rate limits, authentication requirements, or error conditions.
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 clear sections: purpose statement, usage scenarios, importance explanation, and example use cases. While slightly verbose, every sentence adds value by clarifying different aspects of when and how to use the tool. The front-loaded purpose statement immediately communicates the core function.
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 status checking tool with 2 parameters and 100% schema coverage, the description provides substantial contextual guidance about usage scenarios and purpose. The main gap is the lack of output schema, but the description compensates by indicating what information will be returned (fill details, execution timestamps, acceptance/cancellation status).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (order_id and client_id) adequately. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.
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 with specific verbs ('check', 'get', 'track') and resource ('detailed status of a specific order'), distinguishing it from siblings like paradex_open_orders (which lists multiple orders) and paradex_orders_history (which shows historical orders). It explicitly focuses on individual order monitoring rather than bulk operations.
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 provides explicit when-to-use guidance with a bulleted list of five specific scenarios (e.g., 'Confirm if a particular order was accepted', 'Diagnose issues with order placement'), plus example use cases. It implicitly distinguishes from siblings by focusing on individual order status rather than account-wide data or order creation/cancellation.
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?
No annotations are provided, so the description carries the full burden. It describes the tool as providing 'essential information' and a 'consolidated view,' implying it's a read-only operation for monitoring, but doesn't explicitly state behavioral traits like whether it requires authentication, has rate limits, or returns real-time vs. cached data. It adds some context about risk management but lacks operational details.
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 appropriately sized and front-loaded, starting with the core purpose, followed by usage guidelines and examples. It avoids redundancy, but the bullet points and example sections are slightly verbose; every sentence earns its place by reinforcing usage contexts, though it could be more streamlined.
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 complexity (monitoring account status) and the presence of an output schema (which covers return values), the description is largely complete. It explains the tool's purpose, usage, and context well, but without annotations, it lacks explicit behavioral disclosures like safety or performance traits, leaving a minor gap.
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%, with the single parameter 'vault_address' well-documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. Since the schema handles the parameter documentation adequately, 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 the tool's purpose as 'Get a comprehensive overview of a vault's trading account status,' specifying the verb 'get' and resource 'vault account summary.' It distinguishes from siblings like paradex_vault_balance or paradex_vault_positions by emphasizing a holistic view including health, margin, exposure, and risk metrics, not just isolated data.
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 five bullet points for when to use this tool (e.g., 'Check account health and available margin,' 'Monitor total exposure and leverage'), and includes example use cases that reinforce these guidelines. It implicitly distinguishes from siblings by focusing on comprehensive status rather than specific components like fills or positions, though it doesn't name alternatives directly.
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?
No annotations are provided, so the description carries full burden. It effectively describes the tool's behavioral purpose (analysis for optimization) and context (essential for larger orders/less liquid markets). However, it lacks details on rate limits, error conditions, authentication requirements, or specific output structure. The description adds value but doesn't fully compensate for the missing annotation coverage.
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 and appropriately sized. It begins with a clear purpose statement, followed by a bulleted list of use cases, explanatory context, and example applications. Every sentence adds value without redundancy. The information is front-loaded with the most critical details first.
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 complexity (market analysis with 2 parameters) and the presence of an output schema (which handles return values), the description provides strong contextual completeness. It thoroughly explains when and why to use the tool, includes practical examples, and covers the analytical context. The main gap is the lack of behavioral details not covered by annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (market_id and depth). The description doesn't add any parameter-specific information beyond what the schema provides. It focuses on the tool's purpose and usage rather than parameter semantics, resulting in the baseline score of 3.
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: 'Analyze market depth and liquidity to optimize order entry and execution.' It specifies the verb ('analyze') and resource ('market depth and liquidity'), and distinguishes it from siblings like paradex_bbo (best bid/offer) or paradex_trades (trade history) by focusing on orderbook analysis rather than simple price data or transaction records.
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 provides explicit guidance on when to use this tool: 'Use this tool when you need to:' followed by four specific scenarios (e.g., 'Assess true liquidity before placing large orders'). It also distinguishes from alternatives by implying this is for pre-trade analysis versus execution tools like paradex_create_order. The 'Example use cases' section further clarifies appropriate contexts.
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?
No annotations are provided, so the description carries the full burden. It effectively communicates that this is a read-only operation for financial data (implied by 'Get a snapshot'), but lacks details on rate limits, authentication requirements, or potential data freshness issues. It adds value by explaining the type of information returned but doesn't fully cover behavioral traits.
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 clear sections (purpose, usage guidelines, example use cases) and front-loaded key information. While slightly verbose, every sentence adds value by clarifying the tool's role and practical applications 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?
Given the tool's complexity (financial summary with no parameters) and lack of annotations/output schema, the description provides comprehensive context about what information is returned and when to use it. It could be more complete by specifying the exact data fields returned, but it adequately covers the essential aspects for informed usage.
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 tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and usage. This meets the baseline of 4 for zero-parameter tools, as no parameter information is needed.
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 with specific verbs ('Get a snapshot') and resources ('account's current financial status and trading capacity'), distinguishing it from siblings like paradex_account_fills or paradex_account_positions by focusing on overall financial health rather than specific transactions or positions.
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 four use cases (e.g., 'Checking available balance before placing new orders') and provides a clear 'Use this tool when you need to' section with bullet points, offering strong guidance on when to use this tool versus alternatives like paradex_account_funding_payments or paradex_account_transactions.
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?
The annotations indicate readOnlyHint=true, which the description aligns with by describing monitoring/checking functions. The description adds valuable behavioral context beyond annotations, such as the tool's role in order management, avoiding duplicate trades, and use cases like checking partial fills or identifying stale orders, though it doesn't specify rate limits or authentication needs.
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 sentence, bulleted usage guidelines, and example use cases. It's appropriately sized for the tool's complexity, though the final paragraph ('Keeping track...') is somewhat redundant with earlier content, slightly reducing efficiency.
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 moderate complexity (3 parameters, read-only operation, no output schema), the description provides good contextual completeness. It explains the tool's purpose, usage, and behavioral context effectively, though it could benefit from mentioning the lack of output schema or typical response format for better agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the three parameters (market_id, limit, offset). The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining how filtering by market_id works in practice or the implications of limit/offset for pagination.
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 as monitoring active orders to track execution status and manage trading strategy. It uses specific verbs like 'monitor', 'track', and 'manage' with the resource 'active orders', and distinguishes itself from siblings like paradex_orders_history (historical orders) and paradex_order_status (single order status).
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 provides explicit usage guidelines with a bulleted list of when to use this tool (e.g., 'Check which of your orders are still pending execution', 'Verify limit order prices and remaining quantities'). It implicitly distinguishes from alternatives by focusing on active orders, unlike paradex_orders_history for historical data or paradex_order_status for individual order details.
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?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it describes the action as 'critical risk management', notes that calling without parameters cancels all orders, explains successful response indicates orders were 'queued for cancellation', and advises to check order status using order ID. It doesn't mention rate limits or authentication needs, but covers essential operational details.
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 appropriately sized and front-loaded, starting with the core purpose and usage guidelines. Some sentences could be more concise (e.g., 'Order cancellation is a critical risk management function...' is slightly redundant with earlier points), but overall it's well-structured with clear sections and minimal waste.
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 complexity (cancellation operation with parameters), no annotations, and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage, behavioral traits, parameter hints, and operational follow-up, providing sufficient context for an agent to use the tool effectively without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some value by implying parameter usage (e.g., 'canceling a specific order identified by order ID' hints at order_id, 'clearing all orders for a specific market' hints at market_id), but doesn't provide explicit syntax or format details beyond what the schema already documents for the three 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 with specific verbs ('cancel pending orders') and resource ('orders'), distinguishing it from siblings like paradex_create_order (which creates orders) and paradex_open_orders (which lists orders). It explicitly mentions managing exposure and adjusting trading strategy, providing clear differentiation.
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 provides explicit guidance on when to use this tool through bullet points (e.g., 'remove stale limit orders', 'quickly reduce market exposure', 'update your order strategy'). It distinguishes from alternatives by implying this is for cancellation versus creation or querying, and includes specific use cases like canceling when outlook changes or during volatility.
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?
With no annotations provided, the description carries full burden. It effectively discloses key behavioral traits: that this is an execution tool (implying write/mutative operations), that successful response means 'orders were queued for execution' (not necessarily filled), and that users should check order status separately. It doesn't mention rate limits, authentication requirements, or error conditions, but provides substantial operational context.
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 and appropriately sized. It begins with a clear purpose statement, follows with usage guidelines in bullet points, provides context about being the primary execution tool, gives concrete example use cases, and ends with important behavioral information about response interpretation. Every sentence earns its place with no wasted words.
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 complex trading execution tool with 9 parameters (7 required) and no annotations or output schema, the description does an excellent job. It covers purpose, usage scenarios, behavioral expectations, and references follow-up actions. The main gap is lack of information about authentication requirements, rate limits, or error handling, which would be valuable for a financial trading 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 description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions 'full control over order type, size, price, and execution parameters' and references 'reduce-only orders' in an example, but doesn't provide additional meaning or clarification beyond what's in the parameter 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 clearly states the tool's purpose as executing trades on Paradex with precise control over order parameters. It specifies the verb 'execute trades' and resource 'Paradex', distinguishing it from sibling tools that focus on account information, market data, or order management rather than order creation.
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 provides explicit guidance on when to use this tool through a bulleted list of specific scenarios (entering new positions, setting limit orders, creating stop-loss/take-profit orders, implementing complex strategies). It distinguishes this as the 'primary tool for executing your trading decisions' and references checking order status with another tool (order_status), though it doesn't explicitly name alternative tools for different 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool retrieves comprehensive market details, explains the 'ALL' default behavior, mentions specific data fields returned (base/quote assets, tick size, minimum order size), and provides guidance on result filtering via JMESPath. It doesn't mention rate limits or authentication requirements, but covers the core operational behavior well.
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 clear sections: purpose statement, usage guidelines, behavioral details, parameter explanations, and examples. While comprehensive, some redundancy exists (e.g., JMESPath explanation appears twice). Most sentences earn their place by providing distinct value, though it could be slightly more concise in the examples section.
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 moderate complexity (4 parameters, no output schema, no annotations), the description provides substantial context. It covers purpose, usage scenarios, behavioral details, parameter semantics, and includes practical examples. The main gap is the lack of output format description, but this is partially compensated by mentioning specific data fields returned. For a read-only query tool, this is quite complete.
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?
With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the practical meaning of parameters: it clarifies that 'market_ids' defaults to 'ALL' for all markets, provides concrete examples of JMESPath usage for filtering/sorting/limiting, and explains the purpose of filtering through use cases. However, it doesn't explain the 'limit' and 'offset' parameters beyond what the schema provides.
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 with specific verbs ('find markets', 'get detailed market specifications') and distinguishes it from siblings by focusing on market discovery and specification retrieval rather than account operations, trading, or system functions. The opening sentence provides a concise summary of the dual functionality.
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 provides explicit guidance on when to use this tool through a bulleted list of specific scenarios (e.g., 'Understand exact tick sizes', 'Find all markets for a specific asset', 'Compare contract specifications'). It also distinguishes use cases from sibling tools by focusing on market research rather than trading execution or account management.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool retrieves current market summaries, explains the default behavior when 'ALL' or no market IDs are specified, and details JMESPath filtering capabilities. However, it doesn't mention rate limits, authentication requirements, or data freshness, leaving some gaps.
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 clear sections (purpose, usage guidelines, retrieval behavior, examples, JMESPath instructions). While slightly lengthy, every sentence adds value—no redundant information. It could be more front-loaded by moving key behavioral details earlier, but overall it's efficiently organized.
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 4 parameters, 100% schema coverage, no output schema, and no annotations, the description does an excellent job of compensating. It explains what the tool returns (market metrics), provides usage context, and includes practical examples. The main gap is the lack of output format details, but for a summary retrieval tool, this is reasonably complete.
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 schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the semantic meaning of parameters: it clarifies that 'ALL' returns all markets, provides concrete JMESPath examples for filtering/sorting, and contextualizes parameters within use cases like limiting results for analysis. This goes beyond the schema's technical 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 clearly states the tool's purpose with specific verbs ('identify', 'get current market conditions') and resources ('markets'), distinguishing it from siblings like paradex_markets (likely listing) or paradex_trades (transaction data). It explicitly mentions retrieving market summary information including price, volume, and 24h change.
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 provides explicit guidance on when to use this tool through bullet points (e.g., 'Find the most active markets by volume', 'Discover markets with significant price movements') and example use cases (e.g., 'Finding high-volatility markets for short-term trading'). It distinguishes usage from potential alternatives by focusing on summary metrics rather than detailed data.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates this is a read-only analysis tool (implied by 'analyze', 'monitor', 'check') that provides position data for risk management and trading decisions. However, it doesn't mention potential limitations like data freshness, rate limits, or authentication requirements, leaving some behavioral aspects unspecified.
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 and front-loaded with the core purpose in the first sentence. Each subsequent section (usage scenarios, fundamental importance, example use cases) adds specific value without redundancy. The bullet points and clear organization make it efficient to parse while maintaining comprehensive coverage.
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 parameters and no output schema, the description provides excellent contextual completeness by explaining what the tool does, when to use it, and providing concrete examples. The only minor gap is the lack of information about return format or data structure, which would be helpful since there's no output schema, but the description otherwise covers the essential context thoroughly.
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 tool has zero parameters with 100% schema description coverage, so the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and usage context, which adds value beyond the empty 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's purpose with specific verbs ('analyze', 'monitor', 'assess') and resources ('open positions'), and distinguishes it from siblings by focusing on position analysis rather than fills, funding, orders, or other account aspects. The opening sentence 'Analyze your open positions to monitor exposure, profitability, and risk' provides immediate clarity.
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 four bullet points detailing when to use this tool ('Check the status and P&L', 'Monitor liquidation prices', 'Assess exposure', 'Make decisions about position management'), and includes example use cases that reinforce these scenarios. It clearly differentiates this from tools like paradex_account_fills or paradex_open_orders by focusing on position analysis rather than transaction history or order management.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (monitoring/read-only operations) and provides rich context about the type of information returned (unrealized P&L, liquidation prices, margin requirements, entry prices, position duration). However, it doesn't mention potential limitations like rate limits or authentication requirements.
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 clear sections (purpose, usage scenarios, rationale, examples) and efficiently communicates essential information. While slightly longer than minimal, every sentence adds value by clarifying use cases and context. The information is front-loaded with the core purpose stated first.
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 complexity (position monitoring in a trading system), the description provides comprehensive context about what information is returned and how it should be used. With an output schema present, the description appropriately focuses on usage scenarios rather than return value details. The description adequately compensates for the lack of annotations.
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% for the single parameter 'vault_address', so the schema already documents it adequately. The description doesn't add specific parameter semantics beyond what's in the schema, but with only one parameter and high schema coverage, this is acceptable. The description provides context about what 'vault' means in this trading system.
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 as 'Monitor active trading positions to track performance and manage risk' with specific verbs ('monitor', 'track', 'manage') and resource ('trading positions'). It distinguishes from sibling tools like 'paradex_account_positions' by focusing specifically on vault positions rather than general account positions.
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 provides explicit usage scenarios with a bulleted list of when to use this tool ('Get a complete view of all open positions for a vault', 'Monitor unrealized P&L', etc.) and includes example use cases that reinforce appropriate contexts. It implicitly distinguishes from sibling tools by focusing on vault-specific position monitoring.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's purpose as a read-only status check (implied by 'verify' and 'check'), highlights its importance for safety before trades, and mentions context like maintenance periods and clock sync. However, it doesn't specify rate limits, authentication needs, or exact response format, leaving some behavioral aspects uncovered.
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 and front-loaded with a clear purpose statement, followed by bullet points and examples. Every sentence adds value by elaborating on usage scenarios without redundancy. It efficiently conveys necessary information in a compact format.
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 (0 parameters, no annotations, but with an output schema), the description is complete. It explains the tool's purpose, usage guidelines, and importance in trading contexts. The output schema will handle return values, so the description doesn't need to detail them, making it sufficiently comprehensive for this low-complexity 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter-specific information, which is appropriate here. A baseline of 4 is applied for zero-parameter tools, as no additional semantic value is needed beyond the schema's completeness.
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 as verifying exchange operational status before trades, using specific verbs like 'verify' and 'check' with the resource 'exchange' or 'system status'. It distinguishes from sibling tools (e.g., trading or account tools) by focusing on system health rather than market data or account actions.
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 provides explicit guidance on when to use this tool: before executing important orders, when encountering unexpected behavior, to check maintenance periods, and for clock synchronization. It includes specific use cases (e.g., before trading strategies, during market volatility) and implies alternatives by suggesting it for diagnosing API issues when other calls fail.
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/Habinar/mcp-paradex-py/badges/card.svg)](https://glama.ai/mcp/servers/Habinar/mcp-paradex-py)

Score Badge

Copy to your README.md:

[![mcp-paradex-py MCP server](https://glama.ai/mcp/servers/Habinar/mcp-paradex-py/badges/score.svg)](https://glama.ai/mcp/servers/Habinar/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/Habinar/mcp-paradex-py'

If you have feedback or need assistance with the MCP directory API, please join our Discord server