ChatGPT Market Data: How to Connect Actions, MCP, and REST

Why ChatGPT has no market data of its own

A language model is a compression of its training data, not a terminal. Ask vanilla ChatGPT what a fund held last quarter and it will answer fluently, because it has read thousands of articles about that fund, and confidently, because fluency is what it optimizes for. Whether the position still exists is another matter entirely. Filings data is particularly unforgiving here: portfolios turn over every quarter, insiders trade every week, and a model trained months ago has no mechanism to know any of it.

The failure mode is not "I don't know." It is a plausible, specific, wrong number with no citation attached, which is worse than no answer. That problem is architectural, so the fix is too: give the model a tool that returns real, sourced records at answer time, and instruct it to answer from the tool instead of from memory. We covered the general pattern in how to stop AI hallucinating market data; this guide is the ChatGPT-specific setup.

ChatGPT supports the tool pattern in three different wrappers. They look different in the UI, but they are the same idea underneath: somewhere, an HTTP request goes out carrying a bearer key, structured JSON comes back, and the model reasons over that JSON rather than over its training set.

Three ways to connect, compared

The decision is mostly about who owns the integration: ChatGPT's UI, the protocol layer, or your own codebase. Each step right gains control and costs convenience.

If you only ever ask questions interactively, a custom GPT action is the least friction: configure once, then chat. If you are building agents, MCP is the cleaner abstraction, because the server publishes its own tool catalog and you never hand-maintain a schema as endpoints evolve. If you are shipping software to other people, take the REST path, because you control retries, caching, logging, and exactly what the model is allowed to see. The trade-offs between the last two are subtle enough that we wrote a separate MCP vs REST API comparison.

One thing that does not change across paths: the data source authenticates with a single key, and the quality of your answers is capped by the quality of what that key unlocks.

Path 1: a custom GPT action with a bearer key

Custom GPTs accept "actions": you paste an OpenAPI schema describing HTTP endpoints, and ChatGPT decides when to call them mid-conversation. For authentication, choose the API key option with the Bearer scheme. ChatGPT stores the key on the builder side and attaches it to every request, and people chatting with your GPT never see it. That also means every user of your GPT spends against your key, so treat a shared GPT like a shared budget.

Before wiring anything into a schema, verify the endpoint by hand:

curl -H "Authorization: Bearer YOUR_KEY" \
  "https://arkolith.com/api/v1/search?q=berkshire"

Minting a key takes a couple of minutes via the quickstart. Two practical notes from building these. First, the model decides when to invoke an action based on the schema's description fields, so write them like instructions to a junior analyst ("use this to resolve a fund name to its CIK before requesting holdings"), not like terse API docs; vague descriptions produce a GPT that answers from memory instead of calling the tool. Second, keep responses small and structured: actions have payload limits, and the model reasons better over twenty relevant rows than two thousand raw ones. Agent-oriented endpoints paginate and rank results for exactly this reason.

The main limitation is reach. A custom GPT lives inside the ChatGPT interface; you cannot embed it in your product or control its orchestration loop. For interactive research that is fine. For anything programmatic, keep reading.

Path 2: MCP connectors

Model Context Protocol is the emerging standard for handing tools to models. Instead of you describing endpoints in a schema, the server describes itself, and any MCP client can discover and call its tools. ChatGPT has been rolling MCP support into its connector system, and the OpenAI API exposes a hosted MCP tool so server-side applications can attach remote MCP servers directly. Availability differs by plan and changes often, so check OpenAI's current documentation for what your account exposes. If the concept is new, start with what an MCP server is.

Arkolith's MCP server lives at https://arkolith.com/api/mcp and authenticates with the same bearer key as the REST API. Once attached, you stop thinking in endpoints. You ask "which funds added Nvidia last quarter," and the agent picks the right tool, pages through results, and carries each number's source along with it. If you also work in Claude, the setup there is a one-line command against the identical server; the Claude-side walkthrough covers it, and nothing about the data differs between clients.

The honest trade-off: MCP support in ChatGPT is newer plumbing than custom GPT actions. When a connector misbehaves, debugging is more opaque than reading your own request logs, and plan-level gating can surprise you. If reliability matters more than convenience, the REST path gives you full visibility into every call.

Path 3: plain REST from your own code

This is the path for anything you ship. Use OpenAI's tool calling: define a function such as get_fund_holdings(cik), let the model emit a call, execute the HTTP request server-side, and return the JSON as the tool result. The model never touches your key; your backend does.

The surface is deliberately small. List institutional filers:

curl -H "Authorization: Bearer YOUR_KEY" \
  "https://arkolith.com/api/v1/funds"

Pull a specific fund's holdings by CIK (here, Berkshire Hathaway). Starting from a fund name instead? Resolve it to a CIK with the search endpoint first:

curl -H "Authorization: Bearer YOUR_KEY" \
  "https://arkolith.com/api/v1/funds/1067983/holdings"

The full endpoint reference is in the docs. Three rules hold up in production. Keep the key server-side, always: a key pasted into a prompt or bundled into a client is a leaked key. Pass provenance through to the model: every record here carries the SEC EDGAR accession number of the filing it came from, and a model that can quote a source is far less inclined to invent one. And bound your own spend: Arkolith meters usage against prepaid credits rather than an open-ended invoice, so a runaway agent loop hits a wall instead of your card.

What you actually get, and where it stops

A connected ChatGPT is only as good as the data behind the tool, so be precise about what this data is. Arkolith's Q1 2026 13F dataset covers 1,824 institutional filers reporting 1.87 million long positions worth $53.7 trillion, alongside 51,000+ tracked insider transactions from Form 4 filings. Every datapoint resolves to an EDGAR accession number, which means any claim your agent makes can be checked against the SEC's own full-text search.

Know the latencies, because your agent should disclose them. 13F filings are due 45 days after quarter end (2026 deadlines: February 17, May 15, August 14, November 16) and only cover managers above $100 million in covered US equities; the SEC's Form 13F FAQ covers the mechanics. Institutional holdings are therefore a quarterly snapshot with a built-in lag, not a live position feed, and the academic record on extracting alpha from them is mixed; we go deeper in how accurate 13F data really is. Insider filings are much fresher: Form 4 is due within two business days of the trade, which is why insider activity on a page like Nvidia's can move within the week while the institutional view updates quarterly.

And know the gaps. Filings data will not give you live quotes or intraday prices, and a 13F does not require disclosure of short positions, most derivatives, or non-US listings. An agent that states those limits plainly is more useful, and more trustworthy, than one that papers over them.

Frequently asked questions about connecting ChatGPT to market data

Can ChatGPT access market data without any setup?

No. Out of the box the model answers from training data, which is months stale and uncited. Anything that looks like a current figure is reconstruction, not retrieval. You need to connect a tool (a custom GPT action, an MCP connector, or an API call from your own code) before answers reflect real records.

Should I use a custom GPT action or an MCP connector?

Use an action if you mainly work inside the ChatGPT UI and want a fast setup with a stored bearer key. Use MCP if you are building agent workflows or use multiple clients, since the server publishes its own tools and you skip schema maintenance. Both can hit the same backend with the same key, so switching later is cheap.

Is the connected data real-time?

The pipeline is live, but the underlying disclosures have legal lags: Form 4 insider trades arrive within two business days, while 13F institutional holdings are quarterly snapshots filed up to 45 days after quarter end. A well-built agent states the as-of date with every answer. None of this substitutes for a live price feed.

How do I keep ChatGPT from mixing real data with made-up numbers?

Instruct it to answer only from tool results and to cite the EDGAR accession number behind each figure. Keep tool responses compact so the relevant rows actually fit in context, and spot-check critical numbers against EDGAR before acting on them. Provenance-first prompting does not make a model perfect, but it makes fabrication easy to catch.

This article explains public filings and data concepts. It is not investment advice.