Fortunest demo

Recent trades

recent_trades

Read-onlyIdempotent

DEMO portfolio (synthetic, shared, read-only). Read the user's OWN executed buys and sells — trade history, never recommendations; the rows of the Trades tab's Recent trades card. since is a number of days back (1-3650, default 90); symbol and side (buy or sell) filter; limit is 1-100 (default 20) with offset/nextOffset, newest first. Each item carries date, side, symbol, name, qty, the account it was filed from and amountEur — the trade's cash value in the display currency at its own trade date, fees included where the broker reports them; a row with no derivable display-currency amount carries nativeAmount plus nativeCurrency (price×qty in the trade's own currency) instead. Transfers between the user's own accounts, ledger corrections, staking credits, in-kind fees and corporate actions are not trades and are never listed — the same rows as the Trades tab's Recent trades card. servedFrom says whether the rows came from the chat context's own trade window ('context') or from the full history ('engine'), and window says which stretch was actually read. detail=true reads the card's own table instead (servedFrom 'engine') and adds its other columns to every row: price (the execution price, in priceCurrency, the trade's own currency), fee (the broker-reported fee in the display currency, only when there was one) and changePct (the Since trade column: how the asset's price moved from this execution to today in its own listing currency, split-adjusted, as a FRACTION — 0.25 = +25%; on a sale, what the sold units did since; absent without a current price), plus cardTotal, the count of every trade the card lists (its 'N of M'). The card's sort and filters imply detail: sort (a column; change = Since trade) with order, query (name/ticker terms), type (asset type, e.g. 'ETF funds') and from/to (ISO days; either replaces since). Each '…Eur' field now also ships under its currency-neutral name (amountEur→amount, buyEur→buy, valueEur→value, totalEur→totalAmount); the '…Eur' twins are DEPRECATED and will be removed — read the neutral name.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description	Default
`to`	No
`from`	No
`side`	No
`sort`	No
`type`	No
`limit`	No
`order`	No
`query`	No
`since`	No
`detail`	No
`offset`	No
`symbol`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context they cannot: the demo/synthetic shared-portfolio nature, the exclusion list (transfers, ledger corrections, staking credits, in-kind fees, corporate actions), fee inclusion caveats, the amountEur vs. nativeAmount fallback, and deprecated field twins. It stops short of stating rate limits or error behavior, so not a 5.

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 purpose and paging rules are front-loaded, and most sentences carry real information, but the text is a dense ~300-word block with clear duplication — 'the same rows as the Trades tab's Recent trades card' is stated twice, and the deprecated-field migration note plus the detail-column enumeration are verbose. Readable but not tight.

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?

There is no output schema, so the description must carry return semantics — and it does: item fields (date, side, symbol, name, qty, account, amountEur), currency caveats, servedFrom/window provenance, detail-mode extras (price, fee, changePct semantics as a fraction, cardTotal meaning), and the 'N of M' interpretation. For a 12-parameter read tool, nothing an agent needs to call and interpret it correctly is missing.

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

Parameters5/5

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

With 0% schema description coverage, the description compensates fully: it supplies defaults the schema lacks (since default 90 days, limit default 20), semantics for since ('number of days back') and from/to ('ISO days; either replaces since'), filtering behavior for symbol/side/query/type, sort/order semantics including 'change = Since trade', and offset/nextOffset paging with 'newest first'. Nearly every one of the 12 parameters gains meaning beyond its type/enum.

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?

States a specific verb and resource — 'Read the user's OWN executed buys and sells — trade history' — and anchors it to a concrete UI artifact ('the rows of the Trades tab's Recent trades card'). It also explicitly negates a lookalike category ('never recommendations'), so an agent can distinguish it from planning/candidate tools without opening schemas.

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?

Gives clear when-to-use context (trade history vs. recommendations) and an explicit mode switch: 'detail=true reads the card's own table instead', plus 'The card's sort and filters imply detail'. It does not name a specific sibling to use for the recommendation case, so routing guidance is strong but not exhaustively comparative.

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

All Fortunest demo 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.