Public.com MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

get_event_summary

Read-only

Browse prediction-market events page by page and filter by category, frequency, resolution time, volume, or creation date to discover event symbols for deeper details.

Instructions

Browse event contracts (prediction-market events), one page at a time.

Returns up to 100 events per page, each with its eventSymbol, title, volume, resolution time, resolved/halted flags, category, related instrument symbols (e.g. BTC-CRYPTO; often empty — these are NOT the event's contracts), and series, the series ticker of a recurring market (e.g. "KXBTC15M"; derived from the eventSymbol, pass it to get_current_event). Pass an eventSymbol to get_event_details for its outcomes, YES/NO contracts and pricing. Results can include resolved and halted events. When the response carries a nextToken, call again with the same arguments plus that next_token to fetch the next page; it is absent on the last page.

eventSymbol (e.g. "KALSHI.KXBALANCESHEET-EO26") is the discovery identifier. It is NOT the "-EVENT" id that get_event_contract_bars takes.

Args: sorting_mode: VOLUME (default), EXPIRATION, or RECENTLY_ADDED. category: Only events in this category (from get_event_categories). subcategory: Only events in this subcategory. event_symbols: Only these events, by eventSymbol. frequencies: Only events recurring at these frequencies. Any of ALL, ONCE, FIFTEEN_MINUTES, ONE_HOUR, ONE_DAY, ONE_WEEK, ONE_MONTH, ONE_YEAR. resolution_time_start: Only events resolving at or after this ISO 8601 timestamp (e.g. 2026-12-31T00:00:00Z). resolution_time_end: Only events resolving at or before this ISO 8601 timestamp. display_resolved_events: Include (true) or exclude (false) resolved events. Omit for the API default. created_within_days: Only events created within the last N days. next_token: The nextToken from the previous page, to fetch the next one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Default
`category`	No
`next_token`	No
`frequencies`	No
`subcategory`	No
`sorting_mode`	No	VOLUME
`event_symbols`	No
`created_within_days`	No
`resolution_time_end`	No
`resolution_time_start`	No
`display_resolved_events`	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

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description adds real behavioral value: 100-item page cap, resolved and halted events being included, the warning that related instrument symbols are often empty and are NOT the event's contracts, and how `series` is derived. The one omission is that it doesn't note whether display_resolved_events interacts with the resolved-events-included note, but overall this is well beyond the annotation bar.

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?

Front-loaded with purpose and return shape, then pitfalls, then a clean Args block; nearly every line earns its place. Slightly verbose where it restates the eventSymbol identifier warning across multiple sentences, but the redundancy is mild and useful given zero schema descriptions.

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?

For a 10-parameter, paginated discovery tool this covers what an agent needs: what a page contains, how to continue, what the identifiers mean, and which siblings to call next. An output schema exists, so explaining return values in depth isn't required — the description supplies the identifier caveats instead, which is the right thing for it to spend words on.

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 carries the full burden — and it does, documenting all ten parameters including acceptable frequency values, ISO 8601 format for the resolution windows, the source of category (get_event_categories), and the pagination contract for next_token.

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?

Opens with a specific verb and resource: "Browse event contracts (prediction-market events), one page at a time." It further disambiguates the identifier space (eventSymbol vs the "-EVENT" id used by get_event_contract_bars) and routes to get_event_details and get_current_event, so an agent can tell it apart from siblings 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 Guidelines5/5

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

Gives explicit downstream routing ("Pass an eventSymbol to get_event_details for its outcomes, YES/NO contracts and pricing") and complete pagination instructions (call again with the same arguments plus next_token; token absent on the last page). Defaults and enumerated values for sorting_mode and frequencies are stated as well, leaving nothing to inference.

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

Deploy Server