SEC Fundamentals API
Server Details
SEC EDGAR financials, benchmarks, screening & Buffett value scans for agents. Pay x402 or API key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
11 toolsbuffett_scanBInspect
Buffett Quality Score (0-100) over a 5-year window: owner earnings, ROE consistency at 15%, balance-sheet safety, FCF quality. Foreign private issuers (20-F) excluded unless exclude_foreign=False. Not investment advice. Cost: $0.25.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | ||
| limit | No | ||
| industry | No | ||
| min_score | No | ||
| min_revenue | No | ||
| exclude_foreign | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses cost ($0.25), a disclaimer, and the 5-year window. However, it does not detail behavior regarding data retrieval, side effects, or response format (though output schema exists).
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 sentences with no waste. Information is front-loaded with score name and components, and includes cost and disclaimer efficiently.
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 output schema exists, the overview is adequate but lacks parameter explanations and detailed usage context. For a scanning tool with 6 parameters, more guidance would improve completeness.
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 0%, but the description only addresses the exclude_foreign parameter. Other parameters (fy, limit, industry, min_score, min_revenue) are left unexplained, forcing the agent to rely on names and defaults.
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 computes a Buffett Quality Score (0-100) over a 5-year window and lists components, making the tool's purpose clear. However, it could be more explicit about the scanning action to differentiate from siblings like buffett_value.
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 on when to use this tool vs alternatives such as screen_companies or buffett_value. The only usage hint is the exclusion of foreign issuers unless exclude_foreign=False.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buffett_valueInspect
Buffett Value Scan: Quality Score fused with previous-close valuation — market cap, FCF yield, owner-earnings DCF margin of safety. Quality companies trading below intrinsic value. Foreign private issuers excluded unless exclude_foreign=False. Not investment advice. Cost: $0.25.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | ||
| limit | No | ||
| industry | No | ||
| min_score | No | ||
| min_revenue | No | ||
| exclude_foreign | No | ||
| min_margin_of_safety | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
company_factsInspect
Raw normalized XBRL facts, filterable by canonical concept (revenue, net_income, total_assets, operating_cash_flow, ...), with filing provenance and quality flags. Cost: $0.01.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| limit | No | ||
| concept | No | ||
| fy_from | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
company_filingsInspect
SEC filing index with direct document URLs; form filters by type (10-K, 10-Q, 8-K, ...). Cost: $0.005.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| form | No | ||
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
company_financialsInspect
Clean annual financial statements: revenue, margins, income, balance sheet, cash flow, and ratios (gross_margin, roe, fcf, ...) per fiscal year. cik = SEC CIK number (Apple=320193). Cost: $0.02.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | ||
| fy_to | No | ||
| fy_from | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
compare_to_peersCInspect
Compare one company's metrics against its industry cohort percentiles. Cost: $0.05.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | Yes | ||
| cik | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions cost ($0.05), but omits whether the tool is read-only, requires authentication, or has rate limits. Minimal transparency.
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 a clear purpose and cost. Efficient but missing important details like parameter meanings and usage context.
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?
The description lacks detail on which metrics are compared, what 'percentiles' refers to, and the output structure. Although an output schema exists, the description should still provide context for effective use.
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 0%, yet the description does not explain the parameters 'cik' (likely company identifier) or 'fy' (fiscal year). The agent cannot infer their meaning from the description 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?
The description clearly states the action ('Compare') and the resource ('company metrics against its industry cohort percentiles'). It is specific and distinguishes from sibling tools like 'industry_aggregate' or 'company_financials' that have different purposes.
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 on when to use this tool versus alternatives (e.g., 'industry_aggregate' for industry-level data) or when not to use it. Only cost is mentioned, which is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
industry_aggregateInspect
Cross-company cohort percentiles (p10/p25/median/p75/p90) for a metric, by industry (2-digit SIC) and size bucket. Metrics: gross_margin, operating_margin, roe, rd_intensity, debt_to_equity, revenue, fcf, ... Cost: $0.05.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | ||
| size | No | ||
| metric | Yes | ||
| industry | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
list_insightsAInspect
Catalog of curated market-wide analyses with parameters. FREE. Call before market_insight / buffett_* to see options.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only adds 'FREE' as behavioral context, but does not disclose read-only nature, idempotency, or other traits. The behavioral transparency is minimal.
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, no wasted words. Purpose is front-loaded, and every sentence provides value (purpose, FREE, usage hint).
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 no-parameter list tool with an output schema, the description adequately conveys it's a catalog of options. The usage hint adds completeness, though it could mention the output's purpose more explicitly.
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 schema has zero parameters (100% coverage), so baseline is 4. However, the description inaccurately mentions 'with parameters', which contradicts the schema and slightly reduces the 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 it catalogs curated market-wide analyses, distinguishing it from sibling tools like market_insight and buffett_* by advising to call it first to see options. However, the claim 'with parameters' is misleading as the schema has no parameters.
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?
Explicitly instructs to call this tool before market_insight or buffett_* tools to see available options, providing clear sequential usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_insightInspect
Curated analysis across all companies. name: top_companies, movers, sector_landscape, metric_trend (agg=sum|median|mean), capital_returns, filing_velocity. Cost: $0.15.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | No | ||
| agg | No | ||
| form | No | ||
| name | Yes | ||
| fy_to | No | ||
| limit | No | ||
| metric | No | ||
| months | No | ||
| fy_from | No | ||
| industry | No | ||
| min_revenue | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
screen_companiesCInspect
Screen companies by financial criteria. filters is a JSON list of [metric, op, value] triples, e.g. [["gross_margin",">",0.6],["revenue",">",1e9]]. Cost: $0.10.
| Name | Required | Description | Default |
|---|---|---|---|
| fy | Yes | ||
| limit | No | ||
| filters | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost ($0.10), which is a behavioral trait. No annotations exist, so the description carries the burden. However, it does not mention whether the tool is read-only, performance characteristics, or error handling.
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 short sentences, no fluff. The first states purpose, the second adds filter format and cost. Efficient but could be slightly more structured.
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?
Despite having an output schema (not shown), the description fails to mention the return format or behavior for missing results. The 'fy' and 'limit' parameters are unexplained, and the tool's overall complexity (3 params) is not fully addressed.
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 0%, so the description must compensate. It explains the 'filters' parameter in detail but does not explain 'fy' (fiscal year) or 'limit' (default 50). This leaves two of three parameters ambiguous.
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 screens companies by financial criteria and explains the filter format. However, it could be more explicit about what 'screen' means (filtering vs. scoring) and how it differs from sibling tools like buffett_scan.
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 on when to use this tool vs. alternatives. No mention of use cases, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
standard_scoreInspect
Industry-standard fundamental scores over all US public companies. name: piotroski (F-Score 0-9), altman_z (bankruptcy zones), beneish_m (earnings-manipulation flag), magic_formula (Greenblatt rank), accruals (Sloan earnings quality). Peer-reviewed; not investment advice. $0.15.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| zone | No | ||
| limit | No | ||
| worst | No | ||
| min_score | No | ||
| min_revenue | No | ||
| flagged_only | No | ||
| exclude_foreign | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
Discussions
No comments yet. Be the first to start the discussion!