Fortunest demo

Trade plan

get_trade_plan

Read-onlyIdempotent

DEMO portfolio (synthetic, shared, read-only). Read the Trade plan card: suggested orders, their company ratings and decision reasons, buy/sell/net/leftover amounts, constraints and sellLotCoverage. Each order's amountEur is the card's Amount, sharePct its Share (percent of that side's budget), rating its Rating (0-100, 50 neutral, null for funds/crypto) and, on sells, taxFreeValueEur/nextMaturity its Tax-free now column; the card's Run historical backtest button opens the historical simulation the backtest_trades tool runs. tradePlanning carries saved controls; planning describes the result. Invest is new money; sales are independent and their proceeds stay cash. Every amount uses displayCurrency; the Eur suffix is legacy. 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. include:['candidates'] adds ranked candidates with inclusion, exclusion or cap reasons; ['taxOrientation'] adds tax lots. Funds/crypto have no company rating. No orders are placed. Default notes are brief; docs carries docs_lookup labels for the simplified planner, verbose:true includes full notes. unavailableReason explains a missing plan. symbols {buys, sells} lists the plan's tickers, ready to pass as symbols to holding, market_lookup, price_on or trade_candidates in ONE call. Each sell order carries taxFreeValueEur/taxFreeQty (the whole position's tax-free capacity today) beside taxFreeEur (the exempt slice of that one order), and nextMaturity {date, qty, valueEur} — the earliest still-future time-test date for that holding, what to report when taxFreeValueEur is 0 ('nothing is tax-free today; the next lot matures on …'); null where no open lot has a maturity date at all. The same orders and contextRevision are in get_context portfolio.tradePlan.

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": "get_trade_plan"
  }
}

Input Schema

Name	Required	Description	Default
`include`	No
`verbose`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, but the description adds real behavioral context beyond them: it is a synthetic shared DEMO portfolio, no orders are placed, unavailableReason explains a missing plan, and several fields are deprecated and slated for removal. That is meaningful disclosure an agent would not get from the structured fields alone.

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 description is front-loaded with purpose, but it degrades into a dense series of semicolon-joined clauses mixing field mappings, deprecation policy, and tax-lot semantics. Much of the field detail is defensible because no output schema exists, but the deprecation parenthetical (amountEur→amount, buyEur→buy, …) and repeated restatements of the same tax-free fields add avoidable bulk.

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?

With no output schema and only two parameters, the description carries the return-value burden and does so thoroughly: field-by-field meaning, currency handling (displayCurrency vs legacy Eur suffix), the taxFreeValueEur/nextMaturity relationship with a sample message, and unavailableReason for absent plans. Only the unexplained 'bothSides' include value and default include behavior leave a gap.

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?

With two parameters and zero schema description coverage, the description must compensate, and it only partly does: 'include:[candidates]' and 'include:[taxOrientation]' are explained with what they add, and 'verbose:true includes full notes' is clarified. The third enum value, 'bothSides', is never explained, and there is no guidance on default behavior when include is omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Read the Trade plan card', then enumerates the card's contents (suggested orders, ratings, decision reasons, buy/sell/net/leftover amounts, constraints, sellLotCoverage). It is distinguishable from siblings like trade_candidates and tax_lots because it names the concrete artifacts it returns, though the core purpose is buried under a very long sentence chain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the description notes the backtest button maps to backtest_trades, and that identical orders also live in get_context portfolio.tradePlan, and that the returned symbols can be passed to holding, market_lookup, price_on or trade_candidates in one call. However, it never says explicitly when to call this versus those alternatives, and no exclusions or prerequisites are given.

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.