Skip to main content
Glama

evaluate_multiple_signals_series

Read-onlyIdempotent

Evaluate chart data and optional signal triggers over a specific range.

[Access: pay 0.05 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

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

Input Schema

NameRequiredDescriptionDefault
symbolNoLive-mode asset symbol; required unless dataset_key is provided
signalsNoUp to 20 registered signals to evaluate
end_dateNoLive-mode chart end timestamp; with start_date, or omit both for the latest 500 bars
providerNoExplicit external history provider
start_dateNoLive-mode chart start timestamp; with end_date, or omit both for the latest 500 bars
dataset_keyNoBundled dataset key; replaces symbol and date range
quote_tokenNoLive-data quote; supply with market_data_venue
include_chartNoAlso return chart bars (latest 2,000 at most) and trigger_indices
chart_timeframeNoLive chart timeframe; dataset mode uses its bundled timeframe1h
market_data_venueNoLive-data exchange; supply with quote_token

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / end_date / description
      Previous value: -"Live-mode chart end timestamp; required unless dataset_key is provided"New value: +"Live-mode chart end timestamp; with start_date, or omit both for the latest 500 bars"
    • addedInput schema / properties / include_chart
      Added value: +{
      +  "default": false,
      +  "description": "Also return chart bars (latest 2,000 at most) and trigger_indices",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / start_date / description
      Previous value: -"Live-mode chart start timestamp; required unless dataset_key is provided"New value: +"Live-mode chart start timestamp; with end_date, or omit both for the latest 500 bars"
  2. First observed

TDQS

B3.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description earns credit for disclosing something annotations cannot: the x402 pay-per-call charge of 0.05 USDC, the PAYMENT-SIGNATURE header requirement, and that an API-key path is free — material context an agent needs before invoking. It stops short of describing result shape or cost scaling with the number of signals.

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?

Two compact blocks: a one-sentence purpose followed by a bracketed access note. Both are front-loaded and free of filler, though the access sentence is denser than necessary for the value it carries.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required, 10-parameter tool with no output schema and a dual live/dataset mode, the description covers payment but not returns — it never mentions that the result contains evaluated signal triggers or optional chart bars and trigger indices. The schema fills the parameter gaps, but an agent still has to infer what comes back.

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 10 parameters including the nested signal object are documented in the schema, which sets the baseline at 3. The description adds only a vague "specific range" and no mapping between symbol/start_date/end_date mode and dataset_key mode, nor any note that omitted dates default to the latest 500 bars.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Evaluate chart data and optional signal triggers over a specific range" gives a verb (evaluate) and the resources (chart data, signal triggers), but it is generic and never states the defining trait that separates it from the sibling evaluate_signal — that it evaluates a batch of up to 20 registered signals at once. Coverage of the two operating modes (live symbol/date range vs. bundled dataset_key) is also left entirely to 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 Guidelines2/5

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

Nothing says when to call this instead of evaluate_signal, evaluate_strategy, or match_signals, nor when live mode is preferred over dataset mode. The only routing information present is about billing, not about tool selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.