Clean SEC EDGAR company financials for AI agents — normalized income statement, balance sheet, cash flow, computed ratios, company profiles, filings, and 10-K/10-Q narrative sections (Risk Factors, MD&A) for 10,000+ US public companies. 5 tools: get_fundamentals, get_ratios, get_company, get_filings, get_sections. Free tier, no card.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 7 of 7 tools scored. Lowest: 3.3/5.
Each tool targets a distinct aspect of SEC EDGAR data: company info, events, filings, fundamentals, insider trades, ratios, and narrative sections. No two tools have overlapping purposes.
All tools follow a consistent 'get_<noun>' pattern, making it easy to predict functionality from the name alone.
Seven tools cover a comprehensive set of financial data operations without being excessive. Each tool serves a clear and necessary function.
The tool set covers key financial data points: company metadata, filings, fundamentals, ratios, insider trades, events, and narrative sections. There are no obvious missing operations for its stated domain.
get_companyGet a company profileACIK, legal name, SIC industry, fiscal-year end, exchanges and website for a ticker, resolved from SEC EDGAR submissions.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, read-only, idempotent behavior. The description adds transparency about the data source (SEC EDGAR submissions) and the specific fields returned, providing context beyond the annotations. No contradictions found.
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?
The description is a single sentence that efficiently lists the returned fields and the data source. No unnecessary words 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?
Given the single parameter, high annotation coverage, and no output schema, the description is nearly complete. It specifies the output fields and source. Minor omission: it does not explicitly state that the tool returns a single company, but this is implied by the ticker parameter.
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?
The input schema has 100% coverage with a clear description for 'ticker'. The description does not add additional meaning beyond the schema's definition, so a baseline score of 3 is appropriate.
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 clearly states the tool returns specific company profile fields (CIK, legal name, SIC industry, etc.) for a given ticker, resolved from SEC EDGAR. It distinguishes from sibling tools like get_filings or get_fundamentals by specifying the exact output type.
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 for retrieving a company profile but lacks explicit when-to-use or when-not-to-use guidance. It does not mention alternatives or conditions, though sibling names provide some context. Usage is implied rather than directly instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventsGet 8-K material eventsA8-K material events for a ticker as typed items (2.02 earnings, 5.02 executive change, 1.05 cybersecurity incident, 2.01 acquisition, etc.), each with a notable flag for the market-moving ones and a link to the filing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of events, 1-100 (default 20). | |
| ticker | Yes | US stock ticker, e.g. 'AAPL'. | |
| notable | No | Only market-moving events (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, ensuring safety awareness. The description adds value by disclosing that events are 'typed items' with a notable flag for market-moving ones and a link to the filing, which helps the agent understand the return structure beyond annotations.
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?
The description is a single sentence that efficiently conveys the purpose, key return features (typed items, notable flag, link), and example event types. It is front-loaded and contains no unnecessary words, though it could be slightly reorganized for clarity.
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?
Given that there is no output schema, the description adequately explains the nature of the returned items (typed, with notable flag and filing link). However, it omits details about pagination, error handling, and default behavior for the limit parameter, which the schema partially covers. Overall, it is sufficient for basic usage.
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 input schema already clearly documents all three parameters (ticker, limit, notable) with their types and descriptions. The description does not add new semantic information about parameters beyond what the schema 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?
The description clearly states it retrieves '8-K material events for a ticker' as typed items with a notable flag and filing link. It uses a specific verb (get) and resource (events for a ticker), and the examples of event types (2.02 earnings, etc.) distinguish it from sibling tools like 'get_filings' or 'get_company'.
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 the tool is for 8-K material events but does not provide explicit guidance on when to use it versus alternatives (e.g., 'get_filings' for all filings, or 'get_sections' for specific sections). No exclusionary criteria or usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_filingsGet recent SEC filingsBRecent SEC filings for a ticker (10-K/10-Q/8-K) with filing/report dates and document links.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Optional form filter, e.g. '10-K', '10-Q', '8-K'. | |
| limit | No | Number of filings to return, 1-100 (default 20). | |
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and open world behavior. The description adds that the output includes filing/report dates and document links, but does not detail other behaviors (e.g., pagination, rate limiting). It adds some value beyond annotations.
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?
The description is a single, front-loaded sentence with no redundant words. Every part contributes to understanding the tool's core function.
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?
For a simple tool with three parameters and no output schema, the description provides adequate context about the response content. However, it lacks details on the recency or ordering of filings (e.g., defaults to last 20).
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%, providing clear parameter definitions. The tool description adds no additional parameter information, so it meets the baseline expectation.
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 clearly states the tool retrieves recent SEC filings for a ticker, mentioning common form types and response contents (dates and links). It distinguishes the tool's purpose but does not explicitly differentiate from sibling tools.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., get_fundamentals, get_insider). The description lacks when/when-not and alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fundamentalsGet company financial statementsANormalized income statement, balance sheet, and cash flow for a US-listed ticker, parsed from SEC EDGAR XBRL. Counts as one request on the Edgrapi plan.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of periods to return, 1-20 (default 5). | |
| period | No | Reporting period (default annual). | |
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about the data source (SEC EDGAR XBRL) and billing plan, which are beneficial beyond the annotations. No contradictions.
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: first defines purpose and source, second adds billing info. No redundant phrases, perfectly front-loaded and efficient.
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?
Given the tool's simplicity (3 parameters, no output schema), the description is complete: it specifies the financial statements returned, data source, and billing cost. Could mention normalization briefly, but not necessary.
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%, so the schema already documents all parameters. The description adds no additional semantic meaning for the parameters beyond what's in the schema, which is adequate but not enhanced.
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 clearly states it retrieves 'income statement, balance sheet, and cash flow' for a US-listed ticker from SEC EDGAR XBRL. This distinguishes it from siblings like get_ratios or get_filings.
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 mentions the billing impact ('counts as one request'), but does not explicitly state when to use this tool versus alternatives like get_ratios or get_filings. Usage is implied by name and purpose but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_insiderGet parsed insider transactionsAParsed SEC Form 4 insider trades for a ticker: owner, role, transaction code (P open-market purchase, S sale, A award, M exercise, F tax withholding), shares, price, dollar value, and a 10b5-1 plan flag. Code P is the only own-money buy signal; A/M/F are automatic compensation. Pass ticker='latest' for the market-wide feed of the biggest open-market buys, or ticker='clusters' for companies where several insiders bought at once (the cluster-buy signal).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | For 'clusters': lookback window in days (default 15). | |
| limit | No | Number of results, 1-100 (default 20). | |
| ticker | Yes | US stock ticker (e.g. 'AAPL'), 'latest' for market-wide buys, or 'clusters' for cluster buys. | |
| min_insiders | No | For 'clusters': min distinct insiders (default 3). |
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 clear. The description adds valuable behavioral context beyond annotations: it explains the structure of returned data (transaction codes, ownership signals) and the special behavior for 'latest' and 'clusters' (e.g., 'cluster-buy signal'). No contradictions.
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?
The description is a single, information-dense sentence that front-loads the purpose ('Parsed SEC Form 4 insider trades for a ticker') and then efficiently lists fields and special cases. Every part earns its place with no redundancy or filler.
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?
Given the lack of an output schema, the description enumerates the returned fields (owner, role, transaction code, shares, price, dollar value, 10b5-1 flag). It also covers the three use cases (single ticker, 'latest', 'clusters') with necessary parameter details. For a read-only query tool with good annotations, this is fully complete.
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%, and the description adds significant meaning: it explains that ticker can be 'latest' or 'clusters' and what they do, and clarifies that days and min_insiders are only for 'clusters'. It also interprets transaction codes, which is not in the schema. This goes well beyond the schema's parameter descriptions.
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 clearly identifies the tool as parsing SEC Form 4 insider trades for a ticker, listing the data fields (owner, role, transaction code, shares, price, etc.). It distinguishes from sibling tools like get_filings by focusing specifically on insider transactions, and explains special ticker values 'latest' and 'clusters'.
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 provides explicit guidance on when to use each ticker value: normal ticker for company-specific trades, 'latest' for market-wide open-market buys, and 'clusters' for cluster buys. It also explains transaction codes, highlighting that 'P' is the only own-money buy signal, which helps the agent decide when to use this tool for identifying insider buying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ratiosGet computed financial ratiosAMargins, returns (ROE/ROA), leverage and liquidity ratios for a ticker, derived from SEC EDGAR fundamentals. Price-based ratios (P/E, P/B) excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe, non-mutating behavior. Description adds context about derivation source and excluded ratio types, beyond annotations.
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 with no wasted words. First sentence lists ratio categories and source, second clarifies exclusion. Information is front-loaded.
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?
For a read-only retrieval tool with one parameter and no output schema, the description sufficiently covers included/excluded ratios and source, leaving no ambiguity.
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% with one parameter described as 'US stock ticker, e.g. AAPL'. Description adds no additional parameter details beyond the schema.
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?
Description clearly states it computes margins, returns (ROE/ROA), leverage, and liquidity ratios from SEC EDGAR fundamentals, and explicitly excludes price-based ratios (P/E, P/B). This distinguishes it from siblings like get_fundamentals.
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?
No explicit when-to-use or when-not-to-use guidance. Implied usage is for obtaining fundamental ratios, but alternatives like get_fundamentals are not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sectionsGet 10-K/10-Q narrative sectionsANarrative sections from the latest 10-K/10-Q as clean text — Risk Factors (item 1A), MD&A (item 7), Business (item 1), etc. Built for LLM/RAG equity research. Omit 'item' to list the available sections first.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Filing type: '10-K' (default) or '10-Q'. | |
| item | No | Section to fetch, e.g. '1A' (Risk Factors) or '7' (MD&A). Omit to list available sections. | |
| ticker | Yes | US stock ticker, e.g. 'AAPL'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is readOnly, openWorld, idempotent, and not destructive. The description adds clarity on behavioral traits: it retrieves the latest filing, returns 'clean text', and provides a listing mode when 'item' is omitted. This complements the annotations well, though some details like error handling are missing.
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?
The description is extremely concise—two sentences that front-load the core purpose and examples, followed by a specific usage hint. Every word earns its place, with no redundancy or irrelevant information.
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?
Given the lack of an output schema, the description could be more explicit about the return format (e.g., plain text, multiple sections at once). It implies a list when 'item' is omitted and a single section when provided, but this is not fully spelled out. The description is sufficient for basic usage but leaves some gaps for an AI agent.
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%, so parameters are well-documented. The description reinforces the behavior of omitting 'item' to list sections, which is already in the schema description for 'item'. It adds minimal new semantics beyond reminding the agent of this optional feature, resulting in a baseline score.
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 clearly states the tool retrieves narrative sections from the latest 10-K/10-Q filings, listing specific items (Risk Factors, MD&A, Business). The verb 'get' matches the tool name, and the resource is distinctly different from sibling tools (company, events, filings, etc.), making its purpose unambiguous.
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 provides the useful hint to omit 'item' to list available sections, which helps the agent decide when to call without parameters. However, it lacks explicit guidance on when not to use this tool, prerequisites (e.g., valid ticker), or comparison to alternatives among siblings. The context is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
