Skip to main content
Glama

x402Pulse

smart_money

Polymarket smart money for one market: the biggest holders on each side, each scored for skill (edge, win rate, ROI), plus which way skilled money leans and whether it agrees with the market's odds. Accepts a market link, slug or condition ID. Data, not investment advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketYesPolymarket market URL, slug or condition ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations at all, the description carries the full burden, and it does disclose the substance of the output (holders per side, skill scoring dimensions, lean and agreement). However, it says nothing about read-only/freshness/permission traits or any constraints. It is informative about return content but silent on operational behavior.

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 that are front-loaded with the core payload and free of filler. The accepted-input variants are placed after the value proposition, which is the right ordering. The disclaimer tags on cleanly without bloating.

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 single-parameter, read-only analytics tool with no output schema, the description is largely self-sufficient: it explains what gets returned and even the scoring dimensions. The only shortfall is the absence of routing against very similar sibling tools, which an agent would still have to infer.

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 the single parameter ('Polymarket market URL, slug or condition ID') is already fully documented. The description's 'Accepts a market link, slug or condition ID' merely restates the schema, adding no syntax or format detail. Baseline 3 is appropriate.

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 gives a specific resource (Polymarket smart money) and scope ('for one market'), then enumerates exactly what is produced: biggest holders on each side, skill scores (edge, win rate, ROI), and skilled-money lean vs. market odds. The verb is analytical rather than a single action verb, but the output is unambiguous. It does not, however, distinguish itself from overlapping siblings such as skilled_whales, whales, or top_traders.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative. Given that skilled_whales, whales, and top_traders are plausible overlapping tools, the agent gets no help deciding among them. The 'data, not investment advice' line frames the tool's nature but does not route usage.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources