Skip to main content
Glama
Sign In

Polyrank

by io.github.polyrank
OverviewDiscussionsAdmin

Strategy Lab: run a backtest

polyrank_run_backtest

Uses one of the plan's daily backtests: ask the user before calling, then pass confirm: true. Queue a backtest of a saved strategy (strategy_id) or an unsaved spec over [from, to) (ISO dates, at most 366 days), optionally with explicit re-rank cuts. Answers with the queued run; poll polyrank_get_backtest. Results are SIMULATED (each report names its fill model and measured optimism). Counts against your plan's daily backtests. Needs POLYRANK_API_KEY.

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": {
      "from": "<from>",
      "to": "<to>",
      "confirm": "<confirm>"
    },
    "name": "polyrank_run_backtest"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYes
cutsNo
fromYes
specNo
confirmYesRequired: true, and only after the user agreed to this call in the conversation.
strategy_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / confirm
      Added value: +{
+  "const": true,
+  "description": "Required: true, and only after the user agreed to this call in the conversation.",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "from",
-  "to"
-]New value: +[
+  "from",
+  "to",
+  "confirm"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses quota consumption, the required POLYRANK_API_KEY, that the call is asynchronous and returns only a queued run, and that results are simulated with a named fill model and measured optimism. These are exactly the mutation, cost and trust caveats an agent needs before spending the user's daily budget.

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

Conciseness5/5

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

Five tight sentences with the highest-stakes fact (quota burn, user confirmation) front-loaded, followed by inputs, return behavior and simulation caveat. No sentence is redundant and nothing is buried.

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 6-parameter, quota-consuming, asynchronous tool with no output schema, the description covers the confirmation gate, the range limits, the polling handoff and the simulation caveat. The remaining gap is the free-form nested spec object, which neither schema nor description explains.

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 description coverage is only 17%, so the description carries most of the load and mostly succeeds: it explains the [from, to) ISO-date range with a 366-day cap that is absent from the schema, and clarifies strategy_id vs spec as two ways to select the strategy. However, spec's internal shape is left entirely opaque and "explicit re-rank cuts" does not explain what the cuts array semantics are.

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?

States a specific verb and resource ("Queue a backtest") and distinguishes two input modes: a saved strategy via strategy_id or an unsaved spec. That plus the polling note for polyrank_get_backtest separates it cleanly from list_backtests, get_backtest and start_paper.

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

Usage Guidelines4/5

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

Gives an explicit precondition ("ask the user before calling, then pass confirm: true"), tells the agent that the call consumes a daily backtest quota, and routes to polyrank_get_backtest for results. It does not name alternatives such as list_backtests or get_lab_limits for checking remaining quota, so it stops short of full alternative routing.

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

All Polyrank 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