Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

polymarket_events

List Polymarket events and their markets, sort by volume, liquidity, or end date, filter open or closed events, and page results with limit and offset.

Instructions

List Polymarket events. Lists Polymarket events with their markets. Sort by 24-hour volume, total volume, liquidity, end date and more, filter to open or closed events, and page with limit (default 25, max 100) and offset. Each event has its slug, description, end date, liquidity, open interest and comment count; each market has its question, outcomes, best bid and ask, last trade price and volume.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum events, defaults to 25 and supports up to 100
orderNoSort field
closedNoClosed filter
offsetNoResult offset, defaults to 0 and supports up to 10000
ascendingNoSort ascending when true

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / closed / enum
      Added value: +[
+  "true",
+  "false"
+]
    • addedInput schema / properties / order / enum
      Added value: +[
+  "volume24hr",
+  "volume",
+  "liquidity",
+  "endDate",
+  "updatedAt",
+  "createdAt",
+  "id",
+  "slug",
+  "title",
+  "question",
+  "label"
+]
  2. Addedv1.1.0

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations and no output schema, the description carries the full burden and mostly does: it discloses the returned shape (event-level slug, description, end date, liquidity, open interest, comment count; market-level question, outcomes, best bid/ask, last trade price, volume) plus pagination defaults and caps. It does not note auth requirements or rate limits, but for a public read-only list it is substantially informative.

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?

Two sentences, front-loaded with the core purpose before the capability and return-field inventory. The field enumeration is dense but each clause earns its place; no filler or tautology.

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 paginated list tool with an output schema absent, the description adequately covers what is listed, the knobs available, page-size defaults, and the returned fields. The main omission is any routing to the many sibling polymarket tools, which the agent would need to disambiguate.

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 description coverage is 100%, so each parameter is already documented; the description restates the limit default/max and the open/closed filter without adding new semantics. It hints at sort options ('24-hour volume, total volume, liquidity, end date and more') but omits several enum values (updatedAt, createdAt, id, slug, title, question, label) and says nothing about 'ascending'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('List Polymarket events') and immediately clarifies scope ('with their markets'). However, it never distinguishes itself from close siblings like polymarket_markets, polymarket_event_detail, or polymarket_search, so the agent gets a clear purpose but no routing signal.

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

Usage Guidelines2/5

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

The description enumerates capabilities (sort fields, open/closed filter, pagination) but never states when to choose this tool over alternatives such as polymarket_search or polymarket_event_detail. With a large family of sibling polymarket_* tools, the absence of any when/when-not guidance is a real gap.

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