SEC EDGAR filings for AI agents: company lookup, filings, financials, insider trades. No keys.
Scored across 5 tools
company_lookup and financials have clearly distinct purposes, but filing_search, recent_filings, and insider_transactions all return filing-related results. The descriptions distinguish keyword search, recent filing listing, and insider ownership filings, so boundaries are mostly clear though slightly overlapping.
All tool names use lowercase snake_case and are readable. The pattern is not uniformly verb_noun: company_lookup and filing_search include actions, while financials, insider_transactions, and recent_filings are noun phrases. This is a minor stylistic deviation rather than confusing inconsistency.
Five tools are well-scoped for a focused SEC filings intelligence server. Each tool covers a distinct research need: identity resolution, full-text search, financial facts, insider transactions, and recent filings.
The surface covers core SEC research workflows including company lookup, filing search, financial extraction, insider activity, and recent filings. It lacks direct retrieval of full filing text or parsed sections beyond search results and links, but agents can work around this via returned document links.
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.
company_lookup1 field changedOutput schema / properties / provenanceAdded value: +{
+ "description": "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.",
+ "properties": {
+ "may_be_cached": {
+ "type": "boolean"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "served_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "upstream": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}filing_search1 field changedOutput schema / properties / provenanceAdded value: +{
+ "description": "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.",
+ "properties": {
+ "may_be_cached": {
+ "type": "boolean"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "served_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "upstream": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}financials1 field changedOutput schema / properties / provenanceAdded value: +{
+ "description": "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.",
+ "properties": {
+ "may_be_cached": {
+ "type": "boolean"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "served_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "upstream": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}insider_transactions1 field changedOutput schema / properties / provenanceAdded value: +{
+ "description": "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.",
+ "properties": {
+ "may_be_cached": {
+ "type": "boolean"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "served_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "upstream": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}recent_filings1 field changedOutput schema / properties / provenanceAdded value: +{
+ "description": "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.",
+ "properties": {
+ "may_be_cached": {
+ "type": "boolean"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "served_at": {
+ "format": "date-time",
+ "type": "string"
+ },
+ "upstream": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}company_lookup1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "category": {},
+ "cik": {},
+ "ein": {},
+ "exchanges": {},
+ "fiscal_year_end": {},
+ "former_names": {},
+ "industry": {},
+ "name": {},
+ "sic": {},
+ "state": {},
+ "tickers": {}
+ },
+ "type": "object"
+}filing_search2 fields changedInput schema / properties / query / descriptionPrevious value: -"Search phrase"New value: +"Words or an exact phrase to find anywhere in EDGAR filing text, e.g. \"going concern\" or a product name."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "query": {},
+ "results": {},
+ "total": {}
+ },
+ "type": "object"
+}financials1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "annual_only": {},
+ "cik": {},
+ "company": {},
+ "concept": {},
+ "history": {},
+ "latest_reported": {},
+ "note": {},
+ "revenue": {},
+ "unit": {}
+ },
+ "type": "object"
+}insider_transactions1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "cik": {},
+ "company": {},
+ "filings": {},
+ "note": {}
+ },
+ "type": "object"
+}recent_filings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "cik": {},
+ "company": {},
+ "count": {},
+ "filings": {}
+ },
+ "type": "object"
+}company_lookupfiling_searchfinancialsinsider_transactionsrecent_filingsSEC EDGAR filings for AI agents: company lookup, filings, financials, insider trades. No keys.
SEC EDGAR financials, insider trading, and economic data for AI agents. US GAAP + IFRS.
SEC EDGAR fundamentals as agent tools: look up or screen US public companies. Free, no key, CC0.
Normalized SEC EDGAR data for AI agents: XBRL financials, 10-K risk diffs, Form 4 insider trades.
Add one secure layer between your agents and this server.
