Skip to main content
Glama

x402Pulse

wallet

Polymarket trader scorecard for any wallet: skill score (0-100), edge over the odds paid, win rate vs. the win rate the odds implied, return (ROI), realized PnL, specialty and largest open positions. Scores the latest 200 finished bets, losses included.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesPolymarket proxy wallet address

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/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 does add real behavioral context by disclosing the scoring basis ('latest 200 finished bets, losses included'), which tells the agent about the sample window and that results are not cherry-picked. However, it omits any auth requirements, error behavior for unknown/invalid wallets, or latency/rate considerations.

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 and followed by the concrete return fields. The metric list is somewhat long but each entry earns its place by telling the agent what to expect. No filler or redundancy.

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?

There is no output schema, so the description correctly compensates by enumerating the returned fields (skill score, edge, win rate, ROI, PnL, specialty, open positions). Combined with the disclosed scoring window, an agent has enough to invoke and interpret the tool, though absent error/auth notes keep it short of a 5.

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% and the single parameter is documented as a 'Polymarket proxy wallet address' with a strict regex pattern. The description adds nothing beyond the schema here ('for any wallet'), so the baseline 3 for high-coverage schemas 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 verb+resource ('Polymarket trader scorecard for any wallet') and enumerates the metrics produced, so the agent knows exactly what it returns. It implies single-wallet analysis via 'any wallet' with a required address, which distinguishes it from leaderboard-style siblings like top_traders or whales, but it never names or explicitly contrasts those alternatives.

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 only implied: the required 'address' param and 'for any wallet' phrase signal that this is the tool for evaluating one specific wallet. There is no explicit when-to-use, when-not-to-use, or routing to siblings like smart_money or skilled_whales, which a caller might reasonably confuse this with.

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