Polyrank

Lab assistant: ask in a new chat

polyrank_lab_ask

Spends the account's AI credits: ask the user before calling, then pass confirm: true. Start a Lab assistant chat with a question (research only: it finds traders, saves, backtests and paper-trades strategies in YOUR account, never places orders). Spends your plan's AI credits (a question needs 25 to start; a typical one costs about 13; deep: true runs the slower, more thorough mode, about twice the credits, Lab Pro and up). Your plan answers a number of chats at once (Pro Trader 2 … Enterprise 8; one more is refused 429 lab_agent_busy). Waits up to wait_seconds (default 45, max 55) for the answer; if it is still working, poll polyrank_lab_get_chat with the returned id. A long backtest it starts answers at once and its result is posted to the chat later. Results are SIMULATED. 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": {
      "message": "<message>",
      "confirm": "<confirm>"
    },
    "name": "polyrank_lab_ask"
  }
}

Input Schema

Name	Required	Description
`deep`	No
`confirm`	Yes	Required: true, and only after the user agreed to this call in the conversation.
`message`	Yes
`wait_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

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: -[
-  "message"
-]New value: +[
+  "message",
+  "confirm"
+]

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The description carries far more than the annotations. It discloses credit costs (25 to start, about 13 typical, deep about double), plan concurrency caps and the specific failure mode (429 lab_agent_busy), the wait default and max, the simulated nature of results, and the POLYRANK_API_KEY requirement. Annotations only say it is not read-only and not destructive; the description adds the real cost and rate-limit behavior, so this is a 4 rather than a 5.

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 content is rich and front-loaded: the credit spend and the confirm precondition come first. However, the single dense paragraph is packed with parentheticals ('Pro Trader 2 … Enterprise 8', 'a question needs 25 to start; a typical one costs about 13'), which makes it harder to scan than a short bulleted breakdown would be.

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?

Complete for a paid chat-start operation with no output schema. The description covers cost, consent, concurrency refusal, timeout behavior and follow-up polling, so an agent has everything it needs to call correctly and handle the slow path.

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 only 25% (only `confirm` is documented), so the description has to compensate. It does: `deep` gets meaning (slower, more thorough, about twice the credits, Lab Pro and up), `wait_seconds` gets a default (45) and a max (55), and `confirm` gets a consent condition. It never mentions the 8000-character `message` limit or what belongs in a good question, which is the only remaining gap.

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: 'Start a Lab assistant chat with a question', and the scope is precise: research only, finding traders/backtests/paper-trades, 'never places orders'. That last clause cleanly separates it from the execution-shaped siblings like polyrank_start_paper and polyrank_run_backtest.

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?

Explicit gating and alternatives: 'ask the user before calling, then pass confirm: true', and 'if it is still working, poll polyrank_lab_get_chat with the returned id'. It also names the situation where a poll is unnecessary, namely a long backtest, which 'answers at once and its result is posted to the chat later'.

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

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