Fortunest demo

Money flow

money_flow

Read-onlyIdempotent

DEMO portfolio (synthetic, shared, read-only). Read the Trades tab's Money flow card: the cash spent on purchases and raised by sales per week, month or year, from the same rows as the Recent trades card. period is 'week' (ISO weeks, Monday start), 'month' (calendar months, the default) or 'year' (calendar years, the current one to date); count is how many periods back, up to and including the current one (1-260; default 26 weeks, 24 months or 10 years, the card's own). Each item is one period, newest first: start (the period's first day), purchases (the card's Purchases bar) and sales (its Sales bar) — the display-currency cash at each trade's own date, fees included where the broker reports them — net = sales − purchases (the Net line: positive when the period sold more than it bought), buys, sells and trades (execution counts) and unpriced (trades with no derivable amount: counted, never summed). A period without trades is zeros, not a gap. totals sums the whole window; limit/offset page the periods (nextOffset). Transfers, corrections, staking credits, in-kind fees and corporate actions are not trades and never counted.

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

Input Schema

Name	Required	Description	Default
`count`	No
`limit`	No
`offset`	No
`period`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent, but the description adds substantive context: a synthetic demo portfolio, fees included only where the broker reports them, unpriced trades counted but never summed, empty periods returned as zeros rather than gaps, and explicit exclusion of transfers, corrections, staking credits and corporate actions. These are exactly the behaviors an agent could not infer from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the portfolio qualifier and the resource being read, then organized with semicolons by topic (period, count, output fields, paging, exclusions). It is a dense single block, and the long output-field enumeration could be tightened, but almost every clause carries information an agent needs.

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, and the description compensates by enumerating the returned fields (start, purchases, sales, net, buys, sells, trades, unpriced, totals, nextOffset) and their sign conventions. Combined with the zero-period and unpriced handling rules, an agent has everything needed to call this correctly.

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?

Schema coverage is 0%, so the description must carry the load and it does: period is defined term-by-term with what each unit means and which is the default, count is bounded (1-260) with per-period defaults, and limit/offset are identified as paging with nextOffset returned. Only minor gap is that limit's default and maximum aren't stated, but all four parameters are given real meaning.

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?

Names a specific action and resource: reading the Trades tab's Money flow card, showing cash spent on purchases and raised by sales per period. It also anchors the data source ('the same rows as the Recent trades card'), so an agent can distinguish it from the sibling recent_trades tool without opening either schema.

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 strong usage context: period semantics (ISO weeks/Monday start, calendar months default, calendar years to date), the meaning of count and its per-period defaults. It differentiates implicitly from the trade-level sibling by framing the output as per-period aggregation, but never explicitly says 'use recent_trades for individual executions' or states exclusions.

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.