> ## Documentation Index
> Fetch the complete documentation index at: https://partners.centaur.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Public changelog for API and documentation updates.

<Update label="2026-08-18" description="Trader tags on trader stats" tags={["API", "MCP", "Docs"]}>
  ## Trader tags on trader stats

  * Trader stats rows (`GET /api/v1/traders/stats` and the `list_trader_stats` MCP tool) now include `tags`: editorial trader tags as `{ category, name }` pairs, lowercase, e.g. `{ "category": "thematic", "name": "ai capex buildout" }`.
  * The first shipped category is `thematic`: which macro themes a trader's book expresses (AI capex buildout, power and energy, critical metals and minerals, robotics, macro rotations, crypto). Categories are an open set and may grow without a version bump.
  * `tags` is always present and empty for untagged traders. Tag visibility follows the same trader visibility rules as the rest of the stats row.
</Update>

<Update label="2026-08-06" description="Partner feed" tags={["API", "MCP", "Auth", "Docs"]}>
  ## Partner Feed

  * Added `GET /api/v1/feed` and the `list_feed` MCP tool: presentation-ready source-message groups that embed the source preview, source identity, trader, and asset display fields needed for direct rendering, ordered by source-message post time.
  * Server-side curation removes fabricated events with no message evidence: assumed and GC-generated closes, instant opens fabricated at a position's close, and assumed opens siblinged with another event for the same message and asset. Lone inferred opens remain visible with `assumed: true`, and retrospective events remain flagged with `retrospective: true`.
  * `limit` counts source-message groups (default `20`, maximum `100`). `traderIds` and `assetIds` filters plus `startTime`/`endTime` bounds select groups by source-message post time.
  * `cursor` scrolls back through older groups. `since` is an ingestion-watermark change feed with whole-group upsert semantics: merge returned groups by `id` and replace each prior payload. The two parameters are mutually exclusive; persist the newest non-null `nextCursor` after every successful poll, including empty polls.
  * The feed uses the new `feed.read` scope on REST API keys and MCP OAuth connections. MCP connections authorized before the scope existed need one disconnect and reconnect to pick it up; API keys are unaffected.
  * Added the [Partner Feed guide](/docs/guides/rest/feed) and updated query-semantics, data-reads, and MCP docs for the new read family.
</Update>

<Update label="2026-07-06" description="Trader rankings and activity summaries" tags={["API", "MCP", "Docs"]}>
  ## Trader rankings and activity summaries

  * Added `GET /api/v1/traders/rankings` and the `rank_traders` MCP tool: server-side trader ranking by `event_count` (default), `position_count`, `win_rate`, `avg_return`, `median_return`, or `sharpe_ratio` over an explicit UTC time window, without supplying trader IDs.
  * Performance-metric rankings evaluate the `timeBasedPerformanceWindow` (default `7D`) and require `minPositions` evaluated positions (default 3); rows expose the evaluated sample size. Windows whose `startTime` is more recent than the evaluation window are rejected with a corrective `422` instead of returning a silent empty ranking.
  * Added `GET /api/v1/activity-summaries` and the `summarize_message_activity` MCP tool: deterministic message and event counts grouped by trader or overall, bucketed by hour, day, or week. Activity summaries are count evidence, not generated narrative summaries.
  * Both reads use the `stats.read` scope, default to the last 7 days, and return small bounded results (default limit 10, maximum 50) with no pagination. Activity summary requests above 168 buckets per group are rejected with `422`.
  * Updated MCP capabilities and filter-guide resources so ranking, count, and trend prompts route to the aggregate tools instead of paging `list_events`/`list_messages`.
</Update>

<Update label="2026-06-30" description="Trader discovery trade counts" tags={["API", "MCP", "Docs"]}>
  ## Trader discovery trade counts

  * Trader discovery rows now include `tradeCount`, the eligible visible position count for the discovery result.
  * `GET /api/v1/traders` and `list_traders` now accept `minTrades`, defaulting to `3`; pass `minTrades=0` for the full visible trader directory.
  * Trader discovery now accepts `startTime` and `endTime` to scope `tradeCount` and `minTrades` by position open time.
  * Updated REST, MCP, and platform docs to identify trader discovery as the supported source for discovery-level activity counts.
</Update>

<Update label="2026-06-25" description="Source-aware payloads" tags={["API", "MCP", "Docs"]}>
  ## Source-aware payloads

  * Message rows now expose source metadata under `source.identity` and message display data under `source.preview`.
  * The old flat message `url`, `text`, `attachments`, and `originalCreatedAt` fields were replaced by the nested source payload.
  * `source.platform` can be `TELEGRAM` or `X`, enabling platform-specific links, labels, avatars, and audience counts.
  * `GET /api/v1/messages`, `list_messages`, and delegated chat assistant message reads now accept `sourcePlatforms` for Telegram-only or X-only message feeds.
  * Trader discovery and trader stats rows now include one `source` identity, and their reads accept `sourcePlatforms`.
</Update>

<Update label="2026-06-24" description="Opaque source-message IDs and X-backed message reads" tags={["API", "MCP", "Docs"]}>
  ## Opaque Source Message IDs and X-backed message reads

  * Source Message IDs are now opaque identifiers returned by source-message views, not Telegram channel/message tuples.
  * `GET /api/v1/messages`, `list_messages`, and event `messageId` hydration use those opaque IDs through `ids`.
  * Source-message URLs may point to Telegram or X depending on the source platform.
</Update>

<Update label="2026-06-19" description="Product and contract documentation refresh" tags={["Docs", "Product", "API", "MCP"]}>
  ## Product and contract documentation refresh

  * Replaced the old Arena product page with current product-surface docs for Trader Discovery, Asset Discovery, Feed, Following, profiles, Assistant, and source transparency.
  * Added API-key, Connected Apps, and contract-limit guides for REST, MCP, and agent clients.
  * Clarified messages vs events vs positions, positioning vs performance, event classification flags, and time-based performance windows.
  * Updated REST docs to list generated channel and aggregate summary endpoints as first-class read families.
</Update>

<Update label="2026-06-13" description="Event and message contract compaction" tags={["API", "MCP", "Docs"]}>
  ## Event and message contract compaction

  * Event rows now return flat `type`, `positionId`, and `messageId` fields instead of `eventType`, nested `position`, or nested `source`.
  * Event reads now filter event kinds with `types`.
  * Message reads now hydrate Source Message IDs with `ids` and no longer expose `traderId` or event-derived filters.
</Update>

<Update label="2026-06-11" description="Generated narrative summary guidance" tags={["MCP", "Docs"]}>
  ## Generated narrative summary guidance

  * Clarified MCP and docs language for channel and aggregate summaries as generated narrative summaries.
  * Added guidance that generated narrative summaries are useful for market narratives but are not evidence for exact trade counts, public activity rankings, or current open-position skew.
  * Clarified that current positioning claims should use open-position reads.
</Update>

<Update label="2026-06-09" description="Position history reads" tags={["API", "MCP", "Docs"]}>
  ## Position History Reads

  * Replaced `GET /api/v1/positions/closed/valid` and `list_valid_closed_positions` with `GET /api/v1/positions` and `list_positions`.
  * Position history reads return open and closed positions by open time with `1D`, `7D`, and `30D` time-based performance.
  * Open-position reads continue to expose current marks and live mark-to-market returns.
</Update>

<Update label="2026-05-12" description="Centaur API naming" tags={["Docs", "MCP"]}>
  ## Centaur API naming

  * Updated user-facing copy to use “Centaur API” and “Centaur MCP”.
  * Updated examples to use a generic `<api-key>` placeholder.
</Update>

<Update label="2026-05-12" description="Channel summary trader IDs" tags={["API", "MCP", "Docs"]}>
  ## Trader-attributed channel summaries

  * Added top-level `traderId` to `GET /api/v1/channel-summaries` and `list_channel_summaries` results so clients can connect summaries from the same trader over time.
  * Channel summaries still do not accept trader or Telegram channel filters, and they do not return trader metadata, channel identity, or raw source material.
  * Generated aggregate summaries remain source-anonymous and unchanged.
</Update>

<Update label="2026-05-12" description="Open summary access" tags={["API", "MCP", "Auth", "Docs"]}>
  ## Summary access

  * Removed the separate Summary Entitlement row-returning gate from generated channel and aggregate summaries.
  * Summary reads still require `summaries.read` authorization through REST API-key permissions or MCP OAuth scopes.
  * New default Centaur API keys include `summaries.read`.
</Update>

<Update label="2026-05-11" description="Aggregate summaries" tags={["API", "MCP", "Docs"]}>
  ## Generated aggregate narrative summaries

  * Added `GET /api/v1/aggregate-summaries` and `list_aggregate_summaries` for cross-source generated aggregate narrative summaries.
  * Aggregate summaries use `summaries.read`, support Source Window-style overlap filtering, and default to `safe` summaries.
  * Public responses expose source coverage counts but not trader or channel identities.
</Update>

<Update label="2026-05-11" description="Open app access" tags={["Auth", "MCP", "Docs"]}>
  ## MCP OAuth eligibility

  * Changed MCP OAuth eligibility from existing active API-key ownership to an active Centaur account with a verified email.
  * REST remains API-key based, and generated summaries require normal `summaries.read` authorization.
  * Runtime reads now reject API-key and OAuth owners whose Core account later becomes blocked or unverified.
</Update>

<Update label="2026-05-09" description="Channel summary time filtering correction" tags={["API", "MCP", "Docs"]}>
  ## Source Window overlap filtering

  * Changed `GET /api/v1/channel-summaries` and `list_channel_summaries` so `startTime` and `endTime` select summaries whose Source Windows overlap the requested interval.
  * A Source Window now matches when `windowEnd` is after `startTime` and `windowStart` is before `endTime`.
  * This fixes daily summary reads so UTC day bounds return summaries covering that day instead of summaries selected only by their window end timestamp.

  ## Documentation and client guidance

  * Updated the OpenAPI descriptions, REST docs, MCP filter guide, and public skill guidance to describe Source Window overlap semantics.
</Update>

<Update label="2026-04-16" description="Messages feed semantics update" tags={["API", "MCP", "Docs"]}>
  ## Messages now default to feed semantics

  * Changed `GET /api/v1/messages` and `list_messages` to return eligible messages even when they have no linked extracted events.
  * Kept `assetIds`, `directions`, and `eventTypes` as filters that narrow messages through linked events when supplied.
  * Superseded on 2026-06-13: message reads now support Source Message ID hydration with `ids` plus time bounds, `limit`, and `cursor`; trader, asset, direction, and event-type filters are no longer part of the public message contract.

  ## Documentation and MCP guidance

  * Clarified the new message-feed behavior in the public docs, generated API reference, and MCP filter guidance resource.
  * Kept the response shape and pagination contract unchanged.
</Update>

<Update label="2026-04-08" description="Read surface expansion and contract cleanup" tags={["API", "MCP", "Docs"]}>
  ## Broader read surface

  * Expanded the documented and generated REST surface beyond events to cover messages, positions, and stats under `/api/v1`.
  * Expanded the documented MCP surface to cover the same read-only trading data families across events, messages, generated summaries, positions, discovery, and stats.

  ## Query and pagination updates

  * Removed `allTime` from the public date-range contract. Time-bounded reads now use `startTime` and `endTime`.
  * Standardized list-style reads on forward-only cursor pagination and documented the applied time bounds echoed back in relevant responses.

  ## Access and authentication behavior

  * Clarified that returned data can reflect current access and eligibility rules, so visible rows and available history can vary by caller context.
  * Hardened event pagination so paging remains stable even as the currently visible result set changes.

  ## Documentation and client guidance

  * Reframed the docs around a broader read-only trading data surface instead of an events-only product view.
  * Added a data-reads guide, aligned public skill guidance, and refreshed client setup docs to match the expanded REST and MCP surface.
</Update>

<Update label="2026-03-31" description="Docs refresh" tags={["Docs", "API"]}>
  ## Task-first onboarding

  * Reworked the homepage around access, path selection, and quickstarts for both REST and MCP.
  * Added concrete MCP setup guides for Claude Code, Cursor, and Codex.

  ## API reference improvements

  * Strengthened the generated OpenAPI-backed reference with richer examples and schema descriptions.
  * Kept Swagger available as a secondary technical artifact rather than the primary docs surface.

  ## Information architecture

  * Reworked the MCP/API docs around task guides, generated API reference, and changelog pages.
  * Moved public skills into a more clearly supplemental role within the docs.
</Update>