trading-signals-mcp

AI Trade Brief

ai_trade_brief

Read-only

Short structured pre-trade brief for ES/NQ/CL/GC/ZN written by an LLM strictly from the toolkit's own data (event-risk gate, session brief with US macro calendar, Treasury yields and CFTC positioning, SEC insider clusters, and the macro event study for the next high-impact release): headline, bias (bullish/bearish/neutral/stand_aside), confidence, summary, key levels, risks, catalysts with ET times, trade-plan notes, a deterministic GO/CAUTION/NO_GO tradeability, and the input facts. A NO_GO check always forces stand_aside. Not investment advice. If the AI upstream is unavailable the call fails before payment settles (not charged). Uses 20 units of a plan key's monthly quota; anonymous use is limited to 1 per day. Works with no key (small daily allowance) or with a Trading Signals Toolkit API key (free 100 calls/month, Starter, Pro). Pay-per-call equivalent: $0.08 USDC over x402. Informational only, not investment advice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "ai_trade_brief"
  }
}

Input Schema

Name	Required	Description
`price`	No	Optional current futures price, so typical moves and stops can be expressed as levels
`symbol`	Yes	Futures root: ES (E-mini S&P 500), NQ (E-mini Nasdaq-100), CL (WTI crude), GC (gold), ZN (10-year T-note)
`window`	No	Look-ahead window in minutes (1-240, default 30)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly=true, openWorld=true, non-idempotent and non-destructive, but the description adds substantial context beyond them: LLM authorship, a deterministic NO_GO gate that forces stand_aside, quota burn of 20 units, anonymous rate limit, auth tiers, $0.08 x402 price, and the no-charge guarantee when the upstream AI fails. The disclaimers are repeated, but the behavioral disclosure itself (cost, limits, failure semantics) is genuinely useful.

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

Conciseness3/5

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

The output-field list is front-loaded and useful, but the single run-on paragraph crams output schema, quota, auth tiers, pricing, and disclaimers together. 'Not investment advice' / 'Informational only, not investment advice' is stated twice with no added information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 carry the return shape, and it does by enumerating every field including the input facts and the deterministic tradeability. Cost, auth, rate limits, and failure behavior are all covered; only the relationship to the overlapping pre_trade_check and any latency expectations are left unaddressed.

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?

Schema description coverage is 100%, so all three parameters (symbol enum with per-symbol expansions, price, window 1-240 default 30) are already documented in structured form. The description adds nothing about parameter semantics beyond restating the symbol set, so the baseline of 3 applies.

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 uses a specific verb and resource ('short structured pre-trade brief') and enumerates the produced fields (headline, bias, confidence, key levels, risks, catalysts, GO/CAUTION/NO_GO tradeability), plus names the exact symbol universe. It clearly signals this is an aggregating composite of the toolkit's other data sources, but never states how it differs from the sibling pre_trade_check, which appears to produce an overlapping tradeability verdict.

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

Usage Guidelines3/5

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

Usage is implied by the name and the phrase 'pre-trade brief', and the description supplies quota/allowance rules (20 units per call, 1/day anonymous, 100 free calls/month with a key) that shape when an agent should call it. However, there is no explicit when-to-use versus when-not, and no named alternative such as pre_trade_check for a cheaper deterministic check.

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

All trading-signals-mcp 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.