Trandence Trading Journal

List trades

get_trades

Individual trades, newest first, filtered the way the Trades page filters them: date range, ticker, playbooks and tags. Returns 20 rows unless you raise limit (max 50), plus totals computed over every trade that matched — use those for "how did my trades tagged X / on playbook Y do" instead of adding rows up. total is how many trades matched. Fields with no recorded value are omitted. Rows are executions: several trades in one symbol on one day belong to a single setup, reviewed as a whole in get_symbol_reviews.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No
`symbol`	No	Ticker, e.g. TSLA. Matches tickers containing it, as the Trades page does
`tagIds`	No	Tag ids from list_tags
`endDate`	No	Inclusive end date (YYYY-MM-DD)
`assetType`	No	Only stock trades or only option trades — the Stocks / Options switch in the app. Omit for both.
`dateField`	No	Which timestamp the date range applies to: executedAt (default) or openDate
`startDate`	No	Inclusive start date (YYYY-MM-DD)
`playbookIds`	No	Playbook ids from list_playbooks; "__unassigned__" selects trades with no playbook. A trade matches if it is on any of them.
`tagFilterMode`	No	ANY (default): the trade carries at least one of tagIds. ALL: every one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 19, 2026

addedInput schema / properties / assetType

Added value: +{
+  "description": "Only stock trades or only option trades — the Stocks / Options switch in the app. Omit for both.",
+  "enum": [
+    "STOCK",
+    "OPTION"
+  ],
+  "type": "string"
+}

First observedSep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses default page size (20), max limit (50), ordering, totals computed over all matching trades, omission of fields with no value, and that rows represent executions rather than setups. This is far beyond a minimal 'List trades' statement.

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 four dense sentences with zero filler. It front-loads the core operation and ordering, then efficiently covers pagination, totals, field omission, and row granularity without repeating schema content.

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?

For a 9-parameter list tool with no output schema and no annotations, this description is remarkably complete. It covers purpose, filter semantics, pagination, aggregate totals, missing-value behavior, row granularity, and names the related review tool. Row-level field names and empty-result behavior are secondary for tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents most parameters with 89% coverage, so the baseline is 3. The description adds meaningful parameter-related context by stating the default `limit` of 20 and max of 50, and by framing the filters as matching the Trades page behavior.

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 opens with 'Individual trades, newest first', giving a specific verb, resource, and ordering. It clearly distinguishes this from get_symbol_reviews by explaining that rows are executions and that multiple trades in one symbol/day belong to a single setup reviewed elsewhere.

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?

It explicitly routes aggregate performance questions to the returned `totals` rather than summing rows, and points to get_symbol_reviews for setup-level review. It doesn't exhaustively compare against all sibling analytics tools, but it provides clear contextual guidance for the main alternatives.

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

All Trandence Trading Journal tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?