MangroveAI

query_signal_behavior

Read-onlyIdempotent

Query measured signal behaviour: describe, pick, find or gap_probability.

[Access: pay 0.005 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

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": {
      "lookup": "<lookup>"
    },
    "name": "query_signal_behavior"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum results, 1-100
`lookup`	Yes	describe: one signal -- parameter meanings, measured span, what its default measures. pick: settings of one signal that hit target_rate. find: which signals reach a rate band. gap_probability: share of a signal's gaps inside a range of bar lengths, per configuration.
`signal`	No	Signal name, e.g. rsi_oversold. Required by describe, pick, gap_probability
`category`	No	find: restrict to one family, e.g. oscillator, volatility, momentum
`max_rate`	No	find: high end of the band, same units (required)
`min_rate`	No	find: low end of the band, same units (required)
`signal_type`	No	FILTER (an ongoing state) or TRIGGER (a one-bar event); measured separately	FILTER
`target_rate`	No	pick: rate to aim for -- FILTER selectivity 0-1, TRIGGER firings per 1,000 bars. Omit to list the span
`max_gap_bars`	No	pick/find, TRIGGER only: median gap at most this many bars
`max_run_bars`	No	pick/find, FILTER only: mean run at most this many bars
`min_gap_bars`	No	pick/find, TRIGGER only: median gap at least this many bars
`min_run_bars`	No	pick/find, FILTER only: mean run at least this many bars
`max_gap_range_bars`	No	gap_probability: high end of the gap range, inclusive (required)
`min_gap_range_bars`	No	gap_probability: low end of the gap range, inclusive (required)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is carried. The description adds genuinely useful non-annotation behavior: a 0.005 USDC x402 cost per call, the PAYMENT-SIGNATURE header, and that API-key clients pay nothing — but says nothing about rate limits or result shape.

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 first sentence is front-loaded and short, but it duplicates the lookup enum that the schema already documents, and the bracketed access note is dense boilerplate. Nothing is padded to the point of harm, yet the mode enumeration does not earn its space.

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 14-parameter, four-mode tool with no output schema, the description should say more about what comes back (rate bands, per-configuration gap shares) and how the modes differ in required inputs. Annotations cover safety and payment is disclosed, but a mode-dependent query tool deserves richer framing.

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% and the lookup descriptions already spell out per-mode meaning, required vs optional fields (signal required by describe/pick/gap_probability; min/max_rate required by find) and units. The description's mode list is essentially a restatement of the schema, so it adds little beyond the baseline, but the baseline itself is a solid 4 given how thoroughly the schema documents 14 parameters.

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 names a specific verb and resource (query measured signal behaviour) plus the four lookup modes (describe, pick, find, gap_probability), so an agent can tell roughly what it does. It does not differentiate itself from the many signal siblings (evaluate_signal, get_signal, search_signals, match_signals, screen_candidates), which is where a 5 would require work.

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?

There is no when-to-use / when-not-to-use guidance and no alternatives named, despite a sibling set full of near-neighbours like evaluate_signal, match_signals and search_signals. The modes are listed, but the agent is left to infer which tool in the family this is for.

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

All MangroveAI 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.