← Back to Enterprise.AI
Accelerator · Model Context Protocol

MCP Data Agent — SEC EDGAR

Every other prototype here shows an agent doing a task. This one shows the layer underneath — how a model reaches a data source it has never seen before, and what it has to be told before the answer can be trusted.

5
MCP Tools Exposed
5
Companies in Scope
8
Concepts per Filer
100%
Figures Tag-Traceable
◆
Real SEC data, served from a snapshot. These are genuine XBRL figures pulled from EDGAR company facts on — by a working MCP server, then bundled with this page so the tools respond without a live backend. Five companies only. Nothing here is invented, and nothing here is live — if a filer amends a statement tomorrow, this page will not know.

Company

Tool

Filings to return

Form type fixed to 10-K in this snapshot.

Select two or more companies above to build a peer set.

Pick a company and a tool, then call it.
The rendered tab reads the response; the other two show it untouched.

What just happened

A client that has never seen this server asks what it can do, and the server answers with typed tool definitions. No integration code is written on either side — that handshake is the whole point of the protocol.

STEP 1
initialize
Client and server agree a protocol version and exchange capabilities.
STEP 2
tools/list
The server returns each tool's name, description and JSON schema. This is how a model knows get_fundamentals takes a ticker.
STEP 3
tools/call
One tool, arguments matching the schema. The server does the work and returns content blocks.
STEP 4
Read the answer
Text comes back. What the caller does with it — including how honestly it renders gaps — is the part nobody else can do for you.

The same server runs over stdio as a subprocess or over HTTP as a service, and one flag switches between them. Every message above is identical either way. What is not identical is the security posture: over stdio the server inherits the trust of whoever launched it; over HTTP it is reachable by anything on the network and authentication, rate limiting and entitlement checks all become its problem. That distinction is where most enterprise MCP conversations should start.

Three decisions that make the data usable

Filers disagree on tags

The same economic concept is filed under different XBRL tags by different registrants. Revenue alone resolves through four candidates. The server tries them in priority order and records which one won — that tag travels with the number to the screen.

Missing is not zero

When no candidate tag resolves, the concept is reported unresolved and never as zero. Intuit files no separate depreciation and amortisation line. A pipeline that substituted zero there would produce an EBITDA that is simply wrong, and would look entirely plausible doing it.

Abandoned tags go stale

A filer that stops using a tag leaves its last value in the fact set forever. Adobe's non-current debt still resolves to a 2009 figure. Presented next to current numbers it reads as current, so anything far behind the reference period is flagged rather than shown unqualified.

And one honest limit

EDGAR carries no share price and no market capitalisation. Enterprise value, EV/EBITDA and P/E cannot be produced from this source at all. Naming what a dataset cannot do is worth more than any number it can.

Considering MCP for your institution?

The interesting questions are not about the protocol. They are about entitlements, audit trails, and which of your systems should be a server at all.

Book a briefing →

Source data: SEC EDGAR XBRL company facts, public domain. Enterprise.AI · Riyadh · Doha · Dubai · London