dydx-agent-gateway

Overview Schema Source Related Servers Discussions Admin

Recent Trades

recent_trades

Read-only

Retrieve the most recent public trades for any market, showing price, side, size, type, and time, with newest trades first and a configurable limit up to 100.

Instructions

Latest public trades of a market (price, side, size, type, time). Newest first; limit capped at 100. side is BUY/SELL, size in base coin. Example: recent_trades(ticker="BTC-USD", limit=30)

Tool call template

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

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "recent_trades"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`ticker`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds useful behavioral details: results are newest-first, limit is capped at 100, side values are BUY/SELL, and size is in base coin. This gives the agent expectations about ordering and data semantics.

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 compact and information-dense: scope, fields, ordering, cap, units, enum values, and an invocation example in three short sentences. Every sentence contributes value, and the most important facts are front-loaded.

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 simple listing tool, the description covers the key invocation details: what is returned, ordering, limit behavior, side/size semantics, and an example call. It does not define the 'type' field or the full return structure, but annotations and schema already cover safety and parameters, so nothing blocks invocation.

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 0%, so the description must compensate for parameter meaning. It partially does via the example and the limit cap, but it does not explicitly explain the ticker format or the limit default beyond what the schema shows. The example provides minimal but usable semantics.

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 identifies the tool as returning the latest public trades of a market, lists the returned fields, and states ordering and limit behavior. This is specific enough to distinguish it from sibling tools like candles or historical_funding without ambiguity.

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 phrase 'Latest public trades of a market' establishes a clear use case: retrieving recent trade-level activity. It does not explicitly name alternatives or when-not-to-use conditions, but the context is clear enough that an agent would know when to select it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.