Fortunest demo

Portfolio overview

get_core

Read-onlyIdempotent

DEMO portfolio (synthetic, shared, read-only). Read the whole portfolio as one small digest (at most 16 000 characters, about 4 000 tokens) instead of the enormous get_context union: asOf, the value/cash/day-change/P-L totals with the per-account split, time-weighted and money-weighted performance, the six risk headlines (max drawdown, current drawdown, volatility p.a., Sharpe, Sortino, worst day), the ten largest holdings by weight with weight, value, day change and total gain, the asset-class and sector allocation with target drift where targets are set, the trade plan's buy/sell/net totals and order counts, the next five calendar events, the data-quality warning counts by kind, the strategy profile, the central-bank policy rates with the risk regime, the user's own trades of the context window (newest first), the subscription tier and its limits, and the user's saved memories and standing notes in full. include ⊆ [memories, notes] LISTS WHICH of the two optional blocks to keep — both when it is omitted, only the ones named when it is given, and neither for include: []. Every amount is in displayCurrency and every field ending in Pct is a percentage. Start here, then call a focused view for the detail; trimmed names any list that had to be shortened to fit.

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_core"
  }
}

Input Schema

Name	Required	Description	Default
`include`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare the safe read-only/idempotent profile, and the description adds substantial context beyond them: the digest is capped at ~16,000 characters (~4,000 tokens), the data is synthetic/shared/demo, amounts are in displayCurrency, Pct fields are percentages, and lists may be shortened ('trimmed'). That last detail is important because it warns the agent output can be lossy.

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?

The key instruction is front-loaded — digest instead of get_context — and the long content enumeration is genuinely useful for judging whether the digest obviates focused calls. It is still a single sprawling sentence, which makes it harder to scan than a short bulleted listing would be.

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 describe the return payload, and it does so exhaustively (totals, performance, risk headlines, top holdings, allocations, trade plan, calendar, warnings, rates, trades, tier, memories/notes). An agent knows what to expect without a trial call.

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 0% schema coverage the description must carry the parameter, and it does explain default (both blocks kept when omitted) and empty-array semantics. However, it states include is a subset of only [memories, notes], while the schema enum actually allows five values (memories, notes, strategy, macro, recentTrades) — a misleading narrowing of the documented value domain.

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 whole portfolio as one small digest') and explicitly contrasts itself with the sibling get_context union it replaces. The enumerated contents make it unmistakable what this tool returns versus the focused views.

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?

'Start here, then call a focused view for the detail' gives a clear entry-point directive and the escalation path. It stops short of naming which focused view to use for which need, leaving that inference to the sibling names.

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.