Skip to main content
Glama
Sign In

MangroveAI

by io.github.MangroveTechnologies
OverviewDiscussionsAdmin

get_benchmark

Read-onlyIdempotent

Buy-and-hold return for an asset between two dates, as a percentage. Use it whenever you state what a strategy returned: a return with nothing to compare it against does not answer whether the strategy was worth running. run_backtest already includes this for its own window, so call this for a different asset or a different period. A YYYY-MM-DD end date covers that whole UTC day, as run_backtest reads it; an end date of today stops at the end of yesterday, the last complete day; an exact end timestamp is passed through without adding a day.

[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": {
      "asset": "<asset>",
      "end_date": "<end_date>",
      "start_date": "<start_date>"
    },
    "name": "get_benchmark"
  }
}

Input Schema

NameRequiredDescriptionDefault
assetYesAsset symbol, e.g. BTC or ETH.
end_dateYesISO end of the window.
base_tokenNoCanonical base token; supply with quote_token and market_data_venue.
start_dateYesISO start of the window, e.g. 2026-01-01.
quote_tokenNoQuote currency of the requested market.
market_data_venueNoExact venue of the requested market.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is the date-window semantics (whole-UTC-day coverage, today's end date truncating to yesterday, exact timestamps passed through) and the access model (x402 micropayment vs. free API-key auth). That is genuinely useful context beyond the structured fields, though the cost/rate-limit behavior of repeated polling and the exact response payload are not addressed.

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 core purpose and the run_backtest distinction are front-loaded, and the date and payment notes are compact and actionable. The middle sentence ('a return with nothing to compare it against does not answer whether the strategy was worth running') is motivational padding that could be cut without losing 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?

For a read-only metric tool with a fully documented schema and no output schema, the description supplies the pieces an agent most needs: result unit, window semantics, sibling routing, and payment/auth requirements. The one remaining gap is how the optional market-identification parameters interact with the required asset symbol.

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 the baseline is 3; the description earns an upgrade by clarifying end_date semantics that the schema's 'ISO end of the window' does not — namely inclusive whole-day handling versus pass-through timestamps. The optional base_token/quote_token/market_data_venue trio is left entirely to the schema, so it is not fully comprehensive.

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 opening sentence gives a specific verb and resource ('Buy-and-hold return for an asset between two dates, as a percentage'), including the unit of the result. It also explicitly distinguishes itself from the sibling run_backtest, so an agent can route correctly without opening a schema.

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 states a concrete when-to-use rule ('use it whenever you state what a strategy returned') and an explicit when-not/alternative rule ('run_backtest already includes this for its own window, so call this for a different asset or a different period'). Both the trigger and the exception are spelled out rather than implied.

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

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