Most articles about AI agents and financial data skip the boring part. They show a chat window, a confident answer, and a chart. They do not show what the agent actually called, what came back, or what it could not know. This piece does the opposite. It walks through how an agent reads SEC filings through the Model Context Protocol (MCP), using the two tools on our server that work without a key. If you only want to verify that the data is real before paying for anything, that is the whole point of the free tier.
This is not investment advice. It is a description of plumbing.
What MCP is, in one paragraph
MCP is an open protocol that lets a language model call tools exposed by a server. The client, such as Claude Desktop or an editor plugin, connects to a server. The server advertises a list of tools with names, descriptions and input schemas. The model picks a tool, fills in the arguments, and receives structured output. That is it. There is no magic understanding of filings. The agent is only as good as the tools it can call and the records those tools return. The protocol itself is documented at modelcontextprotocol.io, and it is worth reading the tools section before trusting any vendor's description, including ours.
Where the filings come from
Every SEC record on our server traces back to EDGAR. The SEC publishes filings as raw documents and also as structured JSON through its own APIs, described on the EDGAR application programming interfaces page. Anyone can use those endpoints for free. The SEC asks for a declared User-Agent header and sets a fair access rate limit, which it explains on its accessing EDGAR data page. If your agent only needs one company's filing index, you do not need us. Point it at EDGAR directly.
Congressional trades come from a different place. House members file periodic transaction reports with the Clerk, and those are published on the House Clerk's financial disclosure site. The filing deadline and the STOCK Act behind it are covered in our piece on the 45-day rule, so I will not repeat the mechanics here. The end-to-end path from a trade to a public PDF is in how congressional trading disclosures work.
The reason to put a server between the agent and these sources is not access. It is normalization. EDGAR gives you a Form 4 as XML and a 13F as a different XML. The House gives you a PDF. An agent that has to parse all three on every question will burn tokens and make mistakes. A server that has already parsed, scored and timestamped the records lets the agent ask a question in one call.
Step one: connect without a key
Our Events MCP server runs hosted on Apify. There is nothing to install locally. Add the endpoint to your client's MCP configuration and the client will fetch the tool list on startup.
Two tools answer without any credentials.
The first is list_event_types. It returns every stream the server knows about: SEC insider transactions, 13D and 13G ownership filings, 13F holdings, 8-K current reports, Form D offerings, FDA actions, clinical trial updates, NIH grants, federal contracts, congressional trades and hiring signals. For each stream it tells you how many events exist, which fields a record carries, the formula version used for scoring, and whether the score inputs are complete for that stream.
The second is feed_health. It returns how old each source is right now. This matters more than it sounds. Filings are not real time. Our SEC sources refresh once a night. Congressional trades refresh weekly. Institutional holdings refresh quarterly because that is how often the SEC receives them, a lag explained in 13F deadlines and the 45-day lag. An agent that does not check freshness will happily present a stale record as current.
A sensible first prompt to your agent is simply: call feed_health and tell me which streams are more than two days old. The answer requires no key and tells you whether the server is alive and honest about its own age.
One practical note. The server sleeps when nobody is using it. A first connection can take a few seconds while it starts. If your client times out on the first tool call, retry once.
Step two: see what a record looks like
Before paying, you want to know what a scored record contains. Use list_event_types and ask the agent to print the field list for the insider stream.
Every record carries three things that most data vendors leave out.
scored_on is the timestamp when the score was computed, separate from the filing date. If the score was computed before a correction was filed, you can tell.
score_inputs lists the raw values that went into the score, together with the formula version. If a formula changes, the version number changes. An agent comparing two records from different months can see whether the scores are comparable.
proof is a reference into a published hash chain. The chain is written daily and anchored with OpenTimestamps. The record does not assert that it existed on a given day. It points to a chain entry that can be checked independently.
Where a source does not supply an input, the record says inputs_complete: false. It does not fill in a plausible value. For a Form 4 this often means a missing price field in the original filing, which is common for gifts and certain option exercises. For a House disclosure it usually means the member reported a range instead of an exact amount, which is what the form requires. If you want to read a raw Form D the same way, how to read a Form D filing walks through the fields.
Step three: the tools that need a key
Five tools require a key set as DATASIGNALS_KEY in the client configuration.
search_events takes filters such as stream, date range, ticker and minimum score. company_events returns everything for one issuer across streams. get_event fetches one record by id, including the proof reference. usage reports what the key has consumed. check_setup confirms the key is valid and the client is configured correctly.
A realistic agent session looks like this. The user asks what insiders at a given company have done in the last quarter. The agent calls company_events with the ticker and a date range. It receives a list of Form 4 records with scores and inputs. It then calls get_event on the two or three records with the highest scores and reads the score_inputs. It reports the transactions, the scores, the formula version, and whether any inputs were missing. If the user asks why a score is high, the agent can answer from the inputs instead of guessing.
What the agent cannot do is tell you whether the trade was a good idea. The score measures how unusual a filing is against a defined baseline. It does not predict price.
Honest limits
The server is not a substitute for reading the filing. A high-scoring 8-K record tells you an unusual event was filed. The agent still needs to open the document on EDGAR to understand it. Our records include the accession number so that step is one call away.
Scoring is deterministic and versioned, but it is still our formula. Another vendor, or your own script against the EDGAR API, will produce different numbers. The point of publishing the inputs and version is that you can disagree with the formula on specific grounds.
Rate limits apply to the keyed tools. The free tools are not rate limited beyond what Apify imposes, but they also return no event records, only metadata about the streams.
Congressional data depends on what members file and when. The STOCK Act sets the obligation, and what the STOCK Act actually requires covers the detail. Late filings exist. The server records the filing date and the transaction date separately so the agent can compute the gap, but it cannot surface a trade that has not been filed.
Free alternatives
If your agent only needs SEC data, the EDGAR APIs linked above are free and well documented. The SEC's full-text search covers filings since 2001. The House Clerk publishes disclosures as PDFs with a searchable index. Several open source projects on GitHub wrap EDGAR in an MCP server. None of them score, timestamp or hash-chain the records, which is the specific thing we charge for. If you do not need those three properties, use the free sources.
Where to go from here
If you want to see what the scored 13F stream looks like before connecting an agent, the Smart-Money 13F Consensus report shows the same records in a readable form, with the formula version and the proof reference on every row. It is the fastest way to decide whether the scoring is useful for your question before you set DATASIGNALS_KEY and let an agent loose on it. Start at the Smart-Money 13F Consensus report.
Want the signal instead of the raw filings? Get a free report preview. Prefer the tool to the write-up? Browse all data feeds or connect the free MCP server.