Public.com MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

get_event_details

Read-only

Retrieves full details for a prediction-market event contract, including outcomes, YES/NO pricing, trading timeline, and CFTC terms to support event analysis.

Instructions

Get full details for one event contract (prediction-market event).

Returns the event's outcomes (each with its floorStrike when it has one), the YES/NO contracts for each outcome with current pricing (bid, ask, last, probability, open interest, daily gain), the trading timeline (open, close, expected expiration, settlement), and the CFTC contract terms. Prices are in dollars between 0.00 and 1.00 and equal the implied probability. Outcome ids carry no exchange prefix (e.g. "KXBALANCESHEET-EO26-6.6"); contract symbols do.

Each outcome also carries shortcuts derived by the SDK: tradable (open, in BUY_AND_SELL mode and before its close time — state alone can still read STATE_OPEN after close), secondsLeft until close, and once settled YES or NO, winner (the contract symbol that paid out). The event carries series, its series ticker.

Args: event_symbol: The eventSymbol from get_event_summary, e.g. "KALSHI.KXBALANCESHEET-EO26". Not the "-EVENT" id that get_event_contract_bars takes. An unknown eventSymbol returns an error with code 7004. include_all_outcomes: True (default) returns every outcome; False returns a short list of up to 8. outcomeCount always reports the full total.

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": {
      "event_symbol": "<event_symbol>"
    },
    "name": "get_event_details"
  }
}

Input Schema

Name	Required	Description	Default
`event_symbol`	Yes
`include_all_outcomes`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.8.0Oct 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover read-only/non-destructive, but the description adds substantial context beyond them: prices are dollars 0.00–1.00 equal to implied probability, outcome ids lack exchange prefixes while contract symbols carry them, and unknown eventSymbols return error code 7004. It also discloses SDK-derived fields (tradable, secondsLeft, winner) and the subtlety that raw state can still read STATE_OPEN after close — behavior an agent could not infer from the schema.

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?

Purpose and the highest-value caveat (which symbol id to pass) are front-loaded, and the Args block is clean. However, a large share of the text enumerates return payload fields even though an output schema exists, which is work the structured data already does; trimming that would sharpen the definition without losing routing information.

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?

An output schema exists, so return values need not be restated; combined with the read-only annotations, the description still supplies the semantic layer (pricing units, id formats, error code, truncation behavior) an agent needs to call this correctly. Nothing material is missing for a two-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden and it does: event_symbol is documented by source (get_event_summary), example format, anti-pattern (not the '-EVENT' id), and failure mode (error 7004). include_all_outcomes is documented with its default (True), the behavior when False (short list of up to 8), and the invariant that outcomeCount always reports the full total.

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 and resource ('Get full details for one event contract'), with the parenthetical clarifying what a prediction-market event is. It is clearly distinguishable from siblings: it names get_event_summary as the source of the symbol and get_event_contract_bars as the tool that takes a different id, so an agent can route without opening schemas.

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?

Routing is effectively spelled out through the argument guidance — call get_event_summary first, take its eventSymbol, and do not reuse the '-EVENT' id consumed by get_event_contract_bars. It also explains when to set include_all_outcomes to false. It stops short of an explicit 'use this instead of get_event_summary when…' statement, so it is not a full 5.

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

Deploy Server