Skip to main content
Glama
Sign In

SiteCheck

by io.github.bck-stack
OverviewDiscussionsAdmin

Quote a YES or NO buy on a Panta market for a USDC amount

markets_quote
Read-only

Quote a YES or NO buy on a Panta market for a USDC amount and wallet: expected shares, average fill price, fee and price impact against the spot price. Nothing is signed or sent. Powered by Panta. Related tools on this server, for a different need: markets_brief when you need One Panta prediction market in depth: current YES/NO odds; markets_build_buy when you need to create an unsigned Panta buy transaction. Price: $0.005 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>",
      "side": "<side>",
      "amountUsdc": "<amountUsdc>",
      "wallet": "<wallet>"
    },
    "name": "markets_quote"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesPanta market id (the market's event address, base58), from GET /api/markets
sideYesyes or no
walletYesThe buyer's Solana wallet (base58). It pays and signs; SiteCheck never does.
amountUsdcYesUSDC to spend, as a decimal string, e.g. "5.00"

Output Schema

NameRequiredDescriptionDefault
spotPriceNo
disclaimerNo
priceImpactNo
expectedFillNo

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true; the description usefully reinforces this with "Nothing is signed or sent," and adds genuinely new behavioral context: a $0.005 USDC per-successful-call price, x402 payment on Base/Solana/Arc, and the fact that failed calls are not charged. It does not contradict annotations, though it omits things like quote freshness or behavior on illiquid markets.

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 purpose is front-loaded in the first sentence, followed immediately by the outputs, then the non-mutating and pricing facts, then sibling routing. Most sentences earn their place, but "Powered by Panta" is branding filler and the long "Related tools on this server, for a different need:" framing is verbose relative to the useful routing it carries.

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?

With an output schema present, the description correctly summarizes rather than fully specifies return values, and it covers the non-obvious cost model and non-signing behavior. Combined with full annotation and 100% param coverage, an agent has what it needs to call it; only edge-case behavior (stale or unavailable quotes) is left unspecified.

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% and all four parameters are documented in-schema, including the base58 wallet and the decimal-string amount format. The description only restates "USDC amount and wallet" at a high level, adding no syntax, constraints, or meaning beyond the schema, so the baseline of 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 (quote) plus the exact resource (a YES or NO buy on a Panta market for a USDC amount and wallet) and enumerates the returned figures: expected shares, average fill price, fee, and price impact against spot. It also names the siblings it is not (markets_brief, markets_build_buy), so an agent can separate this from them 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly routes to alternatives: markets_brief "when you need One Panta prediction market in depth: current YES/NO odds" and markets_build_buy "when you need to create an unsigned Panta buy transaction." That gives strong when-to-use-other guidance, but the positive trigger for this tool (pre-trade pricing simulation) is only implied by the title rather than stated as an explicit condition.

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

All SiteCheck toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources