Skip to main content
Glama
Habinar

MCP Paradex Server

by Habinar

paradex_account_transactions

Retrieve filtered transaction history for account reconciliation, auditing trades, and tracking deposits, withdrawals, and funding payments over time.

Instructions

Get account transaction history.

Retrieves a filtered history of account transactions, including deposits,
withdrawals, trades, funding payments, and other account activities.
Use transaction_type and time filters to limit the results and avoid
overwhelming the client.

This tool is valuable for:
- Reconciliation of account activity
- Auditing trading history
- Tracking deposits and withdrawals
- Analyzing funding payments over time

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
transaction_typeNoFilter by transaction type.
start_unix_msYesStart time in unix milliseconds.
end_unix_msYesEnd time in unix milliseconds.
limitNoMaximum number of transactions to return.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The primary handler function for the 'paradex_account_transactions' tool. It authenticates a Paradex client, fetches transactions with given filters, validates them using Pydantic, and returns a structured result including schema and data.
    @server.tool(name="paradex_account_transactions")
    async def get_account_transactions(
        transaction_type: Annotated[
            str | None, Field(default=None, description="Filter by transaction type.")
        ],
        start_unix_ms: Annotated[int, Field(description="Start time in unix milliseconds.")],
        end_unix_ms: Annotated[int, Field(description="End time in unix milliseconds.")],
        limit: Annotated[
            int, Field(default=50, description="Maximum number of transactions to return.")
        ],
        ctx: Context = None,
    ) -> list[Transaction]:
        """
        Get account transaction history.
    
        Retrieves a filtered history of account transactions, including deposits,
        withdrawals, trades, funding payments, and other account activities.
        Use transaction_type and time filters to limit the results and avoid
        overwhelming the client.
    
        This tool is valuable for:
        - Reconciliation of account activity
        - Auditing trading history
        - Tracking deposits and withdrawals
        - Analyzing funding payments over time
    
        """
        client = await get_authenticated_paradex_client()
        params = {
            "type": transaction_type,
            "start_at": start_unix_ms,
            "end_at": end_unix_ms,
            "limit": limit,
        }
        # Remove None values from params
        params = {k: v for k, v in params.items() if v is not None}
        response = client.fetch_transactions(params)
        if "error" in response:
            await ctx.error(response)
            raise Exception(response["error"])
        transactions = transaction_adapter.validate_python(response["results"])
        results = {
            "description": Transaction.__doc__.strip() if Transaction.__doc__ else None,
            "fields": Transaction.model_json_schema(),
            "results": transactions,
        }
        return results
  • Pydantic model 'Transaction' defining the structure and validation for individual transaction objects returned by the tool.
    class Transaction(BaseModel):
        """Transaction model representing an account transaction on Paradex."""
    
        id: Annotated[
            str, Field(description="Unique string ID of the event that triggered the transaction")
        ]
        type: Annotated[str, Field(description="Event that triggered the transaction")]
        hash: Annotated[str, Field(description="Tx Hash of the settled trade")]
        state: Annotated[str, Field(description="Status of the transaction on Starknet")]
        created_at: Annotated[
            int, Field(description="Timestamp from when the transaction was sent to blockchain gateway")
        ]
        completed_at: Annotated[
            int, Field(description="Timestamp from when the transaction was completed")
        ]
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.

Install Server

Other Tools

Latest Blog Posts

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