Skip to main content
Glama

One Panta prediction market in depth: current YES/NO odds

markets_brief
Read-only

One Panta prediction market in depth: current YES/NO odds, recent trading activity and a short neutral AI summary of what it asks, what resolves it and what the price implies. No advice. Powered by Panta. Related tools on this server, for a different need: markets_quote when you need quote a YES or NO buy on a Panta market for a USDC amount; markets when you need to search Panta prediction markets. Price: $0.01 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "markets_brief"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesPanta market id, from GET /api/markets

Output Schema

NameRequiredDescriptionDefault
marketNo
summaryNo
disclaimerNo
recentActivityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "disclaimer": {},
      +    "market": {},
      +    "recentActivity": {},
      +    "summary": {}
      +  },
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds genuine non-schema context: a $0.01 USDC charge per successful call via x402 on Base, Solana, or Arc, with failed calls not charged. That payment/auth detail is exactly the kind of thing annotations cannot convey, though it doesn't describe latency, caching, or behavior for unknown/expired market ids.

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 core capability, output contents, and sibling routing are all front-loaded in the first two sentences. Minor waste remains in 'Powered by Panta' and the run-on construction of the alternatives clause ('when you need quote a YES or NO buy'), but nothing essential is buried.

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?

There is an output schema, so return-value detail is not owed, yet the description still previews the result shape (odds, activity, summary of resolution and price implication). With a single fully documented parameter, annotations, and pricing disclosed, an agent has everything needed to call it 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?

Only one parameter exists and schema coverage is 100%, with the schema itself explaining that the id comes from GET /api/markets. The description reinforces that this is a Panta market id but adds no format, length, or error semantics beyond that, 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?

States a specific verb+resource: retrieves one Panta prediction market 'in depth' with current YES/NO odds, recent trading activity, and a neutral AI summary. It explicitly contrasts itself with markets_quote (quoting a buy) and markets (search), so an agent can distinguish it from the nearest siblings without opening a schema.

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?

Names two alternatives with the exact condition that selects each ('markets_quote when you need a quote for a YES or NO buy for a USDC amount', 'markets when you need to search'), and the schema ties the id to the search tool's output, giving an implicit workflow. It also states the not-advice posture, which frames how the result should be used.

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