Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

polymarket_homepage_feed

Fetch structured rows from Polymarket homepage feeds by choosing trending, breaking, new, or other categories to get event and market data.

Instructions

List Polymarket homepage feed rows. Returns rows for Polymarket homepage feeds. The feed enum accepts trending, breaking, new, politics, sports, crypto, esports, iran, finance, geopolitics, tech, culture, economy, weather, mentions, and elections. Most feeds return events; breaking returns high-movement market rows and mentions returns open event search matches.

Input Schema

NameRequiredDescriptionDefault
feedNoHomepage feed
limitNoMaximum rows, defaults to 20 and supports up to 100
cursorNoOptional keyset cursor from a prior event feed response

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / feed / enum
      Added value: +[
+  "trending",
+  "breaking",
+  "new",
+  "politics",
+  "sports",
+  "crypto",
+  "esports",
+  "iran",
+  "finance",
+  "geopolitics",
+  "tech",
+  "culture",
+  "economy",
+  "weather",
+  "mentions",
+  "elections"
+]
  2. Addedv1.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that most feeds return events while 'breaking' returns high-movement market rows and 'mentions' returns open event search matches, which is genuine behavioral information. It does not cover pagination behavior, auth needs, or rate limits beyond what the cursor schema already says.

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

Conciseness3/5

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

The opening two sentences are redundant, and the 16-value enum list repeats data already present in the schema, padding the description. The genuinely useful distinction (breaking/mentions return shapes) is buried at the end rather than front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-output-schema listing tool, the description covers the special-return cases but leaves the general return shape vague ('returns events'), and says nothing about pagination ordering or how to continue from the cursor. Adequate but with clear gaps.

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, but the description adds real meaning beyond the raw enum by explaining that 'breaking' yields market rows rather than events and 'mentions' yields open event search matches. The remaining enum values are still just duplicated from the schema, so it is not a full 5.

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?

States a specific verb ('List') and resource ('Polymarket homepage feed rows') and identifies that it operates on homepage feeds rather than arbitrary markets. However it never names the sibling (e.g. polymarket_events) it differs from, and the second sentence largely restates the first.

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?

Usage is implied through the feed categories and the note about what 'breaking' and 'mentions' return, but there is no explicit when-to-use guidance or comparison against alternatives like polymarket_events or polymarket_predictions. An agent must infer that this is for browsing rather than targeted retrieval.

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