Normalized SEC EDGAR fundamentals. 3 of 6 tools free; the rest $0.04-$0.10 per call in USDC.
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.3/5 across 6 of 6 tools scored.
Each tool targets a distinct resource: company profile, filings, multi-metric financials, single-metric time series, cross-company comparison, and metric vocabulary. Even get_financials and get_concept are clearly separated by scope (statement snapshot vs. one metric's full history). No two tools overlap in purpose.
Five of six tools follow a clear verb_noun snake_case pattern (list_filings, list_metrics, get_concept, get_financials, compare_companies), but company_profile is a noun_noun exception. The deviation is minor and all names remain readable and predictable.
Six tools is an ideal scope for a fundamentals-focused server. Each tool covers an essential function without redundancy, from reference data and filings to financial statements, time series, and peer comparisons.
The surface covers the full lifecycle of fundamental data access: identify a company, see its filings, get financial statements, explore a single metric's history, compare across peers, and understand metric definitions. No major gaps; the only conceivable addition (e.g., name search) is not essential to the domain.
company_profileCompany Reference ProfileAInspectResolves an exchange ticker to its SEC filer and returns that filer's reference data in one call: the zero-padded ten-digit CIK that identifies it in EDGAR, its official registrant name, its SIC industry classification code with the code's description, the exchanges its securities trade on, and the fiscal year end that determines where its fiscal quarters fall. Reach for this first — to confirm a ticker is a real SEC filer, to resolve it to a CIK, to establish industry or sector context, to choose peers to compare against, or to learn a filer's fiscal calendar before reading quarterly figures or lining its periods up against another company whose year ends elsewhere. Returns the CIK and registrant name together with the SIC code and description, the exchange list and the fiscal year end. See /.well-known/x402 for current pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Exchange ticker symbol of a single SEC filer, case-insensitive, such as AAPL, MSFT or KO. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return fields and mentions pricing at /.well-known/x402, but does not describe error handling for invalid tickers, rate limits, authentication requirements, or any side effects. Useful context, but significant behavioral details remain uncovered.
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 somewhat long with a comprehensive list of use cases, but every sentence adds relevant information. It is front-loaded with the core action and return values, and the pricing note is a useful contextual detail. Minor redundancy in the list of return items, but overall 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?
For a single-parameter tool with no output schema, the description thoroughly covers the return values (CIK, registrant name, SIC code and description, exchanges, fiscal year end) and provides clear context for when to use it. It does not address invalid-ticker behavior or other edge cases, but the tool is simple enough that this is a minor gap.
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 schema already documents the ticker parameter format (case-insensitive, pattern, max length). The tool description adds no additional semantic meaning beyond what the schema provides, so the baseline of 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 clearly states the tool resolves an exchange ticker to its SEC filer and returns specific reference data (CIK, registrant name, SIC code and description, exchanges, fiscal year end). It uses a specific verb-resource pair and is easily distinguished from sibling tools like get_financials or list_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 explicitly enumerates use cases ('confirm a ticker is a real SEC filer', 'resolve it to a CIK', 'establish industry or sector context', 'choose peers', 'learn a filer's fiscal calendar') and positions itself as 'reach for this first'. It lacks explicit exclusions or alternative tool references, so it does not fully meet the 'when-not' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_companiesCompare Companies On One MetricAInspectCompares one normalized metric across several filers in a single call, with reporting periods aligned so companies whose fiscal calendars end in different months still line up period by period. Use it for peer, competitor or ranking questions — which of these companies earns the most revenue, whose total assets grew fastest, how a filer's net income stands against its sector — where the same figure is wanted for two to eight tickers. Exactly one metric per call, because the upstream aligns a single metric across companies rather than returning a matrix; ask again per metric if you need more. Returns one row per ticker carrying the aligned period values and the resolved XBRL tag, plus a per-row error for any ticker that fails to resolve or has never reported the metric. See /.well-known/x402 for current pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many aligned reporting periods to return per company, newest first. Accepts 1 to 12; defaults to 4 when omitted. | |
| metric | Yes | The single normalized metric key every company is compared on, as published by list_metrics — for instance revenue, net_income or assets. One metric per call. | |
| period | Yes | Reporting frequency to return: 'annual' for fiscal-year figures drawn from 10-K filings, 'quarterly' for fiscal-quarter figures drawn from 10-Q filings. | annual |
| tickers | Yes | The companies to compare, as exchange ticker symbols. Between 2 and 8 distinct symbols; duplicates are folded together and a symbol that does not resolve is reported on its own row rather than failing the call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It discloses the key alignment mechanism ('fiscal calendars end in different months still line up period by period'), the exact return shape ('one row per ticker carrying the aligned period values and the resolved XBRL tag'), and error behavior ('a per-row error for any ticker that fails to resolve or has never reported the metric'). It even points to pricing docs. This is comprehensive and exceeds the typical transparency level.
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 dense paragraph that front-loads the core purpose and follows with usage guidance, behavior, return format, and a pricing pointer. Every sentence adds value, and it avoids redundancy with the schema. The structure is efficient for its complexity.
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 complexity (multi-company comparison with fiscal calendar alignment), the description fully compensates for the lack of an output schema by explaining the aligned periods, return row structure, and error handling. It also provides clear usage context and a pointer to pricing. Contextual completeness is high, and no important aspect seems 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?
The input schema provides 100% coverage with detailed descriptions for all parameters: limit, metric, period, and tickers. The tool description reinforces the 'one metric per call' rule but does not add new parameter-level semantics beyond what the schema already states. Thus, per the baseline for high schema coverage, a 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's function: 'Compares one normalized metric across several filers in a single call' with aligned reporting periods. It is specific about the resource (multiple filers), the action (compare one metric), and the scope (two to eight tickers), effectively distinguishing it from sibling tools like get_financials.
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 usage context: 'Use it for peer, competitor or ranking questions' and 'where the same figure is wanted for two to eight tickers.' It also states a key constraint: 'Exactly one metric per call' and advises to 'ask again per metric if you need more.' However, it does not name specific alternative tools or explicitly state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_conceptGet One Metric's Reported SeriesAInspectThe reported time series for a single normalized metric from one company's XBRL facts — every revenue, net_income or assets observation the filer has published, each with its value, unit, period start and end, and the filing it came from. Use it when a question is about the history, trend or growth of one figure rather than a whole statement, or when you must reconcile a number against the filing it was tagged in. Returns the observations newest first alongside the upstream tag and taxonomy that actually resolved, which matters because filers tag the same economic concept differently and a series cannot be compared across companies without knowing which tag answered. See /.well-known/x402 for current pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many observations to return, newest first. Accepts 1 to 200; defaults to 20 when omitted. A decade of annual history needs about 10. | |
| metric | No | Normalized metric key to fetch, exactly as published by list_metrics — for instance revenue, net_income, assets, equity or operating_cash_flow. Call list_metrics first if unsure; a key outside that vocabulary is rejected. | |
| ticker | Yes | Exchange ticker symbol of a single SEC filer, case-insensitive, such as AAPL, MSFT or KO. | |
| taxonomy | No | XBRL taxonomy the resolved tag is drawn from: 'us-gaap' for financial statement concepts, 'dei' for entity-level facts such as shares outstanding. Defaults to 'us-gaap'. | us-gaap |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses newest-first ordering, that results include the upstream tag and taxonomy actually resolved, and the caveat about comparing series across companies. It does not cover error behavior or rate limits, but the core behavioral traits are well explained.
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 dense and well-structured: output description, usage guidance, behavioral nuance, and pricing link. It is slightly long with em-dash clauses, but every sentence contributes value without 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?
Without an output schema, the description fully explains what is returned (value, unit, period start/end, filing, tag, taxonomy), the ordering, and the importance of the resolved tag. It also references pricing. This covers all essential context for an agent to decide and correctly invoke the tool.
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 schema already fully documents parameters. The description adds examples like 'revenue, net_income or assets' and mentions 'limit' indirectly through history depth, but does not provide substantial parameter-level meaning beyond the schema, so baseline 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 a reported time series for a single normalized metric from one company's XBRL facts, with concrete examples (revenue, net_income, assets) and details on included fields. It distinguishes itself from siblings by emphasizing 'one figure rather than a whole statement'.
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 states when to use: 'when a question is about the history, trend or growth of one figure' or 'when you must reconcile a number against the filing it was tagged in.' It contrasts with 'a whole statement' but does not name specific alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_financialsGet Normalized Financial StatementsAInspectThe normalized financial statement view for one company across recent fiscal periods: revenue, gross profit, operating income, research and development, net income, diluted earnings per share, total and current assets and liabilities, stockholders equity, cash, operating cash flow and capital expenditures, plus the derived ratios gross_margin, operating_margin, net_margin and current_ratio. Reach for this by default when a question is about a company's performance, profitability or margins over annual or quarterly periods rather than the history of one figure. Returns one record per fiscal period newest first, the upstream XBRL tag that supplied each figure so any number can be traced back to the 10-K or 10-Q, and the list of metrics this filer never reported. See /.well-known/x402 for current pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many fiscal periods to return, newest first. Accepts 1 to 20; defaults to 5 when omitted. | |
| period | Yes | Reporting frequency to return: 'annual' for fiscal-year figures drawn from 10-K filings, 'quarterly' for fiscal-quarter figures drawn from 10-Q filings. | annual |
| ticker | Yes | Exchange ticker symbol of a single SEC filer, case-insensitive, such as AAPL, MSFT or KO. | |
| metrics | No | Optional subset of normalized metric keys to return, as published by list_metrics. Omit to receive the server's standard statement set; narrow it when only a few figures matter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses ordering ('newest first'), provenance ('upstream XBRL tag'), and handling of unreported metrics ('list of metrics this filer never reported'). It also mentions pricing. This is ample behavioral context for a read-only data tool.
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 long sentence with many clauses, including an extraneous pricing pointer at the end. Although informative, it is less concise than it could be; it could be split into shorter sentences. It is not structured with bullets.
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 covers the returned record structure, metric list, ordering, traceability to XBRL, and unreported metrics, which is substantial given no output schema. It also includes usage context. It is missing explicit error handling or examples, but overall is quite complete for a retrieval tool.
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 descriptions cover all parameters fully (100% coverage). The description adds little beyond naming some metrics, but the schema already explains ticker, period, limit, and metrics with defaults and constraints. Thus the description provides marginal additional semantic value, so score baseline 3.
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 provides 'normalized financial statement view for one company across recent fiscal periods' and enumerates the metrics and derived ratios included. It explicitly contrasts with 'the history of one figure,' distinguishing it from the get_concept sibling.
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 explicitly instructs: 'Reach for this by default when a question is about a company's performance, profitability or margins over annual or quarterly periods rather than the history of one figure.' This provides clear when-to-use guidance and references an alternative type of tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_filingsList Recent FilingsAInspectRecent EDGAR filing history for one company, newest first: form type (10-K, 10-Q, 8-K, S-1 and the rest), filing date, the period end the document reports on, its accession number and a direct link to the document. Use it to establish what a company has filed and when — whether the latest annual report is out, whether a fiscal quarter has been reported yet, or how much recent 8-K activity there has been — before deciding which numbers are even available. Pass form to narrow to one filing type; omit it for every type. See /.well-known/x402 for current pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Optional EDGAR form-type filter, for example "10-K" for annual reports, "10-Q" for quarterly, or "8-K" for material events. Omit to receive every form type. Narrowing here is cheaper than filtering the returned rows. | |
| limit | No | How many filings to return, newest first. Accepts 1 to 100; defaults to 25 when omitted. Ask for the fewest that answer the question. | |
| ticker | Yes | Exchange ticker symbol of a single SEC filer, case-insensitive, such as AAPL, MSFT or KO. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the ordering ('newest first'), the specific data elements returned (form type, filing date, period end, accession number, direct link), and mentions pricing at /.well-known/x402. It does not mention rate limits or authentication, but the read-only nature is evident.
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 three sentences: the first defines the output, the second gives usage context, the third gives form-filter guidance. Every sentence contributes; no 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?
Without an output schema, the description enumerates the return fields and ordering, explains why to use the tool, and points to pricing. This is sufficient for an agent to decide when to call it and what to expect, covering the tool's 3-parameter API.
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 covers all three parameters (ticker, form, limit) with descriptions, so the baseline is 3. The description's only parameter guidance is a redundant 'Pass `form` to narrow; omit it for every type,' which adds no new semantics beyond the schema's existing note that narrowing is cheaper. Therefore a 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 opens with 'Recent EDGAR filing history for one company, newest first' and enumerates the returned fields (form type, filing date, period end, accession number, link), clearly differentiating it from financial metrics and company profile tools. The verb 'list' and resource 'filings' make the operation 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?
It explicitly states use cases: 'Use it to establish what a company has filed and when' with concrete examples (annual report, fiscal quarter, 8-K activity), and it notes to pass `form` to narrow or omit for all types. It subtly hints that this is a precursor to pulling numbers, but it doesn't name alternative tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_metricsList Normalized MetricsAInspectPublishes the canonical metric vocabulary this server normalizes SEC XBRL facts into: for each metric its key (revenue, net_income, assets, operating_cash_flow, ...), a human label, the statement it belongs to (income, balance, cashflow, entity), its unit, and the ranked upstream us-gaap/dei tag candidates tried in order until a filer's own tagging matches. Reach for this before any other paid call whenever you need to know which metric keys get_concept, get_financials and compare_companies will accept, or which XBRL tags stand behind a reported figure. Returns the full metric table plus the derived ratios (gross_margin, operating_margin, net_margin, current_ratio) with the numerator and denominator each is computed from. No parameters, no upstream lookup. See /.well-known/x402 for current pricing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses that there are 'No parameters, no upstream lookup,' returns 'the full metric table plus the derived ratios,' and specifies the table's schema. This covers operational behavior, though it doesn't explicitly state read-only semantics or auth requirements.
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 dense paragraph with front-loaded purpose. Every clause adds detail—metric fields, usage, ratios, pricing—without redundancy. Slightly longer than minimal, but each sentence earns its place.
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 no output schema, the description fully specifies the return shape (metric keys, labels, statements, units, tag candidates, and derived ratios with numerator/denominator) and even provides pricing reference, making it a complete guide for a parameterless tool.
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?
Zero parameters; the schema alone covers 100% via its description. The tool description reinforces with 'No parameters' and adds 'no upstream lookup,' clarifying why no input is needed.
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 it 'Publishes the canonical metric vocabulary' with specific fields and explicitly ties to sibling tools' accepted keys, clearly differentiating from company_profile, list_filings, etc.
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 'Reach for this before any other paid call' and lists the exact scenarios (knowing which keys get_concept/get_financials/compare_companies accept, identifying XBRL tags behind figures), providing clear when-to-use guidance.
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!