Skip to main content
Glama

Degenscan Intel

by io.github.tradewr333-lgtm
OverviewDiscussionsAdmin

Oracle: forecast a binary question (async)

oracle_forecast

Get a CALIBRATED probability for a yes/no market question — e.g. "Will Bitcoin close above 120,000 USD on 2026-10-31?", "Will the Fed cut at the October FOMC?", "Will ETH touch 5,000 before 2026-10-31?". The oracle first assembles live context from Intel (spot, 30d realized vol, funding, OI, Polymarket odds, calendar, recent primary-source events) and computes a volatility base rate; then runs Monte Carlo simulations of LLM agent societies (distinct personas, social graph, optional news shocks) plus a 5-expert panel anchored on the base rate; a reasoning model aggregates with the rule "0.5 is never a default". ASYNC: this call returns { forecast_id, status: "queued", eta_s } in under a second; poll oracle_get(forecast_id) every ~20 s (free) until status = "done" (1–3 min). Result: probability, ci80, disagreement, base_rate, market_odds, edge (probability − market), drivers, failure_modes, confidence, runs[] with belief trajectories, panel[], commitment_hash (sha256 committed before resolution), context_used. Public Brier record: oracle_track_record. $0.25/call (covers ~70 LLM calls). Optional interventions=[{round, news, audience}] inject a shock into the simulated society. Use to ask a NEW binary question (async, returns forecast_id); then poll oracle_get. For today's standing forecasts use oracle_board.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runsNoMonte Carlo runs (independent societies).
methodNoForce a method; default = router decides.
roundsNoInteraction rounds per run (simulated time steps).
contextNoExtra facts, news, market data the caller already has.
questionYesBinary question, e.g. 'Will BTC close above 120k on 2026-10-31?'
populationNoAgents in each simulated society.
resolves_atNoWhen the question resolves (ISO 8601).
interventionsNo
require_verifiedNoRefuse (HTTP 422, no charge) instead of publishing when a premise the answer depends on cannot be verified live. Human-facing surfaces set this true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / require_verified
      Added value: +{
+  "description": "Refuse (HTTP 422, no charge) instead of publishing when a premise the answer depends on cannot be verified live. Human-facing surfaces set this true.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, openWorld=true, idempotent=false); the description goes far beyond, disclosing the async contract (returns forecast_id/queued/eta_s in under a second, 1-3 min to done), cost ($0.25/call, ~70 LLM calls), the require_verified HTTP 422 no-charge behavior, and the commitment_hash committed before resolution. This is unusually rich 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?

Dense but nearly every sentence carries load (examples, pipeline, async contract, cost, result fields, alternative). It is somewhat long and the async mechanics sit mid-paragraph rather than front-loaded, which is the only real cost.

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?

With no output schema, the description compensates by enumerating the return fields (probability, ci80, base_rate, edge, drivers, panel, commitment_hash, etc.), and it covers cost, timing, polling, and the failure path. An agent has everything needed to call and interpret this tool.

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 already high (89%), but the description adds real meaning: it explains that interventions inject a shock into the simulated society and demonstrates the {round, news, audience} shape, clarifies method routing vs. forcing, and describes require_verified's refusal semantics beyond the schema text.

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 ('get a calibrated probability for a yes/no market question') with concrete examples, and explicitly distinguishes itself from siblings by naming oracle_get for polling and oracle_board for standing forecasts. An agent can route correctly without opening any 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?

Gives explicit when-to-use ('ask a NEW binary question'), the follow-up workflow (poll oracle_get every ~20s until status=done), and the alternative for a different use case ('For today's standing forecasts use oracle_board'). Nothing is left to inference.

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

All Degenscan Intel 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