Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

polymarket_rewards_market

Fetch Polymarket liquidity-rewards details for a market by condition id, including daily reward rate, spread, volume, and token prices. Returns 404 when no rewards exist.

Instructions

Get Polymarket rewards market. Returns the liquidity-rewards details of one Polymarket market by condition id: the question, daily reward rate, rewards minimum size and maximum spread, each reward configuration with its start and end dates and rate per day, total configured rewards, 24-hour volume and outcome token prices. A condition id with no rewards row returns 404.

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": {
      "condition_id": "<condition_id>"
    },
    "name": "polymarket_rewards_market"
  }
}

Input Schema

NameRequiredDescriptionDefault
condition_idYesPolymarket market condition id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it enumerates the returned liquidity-rewards fields (daily rate, min size, max spread, per-config start/end dates, volume, token prices) and discloses the 404 behavior for a missing rewards row. It omits auth/permission or rate-limit traits, which is a minor gap for a read tool.

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?

Front-loaded with the core purpose, then a single dense but purposeful sentence listing the returned fields, closed by the 404 caveat. Every clause adds information; only the field enumeration is long, and it is necessary given there is no output schema.

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?

No output schema exists, so the description must convey the return shape, which it does thoroughly (rewards config detail plus volume and token prices) and it covers the error case. A note on whether an empty-but-present rewards row differs from a 404 would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the single condition_id parameter is already documented in the schema as 'Polymarket market condition id'. The description restates 'by condition id' without adding format, sourcing, or lookup guidance, so the baseline 3 is appropriate.

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 (Get/Returns) and resource (liquidity-rewards details of one Polymarket market) scoped by condition id, and extends to what data the payload holds. It clearly distinguishes itself from the plural sibling polymarket_rewards_markets by specifying 'one market by condition id'.

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

Usage Guidelines3/5

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

The single-market scoping and the 'no rewards row returns 404' note imply when this is the right call, and it contrasts implicitly with the plural rewards-markets sibling. However, no alternative tool is named and there is no explicit condition for choosing this over polymarket_market_detail or polymarket_rewards_markets.

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

Deploy Server

Other Tools