Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Filings Intel MCP What are the recent insider transactions for Tesla?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SEC EDGAR for AI agents — as MCP tools your agent can call mid-task to research a US public company's filings, financials and insider activity. No API keys.
Tool | What it does | Source |
| Find a company's CIK and metadata by name or ticker | SEC EDGAR |
| List a company's most recent filings, filterable by form type (10-K, 8-K, ...) | SEC EDGAR |
| Full-text search across EDGAR filings | SEC EDGAR |
| Key XBRL financial facts (revenue, net income, assets, ...) for a company | SEC EDGAR |
| Recent Form 3/4/5 insider buys and sells | SEC EDGAR |
No API keys required.
Related MCP server: Aegis Gov SEC Filings MCP
claude mcp add --transport http filings-intel https://filings.datakoot.com/mcpOr point any MCP client at https://filings.datakoot.com/mcp.
Paste this into a terminal:
curl -s https://filings.datakoot.com/mcp \
-H 'content-type: application/json' \
-H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "recent_filings", "arguments": {"query": "Tesla"}}}'You get Tesla's most recent SEC EDGAR filings, straight from the source — no API key, nothing to sign up for.
Or point any MCP client at the URL and just ask your agent, in plain language:
"What did Tesla just file with the SEC?"
"Pull Apple's latest financials and insider transactions."
All data comes from the SEC EDGAR system (US Securities and Exchange Commission), which is US-government public domain. Requests are made with an identifying User-Agent per SEC's fair-access policy. Informational only — not investment advice.
Part of Datakoot — keyless intelligence APIs for AI agents.
Resolve a stock ticker or company name to its SEC identity: CIK number, official name, ticker(s), exchange(s), industry (SIC), and fiscal year end. Start here before other Filings Intel calls.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Ticker (e.g. AAPL), company name, or CIK |
| Name | Required | Description |
|---|---|---|
| cik | No | |
| ein | No | |
| sic | No | |
| name | No | |
| state | No | |
| tickers | No | |
| category | No | |
| industry | No | |
| exchanges | No | |
| provenance | No | Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at. |
| former_names | No | |
| fiscal_year_end | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying the identity fields a successful resolution yields, though it does not say what happens on an ambiguous or unmatched query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core verb and resource, followed by the return-field enumeration and the routing hint. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and annotations cover the safety profile, so the essentials are present for a one-parameter lookup. The only gap is behavior on unmatched or multiple-match queries, which an agent might need when the query is a bare company name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single required parameter, so the baseline is 3. The description restates 'stock ticker or company name' but omits the CIK input form that the schema explicitly supports, adding no meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (resolve) and resource (ticker/company name to SEC identity) and enumerates the exact output fields: CIK, official name, ticker(s), exchange(s), SIC, fiscal year end. This distinguishes it clearly from sibling tools like financials or insider_transactions, which consume the identity rather than produce it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Start here before other Filings Intel calls" gives explicit sequencing guidance that routes the agent correctly relative to its siblings. It stops short of naming individual alternatives (e.g., filing_search for document retrieval) or stating when this tool is unnecessary, but the workflow context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all EDGAR filings for a keyword or phrase (e.g. a risk factor, product name, or executive). Returns matching filings with company, form type, and date. Optionally restrict to a form type.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | Words or an exact phrase to find anywhere in EDGAR filing text, e.g. "going concern" or a product name. | |
| form_type | No | Optional form filter, e.g. 8-K |
| Name | Required | Description |
|---|---|---|
| query | No | |
| total | No | |
| results | No | |
| provenance | No | Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds a light behavioral note about what matches are returned (company, form type, date), but says nothing about pagination, ranking, or result limits beyond the schema default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, tightly front-loaded: scope first, return shape second, optional filter last. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't document return values, and annotations carry the safety profile. Parameter coverage is complete via the schema, so nothing an agent needs to call this search correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so query, limit, and form_type are already documented in the schema. The description only restates the form-type filter ('Optionally restrict to a form type') without adding syntax, matching behavior, or default details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Full-text search across all EDGAR filings') and clarifies it is keyword/phrase matching, not structured lookup. That implicitly separates it from recent_filings, but no sibling is named explicitly, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives examples of keywords ('a risk factor, product name, or executive') and notes an optional form filter, so usage is implied. However, it never says when to prefer this over recent_filings or company_lookup, and offers no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get reported financial facts for a company from XBRL data in its filings: revenue, net income, total assets, liabilities, equity, EPS, and cash — most recent reported values, or the full history of one specific us-gaap concept.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Ticker, name, or CIK | |
| concept | No | Optional specific us-gaap concept, e.g. Revenues, NetIncomeLoss, Assets |
| Name | Required | Description |
|---|---|---|
| cik | No | |
| note | No | |
| unit | No | |
| company | No | |
| concept | No | |
| history | No | |
| revenue | No | |
| provenance | No | Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at. |
| annual_only | No | |
| latest_reported | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds the authoritative source (XBRL data in the company's filings) and clarifies that values are as-reported rather than derived, which is useful context, but it says nothing about coverage gaps, rate limits, or fallback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with a clear verb and an em-dash separating fields from the mode distinction. Dense but every clause earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't describe return values, and it correctly focuses on scope and the concept-vs-default behavior for both parameters. It is essentially complete for calling the tool; only sibling routing is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that omitting 'concept' yields the most recent values while supplying one us-gaap concept returns full history, and names example concepts. That behavioral distinction is not derivable from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('reported financial facts for a company from XBRL data in its filings') and enumerates the concrete metrics returned. It distinguishes itself by domain (XBRL facts, not filings lists or entity identity), but never names a sibling tool to route against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause 'most recent reported values, or the full history of one specific us-gaap concept' implicitly tells the agent the two usage modes and which one the optional concept parameter selects. However, there is no explicit when-to-use guidance versus siblings like company_lookup or recent_filings, so the routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent insider ownership filings (Form 3/4/5) for a company — the filings officers, directors, and 10% owners submit when they buy or sell shares. Returns the filings with dates and links.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | Ticker, name, or CIK |
| Name | Required | Description |
|---|---|---|
| cik | No | |
| note | No | |
| company | No | |
| filings | No | |
| provenance | No | Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds domain framing (Form 3/4/5 and who submits them), but says nothing about freshness, lookback window, ordering, or pagination behavior beyond the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the action and resource, with the em-dash clause earning its place by defining the Form 3/4/5 jargon. No filler or redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations carry the safety profile; the description is therefore adequate for a simple two-parameter lookup. It is slightly thin on which sibling to prefer and on how far back 'recent' reaches, but nothing essential to calling it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents both params, including that query accepts ticker, name, or CIK and that limit defaults to 15. The description adds no syntax, matching, or formatting detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List recent insider ownership filings (Form 3/4/5)') and even defines who files them, so the agent knows exactly what this returns. It does not, however, differentiate itself from the close siblings recent_filings and filing_search, which an agent could reasonably confuse for this data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — the agent can infer it should call this when it needs insider buy/sell activity, but there is no explicit when-to-use, no prerequisite, and no routing away from recent_filings or filing_search. With two similarly named filing-oriented siblings, the absence of a disambiguating statement is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a company's most recent SEC filings (10-K annual reports, 10-Q quarterly, 8-K material events, S-1 IPO registrations, etc.) with filing dates and direct document links. Optionally filter by form type.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | Ticker, name, or CIK | |
| form_type | No | Optional filter, e.g. 10-K, 10-Q, 8-K, 4 |
| Name | Required | Description |
|---|---|---|
| cik | No | |
| count | No | |
| company | No | |
| filings | No | |
| provenance | No | Where this answer came from. served_at is when Datakoot answered (UTC); upstream lists the official sources consulted. Datakoot may serve a briefly cached copy, so the source's own observation can be older than served_at. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds the nature of returned content (filing dates, direct document links), but says nothing about result ordering, pagination, or rate limits. With annotations doing the heavy lifting, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the primary action and returned content come first, the optional filter last. No filler, no repetition of the title, and no information an agent has to hunt for.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return structure, and it correctly focuses on scope and the optional filter. The only meaningful gap is the absence of any routing signal against the closely named sibling 'filing_search'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented in the schema. The description restates the optional form_type filter and gives examples (10-K, 10-Q, 8-K, S-1), but adds no new syntax or format constraints beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (List) and resource (company's SEC filings) with concrete examples of form types and stated return content (dates, document links). However, it never differentiates itself from the sibling 'filing_search', which sounds like the same resource and could easily be confused with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'most recent' and 'Optionally filter by form type', so an agent can infer this is for listing a company's latest filings with an optional form narrowing. It offers no explicit when-to-use versus 'filing_search' or 'financials', nor any prerequisite or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.1.0company_lookupfiling_searchfinancialsinsider_transactionsrecent_filingsScored across 5 tools
Each tool targets a distinct facet: identity resolution (company_lookup), financial facts (financials), insider forms (insider_transactions), per-company filing lists (recent_filings), and keyword search (filing_search). The only mild overlap is between recent_filings and filing_search (both return filing lists) and insider_transactions vs recent_filings, but descriptions clearly separate per-company listing from full-text search and specialized insider forms.
All names use consistent snake_case, which is the important factor. The style varies slightly between bare nouns (financials) and noun_noun compounds (company_lookup, filing_search, insider_transactions, recent_filings), but overall the set reads predictably.
Five tools is a lean but reasonable scope for an SEC filings intel server, covering lookup, listings, search, financials, and insider activity. It is slightly thin — a document-retrieval tool would round it out — but nothing feels redundant.
Core lifecycle is covered: resolve identity, list filings, full-text search, pull financial facts, and inspect insider transactions. The main gap is that no tool returns filing document content/sections directly, though the returned links mitigate this since agents can fetch documents externally.
SEC EDGAR financials, insider trading, and economic data for AI agents. US GAAP + IFRS.
SEC filings and financial data for AI agents: 59 tools for statements, valuation and supply chains.
Agent-native SEC data, 20 tools: statements assembled, any line item, filings synthesized. No key.
SEC EDGAR fundamentals as agent tools: look up or screen US public companies. Free, no key, CC0.
