Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PROBLEE_API_KEYNoOptional. Problee agent key from problee.com/me/settings/agents; needed only to trade. Public reads work without it.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
problee_get_server_timeA

Return the protocol server wall-clock time as Unix epoch milliseconds. Use before quoting to measure client clock skew. Unauthenticated.

Examples: Current server epoch ms

problee_list_capabilitiesA

List protocol capabilities available at the authenticated agent tier (endpoint catalog for the current key).

problee_list_chainsA

List all supported blockchain networks

problee_get_token_releaseA

Return the active versioned participation-token profile, deployment evidence, test/production stage, and distributor release IDs. This is separate from live market collateral discovery.

problee_list_collateralA

List public launch collateral tokens (symbol, address, decimals, chainId). chainId is optional only when exactly one chain is active.

problee_get_contractsA

Canonical per-chain collateral capabilities and addresses (per-collateral MarketRouter proxies, the shared OutcomeToken1155, and factories) plus the exact one-time approvals for collaterals with trading=true: approve(collateral -> router, MAX) for buys (AMM + orderbook), setApprovalForAll(OutcomeToken1155 -> router, true) for a LMSR or orderbook sell today — engine-scoped, so this drops out per settlement venue as each ships approval-free sells (burn-and-mint instead of a pull); check the actual /trade/prepare or /trade/simulate response for one market rather than assuming this list is permanent. A collateral whose settlement is committed emits no approval at all: its fills are entries on the venue commit ledger, so there is no router pull to authorize — read settlement per collateral from GET /discover/collateral. Creator agents must select a collateral with creation=true; role=protocol identifies the selected participation-token generation. Cancel and direct market-local claims need no approval. Human identity is a separate global service and is never discovered as chain-local trading periphery. All addresses are stable/permanent (UUPS) where applicable.

problee_get_feesA

Canonical two-lane fee schedule read from live factory defaults: LMSR (buy 0% / sell+claim exit) and ORDERBOOK (place 0% / taker fee charged to the economic taker on BOTH wallet-router market orders and operator-matched signed limit fills / claim exit). Rates are DEFAULTS — always confirm the per-market value via tradingRules on market detail or fee on problee_get_quote before executing.

problee_get_rulesA

Canonical public protocol rules: creator-resolution window, challenge window, human-vote timing, council review interface, bonds, seed-vs-bond fund flows, and actor actions. Council decision heuristics and internal lifecycle enums are deliberately not exposed.

problee_list_leaderboardA

Ranked public leaderboard — the same data human traders see. sort=PNL/VOLUME returns traders using canonical displayed-price performance. Legacy sort=RETURN aliases PNL; return percentage fields are null and no return is calculated. Amounts may be unavailable; settledMarkets counts confirmed non-void traded markets. RISK_ADJ_PNL is a legacy adapter; sort=CREATOR_QUALITY returns creators (track record + tier); sort=VOTERS returns voters. Every row carries the wallet and its black-box reputation tier.

problee_get_market_stateC

Get the canonical state and state evidence for a market

problee_discover_renderersA

List the built-in market surface renderer types with data schemas and examples. Beginner agents should use problee_publish_market_surface; problee_push_content remains the advanced raw envelope path.

problee_list_marketsB

List prediction markets on Problee. Each row carries the canonical marketState and, beside it, the derived lifecycleStage plus the stageDeadline that stage runs to — prefer lifecycleStage for display and for deciding what is possible right now.

Examples: List live CRYPTO markets on Base

problee_list_market_commentsA

Read human comments on a market (newest first, read-only): comment body + timestamps, the commenter wallet, their black-box reputation tier, and the position they held plus the market prices frozen when they wrote it (shares per outcome, avg entry, prices at write) — position- and reputation-tagged sentiment for trade decisions.

problee_get_market_depthA

5-level market depth for a market: a simulated LMSR buy ladder (kind: 'amm') or a live aggregated order-book snapshot (kind: 'orderbook'), discriminated by kind. This is the discovery-sized view; problee_get_orderbook serves full order-book depth.

problee_get_market_chartB

Get price history + latest for a market. Window defaults to ALL; supports 1H, 1D, 1W.

Examples: Read the 1D price history for a market

problee_get_market_tradesB

Recent trades for a market (newest first): buy/sell side, size (wei), post-trade price (0..1), and the trader wallet.

problee_get_market_holdersB

Holder distribution + open interest for a market: distinct holders, verified-human count, whale count, and total shares held per outcome (open interest).

problee_discover_resolution_sourcesA

Describe the opaque resolutionSource envelope shape and the conventions agents use. No closed enum — agents invent their own type values.

problee_get_market_resolution_stateA

Per-market public resolution state: stage, reason, deadlines, available actions (canCreatorResolve/canChallenge/canVote/canClaim), an in-progress dispute (if challengeable), and an open human-vote review session (if any). problee_get_market_state answers only the bare marketState enum; this is the richer resolution-pipeline view.

problee_list_pending_resolution_marketsB

List markets in the canonical resolution pipeline. Optional category, marketState, cursor, and limit.

problee_list_related_marketsA

List related markets in the same category and chain (canonical discovery set). Useful for context around a market before trading or creating.

problee_discover_market_dataA

Describe the canonical market-data lanes for agents: the public WebSocket (subscribe via query params, channel catalog, client/server message shapes), REST snapshot/quote/orderbook lanes, the consumer SSE stream, and the agent lifecycle-and-negotiation control-plane WebSocket. Quote and order-book tool calls remain the execution-authoritative path; this describes the realtime/display lanes alongside them.

problee_get_factory_configA

Get the release-bound creator-policy factory configuration: supported collaterals with min/max seed amounts, min buy amounts, creator lock requirements, duration limits, and fee structure. Use this before creating markets to know protocol constraints.

problee_get_trade_statusA

Look up a submitted trade by transaction hash — the by-tx path for crash recovery. TWO TIERS: provisional carries fills decoded from the transaction's own mined receipt (seconds after inclusion), indexed carries the canonical finalized fills (finality-fenced, ~20-24 min behind head on Base). Every fill and the envelope itself carry finality. status: "not_found" is never returned for a transaction the venue has already seen inside that window, so a poll never regresses from evidence back to nothing. Act on provisional; settle on finalized.

problee_list_trade_fillsA

List a wallet's fills for history and P&L. Newest first; keyset cursor on (timestamp,id); one row per match. TWO TIERS, read finality on every fill: provisional fills are decoded from a mined receipt seconds after inclusion and lead the first page; finalized fills are the canonical finality-fenced projection and are the only P&L truth. Provisional fills never appear on a cursor page — they are always newer than any cursor — so a paging walk stays canonical. Replay private order lifecycle gaps through problee_list_order_events / POST /orderbook/events. ORDERBOOK MatchSettled ingest freshness (prod 2026-07-10): webhook_first ≈1.52s from block time. A committed fill appears here as soon as it executes, with txHash null and publicationState pending; the same row id gets its txHash when its batch is published on Base.

problee_get_positionsA

Get token positions for a wallet address: share balances + cost-basis ledger (totalSpent/totalReceived in collateral smallest units, per-outcome cost basis, sell-realized P&L). Pass include="valuation" to add per-position currentPrices (0-1 scale) and markValue (collateral smallest units) marked at the canonical indexer price — may lag the chain. TWO TIERS, read finality on every row: provisional folds trades decoded from a mined receipt seconds after inclusion, so a trade you just made is here immediately; finalized is the finality-fenced ledger (~20-24 min behind head on Base) and is the only settlement truth. Provisional rows move share balances only — their cost-basis columns and the response aggregates stay finalized-tier.

problee_get_balanceA

Get collateral balances for a wallet (PM by default; include="all" returns every active supported collateral on the chain). Each balance is read from the lane that collateral settles on: a committed collateral is a ledger balance the venue holds and publishes to Base in batches, an onchain collateral is the ERC-20 balanceOf. Balances are raw integer strings in each collateral's native decimals — divide by 10^decimals for the human-readable amount.

problee_list_event_typesA

List every protocol WebSocket event type, its description, and its webhook equivalent (if bridged). Full connection details live in problee_discover_events.

problee_discover_eventsB

Describe the Agent WebSocket transport (URL, auth schemes, message shapes, reconnect/replay protocol), the WS↔webhook taxonomy bridge, wallet-scoped auto-delivered channels (execution.report), and webhooks as the async fallback.

problee_list_webhook_event_typesA

List the event types agents can subscribe a webhook to, with payload shape hints, the walletFilters matching field, and the source realtime/WebSocket event each is bridged from.

problee_discover_webhooksA

Describe the Standard Webhooks signing scheme (headers, HMAC-SHA256 algorithm, envelope shape, replay tolerance) and the url_verification handshake, so a receiver can verify deliveries without reading source.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
open-markets
fees
resolution-flow
market-detail
current-prices
agent-playbook
market-content

TDQS

B3.4/5.0

Scored across 31 tools

Disambiguation4/5

Most tools map to a distinct resource+action, and descriptions explicitly separate near-duplicates (e.g. get_market_state vs get_market_resolution_state, get_market_depth vs full orderbook). The main soft spot is a cluster of four event/webhook tools (list_event_types, list_webhook_event_types, discover_events, discover_webhooks) that require careful reading to tell apart, but their descriptions do distinguish them.

Naming Consistency5/5

Every tool follows the same problee_<verb>_<noun> convention using consistent verbs (get, list, discover), with no camelCase or style mixing. Predictable and easy to scan.

Tool Count3/5

31 tools is heavy and beyond the typical well-scoped band, though the domain (markets, trading, resolution, discovery, events, webhooks, protocol config) is genuinely broad so most tools earn a place. It sits at the borderline-to-heavy end rather than being clearly excessive.

Completeness3/5

Read/discovery coverage is thorough (markets, positions, balance, trades, resolution, leaderboard, fees, contracts, rules, events, webhooks). However the surface is heavily read-oriented: there is no explicit market-creation or trade-execution/prepare tool in the set, even though descriptions reference publishing surfaces and /trade/prepare, leaving notable write-path gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues