Public.com MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

get_price_history

Read-only

Retrieve historical OHLCV price bars for a symbol over a chosen period, including session splits and previous close, to analyze trends and review past prices.

Instructions

Get historical OHLCV price bars for a symbol over a time period.

Returns open/high/low/close/volume bars split into pre-market, regular, and after-hours sessions, plus previous close and total gain/loss. Use this for trend analysis and historical prices — get_quotes returns the current price only, and get_history is account activity, not prices.

Args: symbol: Ticker symbol (e.g. "AAPL"). period: Time window to retrieve (e.g. "YEAR", "TEN_YEARS", "ALL"). instrument_type: EQUITY, CRYPTO, OPTION, INDEX, or EVENTCONTRACT. Default EQUITY. To chart several contracts of one event side by side, get_event_contract_bars is usually the better fit. aggregation: Optional bar size. Prefer omitting it — the server then picks an appropriate size for the period. Only a subset of sizes is valid per period (finer/coarser sizes are rejected); if you set an invalid one, the error lists the valid options. purchase_date: Required only when period is "SINCE_PURCHASE". Format "YYYY-MM-DD". trading_session_toggle: Which sessions to include on the DAY equity chart. Omit for the default (REGULAR_AND_EXTENDED_HOURS, 04:00–20:00 ET). REGULAR_HOURS limits to 09:30–16:00. ALL_SESSIONS returns a full midnight-to-midnight chart including the overnight ATS sessions, adding preMarketOvernight (00:00–04:00) and postMarketOvernight (20:00–24:00) to the response. ipo_date: Optional IPO / first-trade date of the asset. Format "YYYY-MM-DD". When the asset is younger than the requested period, the server fetches a finer aggregation over the available post-IPO history (so the chart isn't a straight diagonal) and adds a leadingFill object to the response describing the flat lead-in to draw for the pre-IPO portion (startTimestamp, endTimestamp, value, count, includedInTotalExpectedBars). Omit for unchanged behavior. Ignored for the DAY chart; leadingFill is also never emitted for the ALL / SINCE_PURCHASE periods.

Input Schema

TableJSON Schema

Name	Required	Default
`period`	Yes
`symbol`	Yes
`ipo_date`	No
`aggregation`	No
`purchase_date`	No
`instrument_type`	No	EQUITY
`trading_session_toggle`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.8.0Oct 16, 2026

changedInput schema / properties / instrument_type / enum

Previous value: -[
-  "EQUITY",
-  "CRYPTO",
-  "OPTION",
-  "INDEX"
-]New value: +[
+  "EQUITY",
+  "CRYPTO",
+  "OPTION",
+  "INDEX",
+  "EVENTCONTRACT"
+]

Changed1 schema field changedv0.6.1Aug 12, 2026

addedInput schema / properties / ipo_date

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Ipo Date"
+}

Addedv0.4.0Jul 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare read-only/no-destructive, so the bar is lower, yet the description adds substantial behavioral context beyond them: the response structure (bars split into pre-market/regular/after-hours, previous close, total gain/loss), aggregation rejection behavior that lists valid options on error, the leadingFill object semantics, and the DAY-chart session toggle boundaries. This is rich disclosure not captured by structured fields.

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 routing are front-loaded before the Args block, and each parameter entry earns its place given 7 params and 0% schema coverage. It is long, but the length is largely warranted by the complexity; a few sentences (e.g. the full leadingFill key list) could be trimmed.

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 7-parameter tool with 0% schema coverage but an existing output schema, the description covers every parameter, the routing decision, and the non-obvious server-side behaviors. Nothing an agent needs to invoke it correctly is missing.

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 does: it documents every parameter's meaning, formats (symbol, date 'YYYY-MM-DD'), defaults, conditional requirements (purchase_date only for SINCE_PURCHASE), and non-obvious edge behavior (invalid aggregation error, ipo_date fetch strategy, trading_session_toggle session windows).

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+scope: 'Get historical OHLCV price bars for a symbol over a time period.' It explicitly distinguishes itself from get_quotes ('current price only') and get_history ('account activity, not prices'), so 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?

Explicitly gives when-to-use ('trend analysis and historical prices') and names two sibling tools to avoid, plus a third alternative for a sub-case ('to chart several contracts of one event side by side, get_event_contract_bars is usually the better fit'). This is exactly the when/when-not/alternatives pattern.

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

Deploy Server