strata_tradesRetrieve recent anonymized market prints for a specific opaque market ID, including price, size, side, and time, to monitor live trading activity.
Read recent anonymized prints for one opaque market ID: price, size, side, and time.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most recent prints to return (default server limit; max 500). | |
| marketId | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. The description adds 'anonymized' prints and specifies the data fields (price, size, side, time), providing behavioral details beyond the annotations about the nature of the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the verb (read), the resource (recent anonymized prints), the qualifier (for one opaque market ID), and the output contents (price, size, side, time). No redundant or extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description sufficiently conveys what the tool does and what returns, but omits details like default limit, pagination, or potential error cases. However, given the lack of an output schema and the simple nature of the operation, it covers the essential aspects adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers `limit` with a description, but `marketId` has no description beyond the pattern. The tool description adds 'one opaque market ID', clarifying that marketId is a hash-like identifier, but doesn't explain how to obtain or interpret it. With 50% schema coverage, the description provides minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads recent anonymized prints, identifies the target resource (a market ID), and lists the return fields (price, size, side, time). This distinguishes it from sibling tools like strata_candles or strata_bbo by its specific focus on trade prints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent anonymous trades for a specific market, but does not explicitly contrast with alternatives or state when not to use it. It provides no direct comparison to sibling tools, leaving the agent to infer the scope from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.