EventTrader Research (read-only)

Theme Journey Ranked Setups

theme_journey_ranked_setups

Read-onlyIdempotent

The MEASURED ranked list of trade setups of every kind — arbitrage venue pairs, event cards by thesis side, fund tokens, single vehicles, theme baskets — for the user's amount, target and horizon, net of round-trip costs. Every row: risk_tier 1-5 (risk_label; the worst measured move of the setup itself), net probable return and its lower bound, p_target (share of measured moves that covered the target), the size for a 1% risk budget, and the TIME-TO-TARGET — measured first passage for series-backed rows (ttt_share of start days that got there, ttt_median_days, ttt_fastest_days) or the compounding count (ttt_steps) for arbitrage and cards. fastest names the most repeatable measured path to the target (share of start days that got there, then median days), or says none got there. order = risk (lowest risk first), time (fastest first) or rank (risk-budgeted lower bound). Use these numbers when asked for setups, a risk ranking, how long a target takes, or which vehicles to combine — never a free-hand list. Read-only; past measurements, never a forecast or a promise. (no key needed)

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

Input Schema

Name	Required	Description
`limit`	No	rows returned (default 15)
`order`	No	list order (default risk)
`target_pct`	No	the target in percent (e.g. 20 for $1,000 → $1,200)
`usdc_amount`	No	the stake the user named (sizes every row)
`horizon_days`	No	hold length in days (default 7)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive, so the description earns credit for adding context beyond them: costs are net of round-trip, values are past measurements and never a forecast or promise, and no API key is needed. It does not discuss row caps beyond the limit default or behavior when no setup reaches the target beyond the `fastest` fallback.

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 core purpose and the row contents before the ordering and usage guidance, and nearly every clause carries substantive information about returned fields. It is dense and long, with a heavy backtick field inventory that could be trimmed, but nothing is genuinely redundant.

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 carries the burden of explaining return values and does so thoroughly: risk_tier with risk_label, net probable return and lower bound, p_target, 1% risk-budget size, and time-to-target via first passage or compounding steps. An agent has enough to call it and interpret the result without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains what each `order` value produces (risk = lowest risk first, time = fastest first, rank = risk-budgeted lower bound) and how amount, target and horizon size every row. That goes beyond the schema's terse enum and field descriptions.

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 — a measured, ranked list of trade setups across venue pairs, event cards, fund tokens, single vehicles and theme baskets — scoped to the user's amount, target and horizon and net of round-trip costs. It is clearly distinguishable from siblings like theme_journey_top_vehicles or find_trade_path because it is explicitly the ranked-setup list with per-row measured fields.

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 explicit trigger conditions: use when asked for setups, a risk ranking, how long a target takes, or which vehicles to combine, and explicitly forbids free-hand lists. It does not name a specific alternative sibling to use instead for adjacent needs (e.g. routing or basket construction), so it falls short of full when-not/alternatives guidance.

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

All EventTrader Research (read-only) 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.

Resources

Need Help?