Fortunest demo

One holding

holding

Read-onlyIdempotent

DEMO portfolio (synthetic, shared, read-only). Read ONE position in depth — the asset drawer, as data. Give symbol, or symbols for SEVERAL positions in one call (up to 25; the two are mutually exclusive and one of them is required). A batch answers {batch: true, symbols, results keyed by ticker, missing, truncated} — never call this once per ticker when you already know the list. The symbol may be held or merely on the watchlist. include picks the blocks: fundamentals (valuation, growth, fair value, analyst view), lots (open and tax-free quantity, next maturity), news (the cached recent headlines), insider (the 3-month Form 4 digest), events (its upcoming earnings/dividend dates), correlations (which holdings it moves with), warnings (the data-quality sentences naming it) and priceHistory, whose window is the separate range argument (1m, 3m, 6m, 1y, ytd, max — default 3m) and which comes back downsampled to at most 120 points, and description (the drawer's two-sentence profile of what the company does, where it is headquartered and where it operates, with its provenance: yahoo for the market-data feed, ai when a fast AI model wrote it — the app's own, or this user's own provider — facts when the app composed it from the listing's own data), and checks (strengths & things to watch, as sourced facts). With no include the position line alone comes back. A position under 0.1% of the portfolio answers grouped=true: held, with its position line (value, weight) when the summary has it, and no lot data. Blocks that did not fit the result budget are listed in dropped (ask for them singly), and an unknown symbol answers ok=false with the closest symbols the user actually holds or watches, never an invented position.

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

Input Schema

Name	Required	Description
`range`	No
`symbol`	No
`include`	No
`symbols`	No	Several tickers in ONE call — up to 25. Send this instead of calling once per ticker; `symbol` and `symbols` are mutually exclusive. The answer is keyed by symbol under `results`, with `missing` naming the ones that had no data.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Well beyond the readOnly/idempotent annotations, it discloses the result-budget behavior (dropped blocks, ask singly), truncated batches, grouped=true for sub-0.1% positions with no lot data, 120-point downsampling, and the ok=false plus closest-symbol fallback for unknown tickers.

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 purpose and alternatives, and nearly every clause carries operational information; however the middle section is one very dense paragraph enumerating ten blocks, which taxes readability despite the value delivered.

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?

With no output schema, the description still documents the return shapes (batch envelope, results keyed by ticker, missing, truncated, dropped, grouped, ok=false), which is everything an agent needs to call and interpret this four-parameter but behaviorally rich tool.

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 only 25% (just `symbols`), yet the description defines every include block (fundamentals, lots, news, insider, events, correlations, warnings, priceHistory, description with its provenance variants, checks), the range window with its 3m default, and the symbol/symbols exclusivity that the schema's empty required list does not convey.

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 ONE position in depth — the asset drawer, as data') and immediately clarifies the batch variant, so an agent can tell this apart from a portfolio-level listing tool without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit routing rules: 'never call this once per ticker when you already know the list', explains that symbol and symbols are mutually exclusive and one is required, and notes include selects blocks while no include returns only the position line.

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.