Skip to main content
Glama
Sign In

Analyzera

by com.analyzera
OverviewDiscussionsAdmin

Preview a strategy in an account

preview_scenario
Read-onlyIdempotent

Measure an account as it is and with a strategy added, without writing anything.

Answers which way the client's position would move if they bought a strategy,
and by how much. The account is measured twice through the Risk tab's own pane.

Pass ``strategy_id`` + ``amount``, or ``changes`` for several signed changes at
once (a switch is a negative amount on an account plus an equal positive one;
an account cannot be reduced below what it holds). A change with ``asset_id``
is one instrument: "sell 20,000 of Volvo in the ISK and buy Investor" is
``{id: ISK, asset_id: Volvo, amount: -20000}`` plus
``{asset_id: Investor, amount: 20000}`` with ``account_id: ISK``; for a switch
between instruments that names one account, that account is the default.
Otherwise ``account_id`` defaults to
everything the client holds, or everything one client holds with ``person_id``.
An empty account is valid: the before side is empty.

Nothing is written: no account, holding or node is created. There is no track
record for a scenario and the returns tab is unavailable for it. The result is
a measurement, not a suitability judgement; the client's own limits are not read.

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

Input Schema

NameRequiredDescriptionDefault
amountNo
changesNo
person_idNoThe id of one person, family or entity this login holds. Omit for everything this login holds.
account_idNo
strategy_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description explains that nothing is written, no account/holding/node is created, no track record exists, the returns tab is unavailable, and client limits are not read. It also explains that the account is measured twice through the Risk tab pane and that an empty account is valid.

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 core purpose is front-loaded and most sentences add useful information. It is somewhat dense and repeats the no-write guarantee at both the beginning and end, but the length is largely justified by the complexity of the change grammar.

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?

For a complex, non-writing analytics tool with no output schema, the description is complete enough: it explains what is measured, how the before/after comparison works, what is not done, and how to express changes. An agent has enough information to invoke it correctly and interpret the result qualitatively.

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 description coverage is only 20%, but the description compensates thoroughly: it explains strategy_id + amount versus changes, signed amounts, switch semantics, asset_id for single instruments, account_id defaulting, and person_id scoping. This goes well beyond the bare schema and is essential for constructing valid nested change objects.

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 states a specific verb and resource: measure an account before and after adding a strategy without writing anything. It clearly conveys the what-if purpose and distinguishes previewing from making changes, but does not explicitly name sibling tools such as run_strategy_backtest or save_simulation.

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?

It gives clear usage context: pass strategy_id + amount or changes, explains switch mechanics, and notes exclusions such as no track record and no suitability judgement. Alternatives are not named explicitly, but the boundary between preview and actual assignment or saved simulation is strongly implied.

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

All Analyzera toolsInspect
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.

Resources