orcatrace-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct (get_index, get_sample, get_research, etc.), but get_latest and get_signal overlap significantly since get_signal can omit the index to return the latest item. get_track_record and get_whales are related but their descriptions clearly separate free proof from paid data.
Naming Consistency5/5
All tools follow a consistent get_<noun> pattern with snake_case throughout. Plurals and modifiers (get_signals, get_digest_history) fit the convention and are predictable.
Tool Count5/5
13 tools is well-scoped for a Polymarket intelligence API, covering free hooks, paid signals, digests, whale tracking, and research without over-expanding. Each tool has a clear role in the workflow.
Completeness4/5
The tool surface covers the core intelligence workflow: polling for new items, retrieving individual/batch signals, digest summaries and history, whale calibration, resolving markets, and on-demand research. Minor gaps exist (e.g., no simple market quote tool), but the domain is well-covered.
Average 4.7/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the paid nature ($0.01 via x402), the compute-first/settle-after model (no charge on error), the three possible return types, and the behavior without a key (returns 402 price terms). This goes well beyond minimal requirements.
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?
The description packs essential operational details (cost, types, index, payment, error safety) into a compact set of sentences. It's slightly dense but each sentence contributes value; minor structural improvements could separate payment setup from return types.
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?
The description covers the tool's purpose, parameters, payment prerequisites, and behavioral guarantees (free on error). It lacks explicit response format, but given the absence of an output schema, it could be more explicit about return values; still, it provides enough context for an agent to decide.
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?
The schema already documents the single parameter index with its description, including 'omit for the latest.' The description repeats this and adds 'Pass index=N for a specific item,' but no new semantic meaning beyond the schema. Coverage is 100%, so baseline is 3.
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?
The description clearly identifies the tool's function: retrieving a single Polymarket feed item (mover, whale entry, or predetermined signal). It distinguishes from siblings by supporting an optional index parameter and indicating it returns one item, unlike get_signals (plural). The verb 'get' plus specific resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains exactly how to use the tool: pass index for a specific item or omit for the latest, and notes the need for PRIVATE_KEY for live payment. It references get_index for obtaining the index, providing contextual linkage. However, it doesn't explicitly contrast when to use get_signal vs get_signals or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses payment via x402, cost, generation time, caching, USDC on Base, refund policy, and the need for PRIVATE_KEY, including behavior without a key (returns 402 price terms). This is comprehensive behavioral disclosure.
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?
The description is longer but every sentence conveys relevant information: cost, output, timing, input, payment mechanics, refund, and key requirement. There is minor redundancy between 'PAID $1.00 via x402' and 'Pays USDC on Base via x402', but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a standalone tool with no output schema, the description covers input, output content, timing, caching, payment, refund, and failure mode. It is complete enough for an agent to decide and invoke correctly.
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?
The schema has one parameter, market, with a description matching the text. The description repeats the slug instruction but adds no new semantic detail beyond the schema, so baseline 3 applies.
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?
The description clearly states the tool performs a single-market deep-dive, synthesizing price action, order book, whale positioning, and news into a thesis with risks and a bottom line. This is a specific verb+resource and distinguishes from sibling tools like get_index or get_digest which likely provide broader market views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the use case: a paid, on-demand deep-dive for a specific market, with instructions to pass the market slug from a URL or feed item. It does not explicitly compare to alternatives, but the single-market scope and payment prerequisites provide clear context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses key behavioral traits: 'noise-filtered', 'FREE', 'rate-limited 5/min per IP', and 'no wallet or API key required'. It doesn't describe return format or what the digest teaser entails, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function, then practical constraints. No wasted words; efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and simple read-only nature, the description is complete: it explains what is returned, the endpoint, rate limit, and auth requirements. An agent can invoke it correctly based on this.
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?
Input schema has zero parameters, so baseline is 4. The description mentions 'no wallet or API key required' which clarifies auth is not a parameter, and there are no parameter semantics to explain beyond that.
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?
The description clearly states the tool returns 'Top-3 Polymarket repricings over 24h (noise-filtered) plus a digest teaser', which is a specific resource and scope. It distinguishes itself from siblings like get_index and get_digest_brief by focusing on repricings and the free hook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear practical context: 'FREE, rate-limited 5/min per IP, no wallet or API key required' implies usage for unauthenticated users needing a free sample. However, it does not explicitly name alternative tools or state when not to use it, so it's short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the paid nature ($0.05 via x402), the compute-first/settle-after model, that errors are never charged, and the behavior without a PRIVATE_KEY (returns 402 price terms). This is comprehensive behavioral context.
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?
The description is dense but not overly long; it front-loads payment info before purpose. All content is relevant, but the structure could be improved by stating the primary function first. Still, no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers the tool's scope, cost, auth requirements, error handling, and example usage, making it fully sufficient for an agent to decide when and how to invoke it.
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 covers 100% of parameters with clear descriptions. The description adds a concrete usage example (hours=24, limit=6) that clarifies typical parameter values, though it doesn't add new semantic meaning beyond the schema.
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?
Description clearly states the tool returns historical Polymarket Intelligence Digests with a 7-day lookback and 4-hour cadence, using a specific verb+resource. The 'historical' aspect differentiates it from sibling tools like get_digest and get_latest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tracking how prediction-market narratives evolved and provides an example (hours=24, limit=6), but does not explicitly state when to use this over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fully discloses payment cost ($0.02), payment mechanism (x402), refund guarantee, private key requirement, and behavior without a key (returns 402 terms). This is exceptional transparency about the tool's operational behavior and prerequisites.
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?
The description is information-dense but well-structured: it opens with the core purpose and data returned, then covers filtering, payment, and auth in separate sentences. Each sentence adds value, but the density may require careful reading; still appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, yet the description covers what data is returned, parameter behavior, payment/refund policies, and authentication requirements. It is complete enough for an agent to understand the tool's full context, including failure modes (402 without key) and live vs. price-term behavior.
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 parameters are documented structurally. The description adds meaningful context beyond the schema by explaining 'withinHours' range (1-72), the default for 'includeNoise', and the meaning of 'mechanical short-interval markets'. This enriches the schema's basic descriptions, though 'minLiquidity' is only covered by schema.
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?
The description clearly states the tool retrieves Polymarket markets resolving within a specified time window, with specific data fields (odds, contested-vs-converged, liquidity, order-book microstructure). This specific verb+resource+scope distinguishes it from sibling tools like get_pulse or get_digest, which likely serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear conditions: mechanical short-interval markets excluded by default, includeNoise=true to include them, and live API requires PRIVATE_KEY with USDC on Base, otherwise returns 402 price terms. It does not explicitly name alternatives but gives enough contextual usage guidance for an agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses rate limiting, no auth, free status, and the key measurement limitation (hold-to-resolution vs. P&L). It also highlights verifiability through full public addresses, which is useful behavioral context.
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?
The description is dense but contains no wasted words: it covers purpose, metrics, endpoint, scope caveat, and access limits in a compact form. The first sentence is a bit long, but it front-loads the core identity effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description enumerates the key output components (win rate, ROI, odds-band breakdown, top-10 wallets) and operational details (rate limit, auth, endpoint). It is thorough for a parameterless read-only tool with no output schema.
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?
The schema has zero parameters, so the description need not explain inputs. It doesn't add parameter details because there are none, and the baseline for 0-param tools is 4. The description correctly implies a parameterless GET call.
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?
The description clearly identifies a specific deliverable ('Verifiable whale-calibration scorecard') and lists concrete metrics (win rate, ROI, odds-band breakdown, top-10 wallets). It distinguishes itself from the paid get_whales tool by positioning as the free proof, so it stands apart from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: as a free verification companion to get_whales. It also clarifies scope (entries held to resolution, not P&L) and access constraints (free, 5/min rate limit, no auth). However, it does not explicitly list exclusions or alternative tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the paid nature ($0.01 via x402), the payment mechanism (USDC on Base), and the compute-first/settle-after model where users are never charged for an error. It also reveals the response without a key (402 price terms), providing complete transparency about tool 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?
The description is information-dense and front-loaded with the cost, but it contains a minor redundancy: 'PAID $0.01 via x402' and 'Pays USDC on Base via x402' both state the x402 payment. Otherwise, every sentence provides unique value and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers everything an agent needs: purpose, cost, usage sequence, prerequisites, and how to discover the response shape via get_sample. It is fully self-contained with appropriate cross-references to sibling tools.
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?
The input schema has zero parameters, so a baseline score of 4 applies. The description adds no parameter-specific semantics because there are none to describe, and it appropriately focuses on behavioral and usage context instead.
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?
The description clearly states that get_latest returns the most recent Polymarket feed item and enumerates the types of items (quality-gated mover, tracked-whale entry, AI-detected predetermined-outcome signal). It distinguishes itself from get_signal by saying 'Same shape as get_signal without an index', making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage instructions: 'Poll get_index (free) first; preview the shape with get_sample (free)' and provides the prerequisite of setting PRIVATE_KEY for live API use, noting the behavior without a key. This clearly guides when and how to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the payment mechanism ($0.05 via x402), refund policy, requirement for PRIVATE_KEY with USDC on Base, and behavior without a key (returns 402 price terms). No annotations are provided, so the description carries the full burden and does so thoroughly.
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?
The description is longer than typical but every sentence adds critical information: pricing, data content, relationship to sibling tools, refund guarantee, and key requirement. It is well-structured and front-loaded with the most important detail (paid).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a paid API with no output schema, the description covers all necessary aspects: what data is returned, how to pay, what happens if payment is charged but not delivered, and prerequisites. It even lists the specific metrics included in the table.
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?
The input schema has zero parameters, so baseline is 4. The description compensates by explaining the payment configuration (PRIVATE_KEY environment variable) which is not a schema parameter but is essential for invocation.
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?
The description clearly states the tool's function: it returns a whale calibration table with per-wallet hold-to-resolution win rates, mirror/fade ROI, and follow/fade labels. It also differentiates itself from the free alternative get_track_record by noting it's the paid data behind whale_entry annotations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names get_track_record as the free proof alternative, implying when to use that instead. It also provides clear context for when to use this tool (when paying for the calibration table) and operational prerequisites (set PRIVATE_KEY).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: paid ($0.10), compute-first/settle-after (never charged for errors), freshness policy (never serves stale, returns 503 if behind), and returns 402 without a key. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds critical value: payment, content, analysis type, freshness, free alternative, payment mechanics, and key requirement. It is dense but well-structured, front-loading the payment requirement and delivering comprehensive information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly covers the operational aspects: what the digest contains, when it's generated, how payment works, error statuses (503, 402), and the free alternative. It is complete and leaves no critical 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?
There are no parameters in the schema (0 params), so the baseline per rubric is 4. The description appropriately adds context about the PRIVATE_KEY environment variable, which is not a parameter but is essential for usage, without cluttering parameter semantics.
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?
The description clearly states it provides the full Polymarket Intelligence Digest, generated every 4 hours, and details what it contains (significant moves, whale positioning, news context). It distinguishes itself from the sibling get_digest_brief by describing the latter as a free teaser.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names get_digest_brief as a free alternative, and provides clear usage conditions: payment via x402, PRIVATE_KEY requirement, and the 402 price terms when no key is set. This tells the agent when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it is free, rate-limited at 5/min per IP, requires no wallet/API key, and returns only a title/summary without analysis. Since no annotations exist, this description fully covers the safety/access profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences deliver purpose, endpoint, cost, rate limit, and auth requirements without waste. Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides sufficient context: what it returns, what it omits, access constraints, and alternative. Complete for its complexity.
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?
The input schema has zero parameters, so baseline score 4 applies; description adds no parameter details because none exist.
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?
Clearly states the tool returns a teaser with title and summary, explicitly excludes analysis, and identifies the endpoint. Distinguishes from siblings by contrasting with the paid get_digest tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions the alternative get_digest for the full paid digest, and specifies costs, rate limit, and auth-free access, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses that the tool is free, read-only (poll target), rate-limited to 5/min, and requires no authentication. It also adds cadence and endpoint details, which are valuable behavioral traits beyond any structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, packing purpose, usage, cadence, endpoint, and access constraints into two efficient sentences. Every element adds value, and it is front-loaded with the core purpose before delivering operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete. It covers what the tool returns, when to use it, how often to poll, the rate limit, and authentication requirements. No further context is needed for an agent to correctly select and invoke it.
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?
The tool has zero parameters, so the baseline is 4. The description adds context about the HTTP endpoint (GET /v1/index) and the purpose, but no parameter explanations are needed. It does not repeat schema info beyond what is already empty.
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?
The description clearly states this tool returns the current Polymarket feed index and identifies its specific role as a polling target to detect new items. It distinguishes itself from sibling tools like get_signal by framing the index as a preliminary check before paying for a signal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: poll target to detect new items at ~10min cadence, before paying for a signal. It also provides operational constraints (FREE, rate-limited 5/min per IP, no auth) which inform usage decisions. This implies not for fetching the signal itself, giving clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: it is FREE, rate-limited to 5/min per IP, requires no wallet or API key, and returns static labelled samples rather than live data. This goes beyond typical descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence covers purpose, usage, cost, rate limit, auth, and static nature. Every element earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: it explains what the sample is, why someone would use it, and all constraints. No gaps remain.
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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details but also doesn't need to; the empty schema is self-explanatory.
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?
The description clearly states the tool provides 'Static samples of every paid Polymarket response shape' and lists specific shapes (signal, whales, digest). This distinguishes it from sibling tools that return actual data or other types of information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to 'use it to learn the contract before paying', giving clear when-to-use guidance. It also differentiates from paid alternatives by being FREE and sample-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses the exact cost ($0.03 via x402), the batch limit, the requirement for PRIVATE_KEY, the 402 response without a key, and the guarantee that users are never charged for an error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence serves a purpose: cost, contents, usage workflow, payment mechanics, and key requirements. The description is front-loaded with the most critical operational detail (paid nature) and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid feed tool with 3 optional params and no output schema, the description covers all necessary usage context: authentication (PRIVATE_KEY), pricing, error safety, pagination (since), filtering (type), and the integration with get_index. An agent has enough information to invoke correctly.
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?
The schema already describes all three parameters at 100% coverage, so the baseline is 3. The description adds value by explaining the relationship between since and get_index, and by confirming count's maximum of 20. It does not go into deeper detail for each enum value, but the schema already covers that.
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?
The description clearly identifies this as a paid batch endpoint for Polymarket feed items, explicitly listing the three item types (mover, whale_entry, predetermined). It distinguishes itself from free siblings like get_index by noting the paid nature and the requirement to poll get_index first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit workflow: 'Poll get_index (free), then pass since=N for new items; filter with type.' It also clarifies when payment is required, how to obtain price terms without a key, and the compute-first/settle-after behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![orcatrace-mcp MCP server](https://glama.ai/mcp/servers/jcislo/orcatrace-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jcislo/orcatrace-mcp)

Score Badge

Copy to your README.md:

[![orcatrace-mcp MCP server](https://glama.ai/mcp/servers/jcislo/orcatrace-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jcislo/orcatrace-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jcislo/orcatrace-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server