Read SEC 10-K and 10-Q sections as clean text and diff them year over year. Pay per call.
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/5 across 5 of 5 tools scored.
Each tool targets a distinct resource: company identity lookup, filing list retrieval, section extraction, financial data, and filing comparison. There is no overlap in purpose; even the two data-fetching tools (financials vs. sections) are clearly differentiated by the type of data they return.
All names use lowercase snake_case, which is consistent, but the verb-noun pattern is not uniform: 'lookup_company' and 'compare_filings' are verb-first, while 'recent_filings', 'company_financials', and 'filing_section' are noun/adjective-first. Still, the style is readable and predictable, with only minor deviations.
Five tools form a well-scoped set for SEC filing analysis: identity resolution, filing discovery, section access, financial data, and comparison. Each tool earns its place without redundancy or bloat, and the count is within the ideal range.
The toolset covers the core workflows: find a company, list its filings, pull a numbered section, fetch as-reported financials, and compare two filings. Minor gaps exist (e.g., retrieving the full filing text or searching across filings), but the most common analysis tasks are well supported, and workarounds are possible.
company_financialsReported financial figuresAFetch an as-reported XBRL financial concept for a company across recent periods, each tied to the filing it came from. Note that many issuers report revenue under RevenueFromContractWithCustomerExcludingAssessedTax rather than Revenues; if one returns nothing current, try the other. Costs $0.01 per call. No subscription and no free tier: present a credit key or a machine payment.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Ticker symbol (e.g. AAPL) or SEC CIK number (e.g. 320193). | |
| concept | Yes | US-GAAP concept name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: per-call cost, no free tier, requirement for credit key/machine payment, and the filing-tied nature of results. This goes beyond the annotation baseline.
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 focused sentences, each earning its place: purpose, nuance, and cost/auth. No 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?
Covers what is returned (concept per period, tied to filing), pricing, and authentication requirements. Lacks explicit return format details, but with no output schema, the description provides enough context for invocation.
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 covers both parameters thoroughly with descriptions. The description adds value by explaining the RevenueFromContractWithCustomerExcludingAssessedTax vs Revenues nuance, which is not in the schema and helps correct usage.
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 fetches an as-reported XBRL financial concept for a company across recent periods, tied to the filing. This distinguishes it from siblings like recent_filings (which lists filings) and lookup_company (which identifies companies).
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 when to use it (need financial figure data) and gives specific guidance on alternative revenue concepts if the primary one returns nothing. It lacks explicit contrast with sibling tools but the context is clear enough for an agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_filingsDiff a section across two filingsACompare the same item between two filings of a company and return what changed: added and removed passages plus a change ratio. This is the year-over-year risk factor or MD&A comparison, done for you. Pass two accession numbers to pin exactly which filings are compared; otherwise the two most recent of that form are used. Costs $0.50 per call. No subscription and no free tier: present a credit key or a machine payment.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | 10-K or 10-Q. Default 10-K. | |
| item | No | Item to compare, e.g. 1A for risk factors. Default 1A. | |
| company | Yes | Ticker symbol (e.g. AAPL) or SEC CIK number (e.g. 320193). | |
| max_passages | No | Cap on added/removed passages returned. Default 40. | |
| to_accession | No | Newer filing to compare to. | |
| from_accession | No | Older filing to compare from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it mentions the cost ('Costs $0.50 per call'), payment requirements ('No subscription and no free tier: present a credit key or a machine payment'), and the output structure ('added and removed passages plus a change ratio'). It does not contradict the readOnlyHint/openWorldHint annotations, and the read-only safety profile is already covered, but the cost and output details are valuable additions.
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 concise and front-loaded: the first sentence states the core function, subsequent sentences cover use case, accession behavior, and cost. Every sentence earns its place; no filler or redundant details. It is appropriately sized for the tool's 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?
With no output schema, the description adequately explains what the tool returns ('added and removed passages plus a change ratio'). It also covers cost, default behavior, and the specific use case. The schema covers all parameters, and annotations cover safety, so the description is complete enough for an agent to select and invoke the tool correctly.
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. The description adds extra meaning for accession parameters: 'Pass two accession numbers to pin exactly which filings are compared; otherwise the two most recent of that form are used.' It also contextualizes the 'item' parameter by mentioning 'risk factor or MD&A comparison,' which isn't in the schema. This lifts the score above baseline.
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: 'Compare the same item between two filings of a company and return what changed: added and removed passages plus a change ratio.' It specifies the resource (filings of a company) and the action (diff/comparison), and distinguishes it from siblings by noting it's a 'year-over-year risk factor or MD&A comparison, done for you.'
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 concrete usage context: 'Pass two accession numbers to pin exactly which filings are compared; otherwise the two most recent of that form are used.' It also implies the primary use case (year-over-year risk factor or MD&A comparison), giving the agent a clear sense of when to invoke it. However, it does not explicitly mention alternatives or exclusions compared to sibling tools, 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.
filing_sectionExtract one section of a filingAPull a single numbered item out of a 10-K or 10-Q as clean text: risk factors (1A), MD&A (7), business (1), and the rest. Saves you fetching a multi-megabyte HTML document and finding the section yourself. Pin an exact filing with accession; without it you get the most recent filing of that form, which changes when the company amends. Costs $0.05 per call. No subscription and no free tier: present a credit key or a machine payment.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | 10-K or 10-Q. Default 10-K. | |
| item | No | Item number, e.g. 1A, 7, 7A. Call with item omitted to list what this filing has. | |
| company | Yes | Ticker symbol (e.g. AAPL) or SEC CIK number (e.g. 320193). | |
| accession | No | Exact accession number to pin, e.g. 0000320193-26-000020. Strongly recommended for anything reproducible. | |
| max_chars | No | Truncate the section. Default 50000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true, but the description goes beyond by disclosing cost ($0.05 per call), no free tier, required credit key or machine payment, the non-determinism when accession is omitted, and the ability to list sections by omitting item. These are valuable behavioral details not captured in 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?
Five sentences cover purpose, value, caveat, cost, and authentication. Each sentence carries necessary information, though the value proposition sentence could be seen as slightly extraneous. Overall it is compact and front-loaded with the core purpose.
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?
No output schema exists, but the description compensates by stating the output is 'clean text' and that omitting item returns a section list. It also covers truncation via max_chars, cost, and authentication, making the tool fully understandable for 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 100%, so baseline is 3. The description adds meaning beyond the schema, especially for the accession parameter (changes when company amends) and for item omission (list what this filing has), enriching the semantics that the schema only hints at.
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 uses a specific verb ('Pull') and resource ('single numbered item out of a 10-K or 10-Q'), enumerates example sections (1A, 7, 1), and clearly differentiates from sibling tools like company_financials or recent_filings by scoping to section extraction.
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?
Provides clear context: saves the user from fetching large HTML and finding the section manually. It also warns about the behavior without accession ('you get the most recent filing... changes when the company amends'). However, it does not explicitly name alternative sibling tools or say when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_companyLook up a companyAResolve a ticker or CIK to a company's canonical SEC identity: legal name, CIK, industry classification, tickers, and exchanges. Use this first when you only have a ticker and need the CIK for other calls. US SEC registrants only. Costs $0.00 per call. No subscription and no free tier: present a credit key or a machine payment.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Ticker symbol (e.g. AAPL) or SEC CIK number (e.g. 320193). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, and the description adds meaningful behavioral context: 'Costs $0.00 per call. No subscription and no free tier: present a credit key or a machine payment.' It also discloses the scope ('US SEC registrants only'). No contradiction with annotations 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?
The description is four sentences, each earning its place: function, usage guidance, scope, and pricing/auth. It is front-loaded with the core purpose and avoids redundancy. No wasted words.
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 one-parameter tool with no output schema, the description is remarkably complete. It lists the returned fields (legal name, CIK, industry classification, tickers, exchanges), covers scope, cost, and authentication, and situates the tool within the workflow. No critical missing context for correct invocation.
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% — the only parameter 'company' is fully described as 'Ticker symbol (e.g. AAPL) or SEC CIK number (e.g. 320193).' The description reinforces this but adds no new semantic detail beyond what the schema already provides, so 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 uses a specific verb ('Resolve') and names the exact input ('ticker or CIK') and output ('canonical SEC identity: legal name, CIK, industry classification, tickers, and exchanges'). It clearly distinguishes itself from siblings by stating it is the first step when only a ticker is available.
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 explicit usage guidance: 'Use this first when you only have a ticker and need the CIK for other calls.' It also clarifies the tool is limited to US SEC registrants. However, it does not explicitly name alternative tools or say when not to use it, though the sibling list implies other tools require a CIK.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recent_filingsRecent SEC filingsAList a company's most recent SEC filings with form type, dates, accession number, and a direct document URL. Optionally filter to one form type (10-K, 10-Q, 8-K, 4, S-1...). Covers EDGAR's recent-filings index, which holds roughly the last 1000 filings; older history is not searched, and the response says so when it exists. This is the canonical filing record, not commentary about it. Costs $0.01 per call. No subscription and no free tier: present a credit key or a machine payment.
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Optional exact form type filter, e.g. 10-K, 10-Q, 8-K, 4. | |
| limit | No | How many filings to return (1-50, default 10). | |
| company | Yes | Ticker symbol (e.g. AAPL) or SEC CIK number (e.g. 320193). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial behavioral context: the data source (EDGAR index), coverage limitation (~1000 filings), the fact that the response acknowledges when older history exists, exact pricing ($0.01 per call), and authentication requirements (credit key/machine payment). No contradiction with 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 four sentences, each adding distinct value: output contents, optional filtering, data coverage boundary, canonical nature, and cost/payment. It is front-loaded with the core purpose and has zero 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?
Without an output schema, the description clearly enumerates return fields (form type, dates, accession number, direct document URL), delimiters (recent ~1000 filings), and access requirements ($0.01 cost, payment for auth). It addresses both functional and operational context, making it complete for an agent to select and call correctly.
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?
Input schema has 100% description coverage for all three parameters. The description reiterates the optional form filter with examples but adds little beyond the schema (e.g., it does not mention the limit default or company identifier formats, which the schema already specifies). Baseline 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 opens with a specific verb and resource: 'List a company's most recent SEC filings with form type, dates, accession number, and a direct document URL.' It clearly differentiates from siblings by noting 'This is the canonical filing record, not commentary about it,' which distinguishes it from financial data or analysis 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?
The description provides clear context: it covers EDGAR's recent-filings index (~last 1000 filings) and explicitly says older history is not searched, signaling when not to use it. It also gives critical usage constraints around cost and payment (no free tier, requires credit key or machine payment), though it does not name alternative sibling tools explicitly.
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!
