MangroveAI

screen_candidates

Read-onlyIdempotent

Rank several candidate strategies by how likely each is to trade at all, before spending backtests on them. Give it one asset and up to 99 candidates, each {entry: [...], exit: [...]} with signals from the library -- the roles come from the library, so do not pass signal_type. IT PREDICTS WHETHER A STRATEGY WILL PLACE TRADES, AND NOTHING ABOUT WHETHER IT WILL MAKE MONEY: only a backtest answers that. Use it to choose which of many candidates to backtest first, never as a verdict on a single strategy -- a probability on its own says little, and the ranking is the answer. A HIGH score is real support for spending a backtest. A LOW score is weak evidence and is NOT a finding that the strategy will not trade: measured against runs that did trade, a 0.5 cutoff recovers under half of them. Never tell someone their strategy will not trade because this scored it low; back it and find out.

[Access: pay 0.02 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": {
      "asset": "<asset>",
      "candidates": "<candidates>"
    },
    "name": "screen_candidates"
  }
}

Input Schema

Name	Required	Description	Default
`asset`	Yes	Asset symbol, e.g. BTC or ETH.
`candidates`	Yes	Each {entry: [{name, params?, timeframe?}], exit: [...]}.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses the tool's inferential limits: high scores are support for backtesting, low scores are weak evidence, a 0.5 cutoff recovers under half of true trading runs, and users must not claim a low-scoring strategy will not trade. It also explains x402/API-key access and pricing.

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 description is front-loaded and mostly earns its length through important caveats and usage limits. It is somewhat verbose and repetitive in the low-score warning, but the repetition serves a safety-critical point.

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 pre-backtest screening tool with no output schema, it explains the ranking output, the input shape, access/payment requirements, and the interpretation limits needed to call and communicate results responsibly. Nothing essential is missing.

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?

Although schema coverage is 100%, the description adds meaningful semantics absent from the schema: up to 99 candidates, each with entry/exit signal lists, roles coming from the library, and an explicit instruction not to pass signal_type.

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?

The description states a specific verb and resource: rank candidate strategies by likelihood of trading before backtesting. It clearly distinguishes this screening step from backtest/evaluation tools by emphasizing that only a backtest answers profitability.

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

Usage Guidelines5/5

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

It explicitly says when to use it: choosing which of many candidates to backtest first. It also gives clear exclusions: never as a verdict on a single strategy, and only a backtest determines whether a strategy makes money.

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.