secedgar-mcp-server
Server Details
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/secedgar-mcp-server
- GitHub Stars
- 0
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
Average 4.4/5 across 8 of 8 tools scored. Lowest: 3.8/5.
Each tool targets a distinct operation: company lookup, dataframe inspection, data querying, XBRL frame fetching, filing retrieval, financial data extraction, concept search, and filing text search. No two tools have overlapping purposes, making misselection unlikely.
All tools share the 'secedgar_' prefix, but the pattern after the prefix is mixed: some use noun_verb (e.g., secedgar_company_search, secedgar_dataframe_describe) while others use verb_noun (e.g., secedgar_fetch_frames, secedgar_get_filing). This inconsistency may cause confusion about the action order.
8 tools cover the core functionalities of searching companies, retrieving filings and financials, exploring XBRL concepts, and querying dataframes. The count is well-scoped for the SEC EDGAR domain, with no apparent bloat or deficiency.
The tool set provides a solid coverage of SEC data retrieval and analysis. However, the description of secedgar_search_concepts references a secedgar_compare_metric tool that is not present, indicating a minor gap in the intended workflow.
Available Tools
8 toolssecedgar_company_searchSecedgar Company SearchARead-onlyIdempotentInspect
Find companies and retrieve entity info with optional recent filings. Entry point for most EDGAR workflows — resolves tickers, names, or CIKs to entity details, with accession numbers in the result feeding secedgar_get_filing for document content.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company ticker symbol (e.g., "AAPL"), name (e.g., "Apple"), or CIK number (e.g., "320193"). Ticker is the fastest lookup. Name search does fuzzy matching. | |
| form_types | No | Filter filings to specific form types (e.g., ["10-K", "10-Q", "8-K"]). Without this, returns all form types. | |
| filing_limit | No | Maximum number of filings to return. | |
| include_filings | No | Include recent filings in the response. Set to false for entity-info-only lookups. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cik | Yes | Central Index Key, zero-padded to 10 digits. |
| sic | Yes | SIC industry code. |
| name | Yes | SEC-conformed company name. |
| filings | No | Recent filings, filtered by form_types if specified. |
| tickers | Yes | Associated ticker symbols. |
| exchanges | Yes | Exchanges where listed. |
| total_filings | No | Total filings matching the filter (may exceed filing_limit). |
| fiscal_year_end | Yes | Fiscal year end (MMDD format). |
| sic_description | Yes | Human-readable SIC description. |
| state_of_incorporation | No | State of incorporation (US two-letter code, e.g. "DE"). Omitted for some entities, including many foreign filers and individuals. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the agent knows this is a safe, cacheable external lookup. The description adds valuable workflow context ('Entry point') and clarifies the optional nature of filings data, but doesn't disclose error behaviors (e.g., empty results for no match), rate limits, or caching specifics.
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 tightly-constructed sentences with zero redundancy. First sentence establishes core functionality; second sentence provides workflow positioning. Every clause earns its place—no filler words or repetitive restatements of the tool name.
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 100% schema coverage, present annotations, and existence of an output schema, the description appropriately focuses on purpose and workflow role rather than repeating parameter or return value details. Minor gap: doesn't describe behavior when no companies match the query.
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 detailed documentation for all 4 parameters including examples for query and form_types. The description reinforces these semantics by mentioning 'resolve tickers, names, or CIKs' and 'optional recent filings,' but doesn't add significant new information beyond what the schema already provides (baseline 3 for high coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Find companies', 'retrieve entity info') with clear scope (optional recent filings). Effectively positions the tool as an entity resolution service ('resolve tickers, names, or CIKs') distinguishing it from sibling tools that likely operate on specific filings or metrics.
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 identifies this as the 'Entry point for most EDGAR workflows,' providing clear guidance on when to start with this tool. Implies it should be used before siblings like get_filing or get_financials by emphasizing identifier resolution, though it doesn't explicitly state negative constraints (e.g., 'don't use this for full document retrieval').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_dataframe_describeSecedgar Dataframe DescribeARead-onlyIdempotentInspect
List dataframes (df_XXXXX_XXXXX) materialized by secedgar_fetch_frames, secedgar_search_filings, and secedgar_get_financials. Each entry surfaces source tool, query parameters, creation/expiry timestamps, row count, column schema, and whether the dataframe is truncated relative to the upstream source.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional table name (df_XXXXX_XXXXX) to describe a single dataframe. Omit to list all dataframes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| dataframes | Yes | Active dataframes for this tenant, newest first. Empty when none are registered. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds valuable behavioral context: dataframes have creation/expiry timestamps, row count, column schema, and truncation status. 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?
Two sentences, front-loaded with purpose and functionality. No wasted words; every sentence adds value.
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, annotations, and output schema (mentioned), the description covers purpose, usage, and the contents of each entry completely. No gaps.
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 a clear description of the parameter. The description adds meaning by explaining that omitting the name lists all dataframes and providing a name describes a single one, adding value 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?
The description clearly states the tool lists dataframes generated by specific sibling tools and provides details about each entry. It distinguishes itself from siblings by focusing on describing dataframes rather than fetching or searching.
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 states to omit the name parameter to list all dataframes or provide a specific name to describe a single one. It implies usage but does not explicitly say when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_dataframe_querySecedgar Dataframe QueryARead-onlyIdempotentInspect
Run a single-statement SELECT against the canvas dataframes registered by secedgar_fetch_frames, secedgar_search_filings, and secedgar_get_financials. Read-only: writes, DDL, DROP, COPY, PRAGMA, ATTACH, and external-file table functions are rejected. System catalogs (information_schema, pg_catalog, sqlite_master, duckdb_*) are denied at the bridge layer — list dataframes via secedgar_dataframe_describe. Optional register_as chains the result as a new dataframe with a fresh TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Single-statement SELECT against df_<id> tables on the shared canvas. Standard DuckDB SQL — joins, aggregates, window functions, CTEs all supported. Reference dataframes by the names returned in fetch/search responses or listed by secedgar_dataframe_describe. BIGINT columns (e.g., XBRL `value`, COUNT/SUM results) serialize as JSON strings to preserve precision past 2^53 — CAST(col AS DOUBLE) in projections for inline arithmetic. | |
| preview | No | Rows to include in the immediate response. Defaults to the row limit. Set lower (e.g., 50) when chaining via register_as and only a sample is needed inline. | |
| row_limit | No | Hard cap on rows materialized in the response. Default 1000, max 10000. The full result lives on-canvas under register_as when provided — do not raise this to keep large results. | |
| register_as | No | When set, persist the result as a new dataframe under this name (must match df_XXXXX_XXXXX shape, or pass a fresh df_<id> generated by the agent). Fresh TTL window — not inherited from the parents in the SELECT. Use to chain analyses without re-running the source SQL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Materialized rows, bounded by `preview` / `row_limit`. |
| columns | Yes | Column names in projection order. |
| row_count | Yes | Total rows the query produced (may exceed `rows.length` when capped). |
| expires_at | No | ISO 8601 expiry timestamp for the newly registered dataframe, when applicable. |
| registered_as | No | Set when `register_as` was supplied and the new dataframe was materialized. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds rich behavioral detail: rejected operations (writes, DDL, system catalogs), BIGINT serialization as JSON strings, register_as TTL behavior, and row limits. 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 concise with 4-5 sentences, each adding value. It front-loads the main purpose and efficiently covers restrictions, registration, and parameter nuances without 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?
Given 4 parameters (all explained), existing output schema, and annotations, the description covers core functionality, edge cases (BIGINT, system catalogs), and intended use. It references source functions and describes chaining, making it complete for the tool's complexity.
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 baseline is 3. The description significantly adds meaning: sql parameter explains DuckDB SQL syntax, BIGINT precision, and dataframe references; preview and row_limit explain use cases; register_as explains persistence and TTL. The description goes well 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?
The description clearly states the tool runs a single-statement SELECT against canvas dataframes, specifying the verb, resource, and constraints. It distinguishes from sibling tools by focusing on querying vs. fetching, searching, or describing.
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 guidance on when to use this tool (for SELECT queries) and when not (for modifications, schema listing via secedgar_dataframe_describe). It mentions chaining via register_as but does not explicitly compare to all sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_fetch_framesSecedgar Fetch FramesARead-onlyIdempotentInspect
Fetch SEC XBRL frames for one concept × one period across all reporting companies. Inline response returns the top N ranked companies; the full frames response (all reporters) is materialized as df_ when a canvas is available, queryable via secedgar_dataframe_query. Accepts friendly names like "revenue" or "assets" (discover via secedgar_search_concepts) or raw XBRL tags. One call hits one XBRL tag — when a friendly name maps to multiple tags, the response's unqueried_tags lists the others; call again per tag and UNION/COALESCE in SQL with an analysis-specific priority (e.g. SalesRevenueGoodsNet is goods-only). Response includes value_distribution and period_end_range to flag XBRL scale-factor anomalies and fiscal-year mixing.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort direction. "desc" for highest values first (typical for revenue, assets). "asc" for lowest values. | desc |
| unit | No | Unit of measure. Use "USD-per-shares" (or equivalently "USD/shares") for EPS, "shares" for share counts, "pure" for ratios. Ignored when concept resolves to a friendly name with a known unit. | USD |
| limit | No | Number of companies to return. | |
| period | Yes | Calendar period. Use duration periods (no I suffix) for income/cash-flow items: "CY2023" (full year), "CY2024Q2" (single quarter). Use instant periods (I suffix) for balance-sheet items: "CY2023Q4I" (snapshot at Q4 close). | |
| concept | Yes | Financial concept — same friendly names as secedgar_get_financials (e.g., "revenue", "assets", "eps_basic") or raw XBRL tag. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Ranked companies for this metric. |
| unit | Yes | Unit of measure used for the lookup (always normalized to dashed form, e.g. "USD-per-shares"). |
| label | Yes | Human-readable concept label. |
| period | Yes | Calendar period the data was fetched for, echoed from input. |
| caveats | Yes | Data-completeness warnings specific to this query. Currently populated for duration periods 'CY####Q[1-4]', where SEC XBRL omits filers' fiscal Q4 (reported only as the 10-K residual) — affected filers are silently absent from the frame. Empty for annual ('CY####') and instant ('CY####Q#I') periods, where the underlying facts exist and the frame is complete. |
| concept | Yes | XBRL tag the data was actually fetched against (after resolving any friendly name). |
| dataset | No | Canvas dataframe handle holding the full frames response. Absent when canvas is unavailable or materialization failed. |
| unqueried_tags | Yes | Other XBRL tags in the same friendly-name mapping that this call did NOT query. Empty for raw tags or single-tag concepts. For "revenue" this typically lists `Revenues`, `SalesRevenueNet`, `SalesRevenueGoodsNet` — filers reporting under legacy variants are absent from `data`; call again per tag and UNION/COALESCE in SQL to recover them. |
| total_companies | Yes | Total companies reporting this metric for this period. |
| period_end_range | Yes | Range of period_end dates across the frame. SEC normalizes to calendar periods but filers report against their own fiscal year-ends, so a "CY2023" duration frame can contain period_ends from 2023-01-31 (January-FY filers like Walmart) to 2024-12-31 (calendar-FY filers reported late). Wide ranges mean cross-comparison mixes fiscal periods. |
| value_distribution | Yes | Distribution stats across the full frame, computed during materialization. Use `max_to_p95_ratio` as the primary outlier signal — it catches scale-factor anomalies even when median is 0 or negative. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds significant behavioral details: it returns top N inline, materializes full frames as df_<id> when canvas available, and includes value_distribution and period_end_range in the response to flag anomalies. This fully informs the agent of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph dense with information, front-loaded with the main purpose. It is efficient with no wasted words, but could benefit from slightly more structure (e.g., separation of behavioral notes from usage guidelines) for easier parsing.
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 (5 parameters, output schema exists), the description covers all necessary aspects: purpose, parameter behaviors, handling of multiple tags, response metadata, and ties to sibling tools like secedgar_search_concepts and secedgar_dataframe_query. It is comprehensive enough for an agent to use 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?
The input schema has 100% description coverage, providing baseline 3. The description adds semantic value by explaining that concept accepts friendly names or raw tags, unit is ignored when concept resolves to a friendly name with known unit, and detailing period syntax (duration vs instant). This enhances understanding 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?
The description clearly states the tool fetches SEC XBRL frames for one concept and one period across all reporting companies. It uses a specific verb ('Fetch') and resource ('SEC XBRL frames'), and distinguishes its scope from sibling tools by mentioning that it operates across all companies, whereas related tools like secedgar_get_financials likely focus on a single 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 provides explicit guidance on when to use this tool and how to handle multiple tags: when a friendly name maps to multiple tags, it lists unqueried_tags, advising to call again for each tag and UNION/COALESCE in SQL. It also explains the difference between inline (top N) and full frames (when canvas available), guiding the user based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_filingSecedgar Get FilingARead-onlyIdempotentInspect
Fetch a specific filing's metadata and document content by accession number. Returns the primary document as readable text, with option to fetch specific exhibits.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | Company CIK (resolve via secedgar_company_search if you have a ticker or name). Optional but recommended — speeds up archive lookup. If omitted, likely filing CIKs are inferred from SEC search metadata and archive paths. | |
| document | No | Specific document filename within the filing (e.g., "ex-21.htm" for subsidiaries list). Default: the primary document. Available documents listed in the response metadata. | |
| include_xbrl | No | Include XBRL viewer artifacts and machine-readable taxonomy files (R*.htm fragments, *_cal/_def/_lab/_pre.xml linkbases, *_htm.xml inline instance, *.xsd schemas, MetaLinks.json, FilingSummary.xml, Show.js, report.css, *-xbrl.zip, Financial_Report.xlsx, EX-101.* technical exhibits) under documents.xbrl. Off by default — these dominate filing indexes (~100 entries on a typical 10-K) and are rarely relevant when reading filing content. | |
| content_limit | No | Maximum characters of document text to return. 10-K filings can exceed 500,000 characters. Default 50,000 captures ~12,000 words (typically business overview, risk factors, and MD&A). Increase to 200,000 for full financial statements, or decrease for quick summaries. | |
| accession_number | Yes | Filing accession number in either format: "0000320193-23-000106" (dashes) or "000032019323000106" (no dashes). Obtained from secedgar_company_search or secedgar_search_filings results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cik | Yes | Filing entity CIK, zero-padded to 10 digits. |
| form | No | Form type (e.g., "10-K", "10-Q"). Absent for filings older than the last ~1,000 the company has filed (SEC does not surface metadata for those without a separate fetch). |
| content | Yes | Document text content, truncated to content_limit. |
| documents | Yes | Filing documents grouped by category. Names from any list are valid values for the document input. XBRL viewer artifacts are suppressed by default; setting include_xbrl=true surfaces them under the xbrl bucket. |
| filing_url | Yes | Direct URL to the filing on SEC.gov. |
| filing_date | No | Date the filing was submitted (YYYY-MM-DD). Absent under the same conditions as form. |
| company_name | No | Filing entity name. Absent if the CIK did not resolve to a known entity. |
| period_ending | No | Period the filing reports on (YYYY-MM-DD). Absent under the same conditions as form. |
| accession_number | Yes | Filing accession number, normalized to dash format. |
| primary_document | Yes | Filename of the document whose text was returned in content. |
| content_truncated | Yes | True if content was truncated. |
| content_total_length | Yes | Full document length before truncation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable context that the tool returns 'readable text' (format disclosure) and specifies the default behavior of returning the 'primary document' versus optional exhibits. However, it omits error handling behavior (e.g., invalid accession numbers) and rate limit considerations despite the openWorldHint annotation.
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 efficiently structured: the first establishes the core fetch operation and key identifier, the second clarifies return format and optional capabilities. Zero redundancy or filler content.
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 rich input schema (100% coverage), presence of output schema, and comprehensive annotations, the description provides sufficient context for invocation. It appropriately avoids duplicating the output schema's structural details while conveying the essence of the return value (metadata + text). Minor deduction for lack of error condition mention.
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?
With 100% schema description coverage, the baseline is appropriately met. The description aligns with schema concepts (mentioning 'accession number' and 'exhibits') but does not add semantic clarification beyond what the schema already provides (e.g., no additional context on content_limit trade-offs or CIK derivation logic beyond the schema 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 uses specific verbs ('Fetch') and identifies the exact resource (filing metadata and document content) and identifier type (accession number). It distinguishes from sibling tools like secedgar_get_financials (structured data) by specifying 'readable text' content, and from search tools by requiring a specific 'accession number' rather than search criteria.
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?
While the description mentions the 'option to fetch specific exhibits,' it provides no explicit guidance on when to use this tool versus secedgar_get_financials (structured financial data vs. full text) or secedgar_search_filings (discovery vs. retrieval). The workflow prerequisite (obtaining accession numbers) is documented only in the parameter schema description, not the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_financialsSecedgar Get FinancialsARead-onlyIdempotentInspect
Get historical XBRL financial data for a company. Accepts friendly concept names (e.g., "revenue", "net_income", "assets") or raw XBRL tags. Discover available friendly names with secedgar_search_concepts. Handles historical tag changes and deduplicates data automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Ticker symbol (e.g., "AAPL") or CIK number. Ticker is preferred. | |
| concept | Yes | Financial concept — friendly name (e.g., "revenue", "net_income", "assets", "eps_diluted") or raw XBRL tag (e.g., "AccountsPayableCurrent"). Friendly names auto-resolve to the correct XBRL tags and handle historical tag changes. | |
| taxonomy | No | XBRL taxonomy. us-gaap for US companies, ifrs-full for foreign filers, dei for entity info (shares outstanding). | us-gaap |
| period_type | No | Filter to annual (FY) or quarterly (Q1-Q4) data. "all" returns both. When omitted, defaults to "annual" for income/cash-flow concepts and "all" for balance-sheet (instant) items so balance-sheet calls return data on the first attempt. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cik | Yes | Resolved CIK, zero-padded to 10 digits. |
| data | Yes | Deduplicated time series, newest first. |
| unit | Yes | Unit of measure (e.g., "USD", "shares", "USD/shares"). |
| label | Yes | Human-readable label for the concept. |
| company | Yes | Resolved entity name (SEC-conformed). |
| concept | Yes | XBRL tag name used. |
| dataset | No | Canvas dataframe handle holding the same time series. Use for cross-company JOINs via secedgar_dataframe_query. Absent when canvas is unavailable. |
| tags_tried | No | XBRL tags that were attempted (shown when using friendly names that map to multiple tags). |
| description | No | XBRL taxonomy description for this concept. Often absent for company-extension tags or older concepts. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, and open-world behavior. The description adds valuable behavioral details not present in annotations: automatic handling of historical tag changes and deduplication logic, which are critical for understanding how the tool normalizes XBRL data over time.
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?
Four sentences with zero waste: sentence 1 states purpose, sentence 2 explains input flexibility with examples, sentence 3 discloses key processing behavior, and sentence 4 provides a reference for enumerated values. Information is front-loaded and dense.
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 100% schema coverage, presence of output schema, and comprehensive annotations, the description appropriately focuses on differentiating features (friendly name resolution, deduplication) rather than repeating parameter mechanics. It sufficiently covers the tool's unique value proposition.
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?
With 100% schema coverage, the baseline is 3. The description adds value by clarifying the dual nature of the 'concept' parameter (friendly names vs raw XBRL tags) and referencing secedgar://concepts for the domain of valid values, which complements the schema's technical 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 states the specific action (Get) and resource (historical XBRL financial data), and distinguishes itself from sibling filing tools (secedgar_get_filing, secedgar_search_filings) by emphasizing structured financial concepts and friendly names versus raw document retrieval.
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 for when to use this tool (extracting structured financial metrics via friendly names or XBRL tags) and references the secedgar://concepts endpoint for valid values. However, it does not explicitly contrast with siblings like secedgar_get_filing to clarify when raw filings are preferred over structured data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_search_conceptsSecedgar Search ConceptsARead-onlyIdempotentInspect
Search supported XBRL financial concepts by keyword, statement group, or taxonomy. Use before secedgar_get_financials or secedgar_compare_metric to discover the right friendly name, or pass a raw XBRL tag (e.g., "NetIncomeLoss") to reverse-lookup which friendly names map to it. Empty search with no filters returns the full catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Filter to a single financial statement group. income_statement covers P&L items; balance_sheet covers position items (use instant periods in secedgar_compare_metric); cash_flow covers CF statement items; per_share covers EPS; entity_info covers DEI items like shares outstanding. | |
| search | No | Case-insensitive substring matched against friendly name, label, and XBRL tags. Examples: "cash" finds cash and operating_cash_flow; "earnings" finds eps_basic and eps_diluted; "NetIncomeLoss" reverse-maps to net_income. Omit to list all concepts. | |
| taxonomy | No | Filter to a single XBRL taxonomy. us-gaap for US filers, ifrs-full for foreign filers, dei for entity info. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Number of concepts matching the filters. |
| concepts | Yes | Matching concepts, ordered by group then alphabetical by name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, closed-world, and idempotent behavior. The description adds valuable context beyond this: it explains that searches are case-insensitive substring matches, describes what happens with an empty search (returns full catalog), and clarifies the reverse-lookup functionality. No contradictions with annotations are present.
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 efficiently structured in three sentences: the first states the core purpose, the second provides usage guidelines with specific sibling tool references, and the third explains edge-case behavior. Every sentence adds value without redundancy, making it appropriately sized and 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?
Given the tool's moderate complexity, rich annotations (readOnlyHint, openWorldHint, idempotentHint), 100% schema coverage, and the presence of an output schema, the description provides complete contextual information. It covers purpose, usage guidelines, and behavioral nuances without needing to explain return values or parameter details.
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?
With 100% schema description coverage, the input schema already fully documents all three parameters. The description adds minimal additional semantics, such as implying the 'search' parameter is optional (by mentioning 'omit to list all'), but doesn't provide significant extra meaning beyond what's in the schema 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 states the tool searches for XBRL financial concepts using keywords, statement groups, or taxonomies. It specifies the verb 'search' and resource 'supported XBRL financial concepts,' distinguishing it from sibling tools like secedgar_company_search (which searches for companies) and secedgar_search_filings (which searches for 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 states when to use this tool: 'Use before secedgar_get_financials or secedgar_compare_metric to discover the right friendly name.' It also provides an alternative use case for reverse-lookup and clarifies that an empty search returns the full catalog, offering clear guidance on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_search_filingsSecedgar Search FilingsARead-onlyIdempotentInspect
Search the full-text index of EDGAR filings since 1993. Supports exact phrases, boolean operators, wildcards, and entity targeting (ticker:AAPL or cik:320193 in query).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result ordering. "filing_date_desc" (default) returns most recent first. "filing_date_asc" returns oldest first. "relevance" returns SEC's native search-score order, which weights term match strength over recency. Date sorts re-order the top 100 hits returned by the search index — for broad queries with more than 100 matches and no entity targeting, date-newest filings may sit outside that window. Entity targeting (ticker:/cik:) or a narrower query keeps matches inside the window when absolute recency matters. | filing_date_desc |
| forms | No | Filter to specific form types (e.g., ["10-K", "10-Q", "8-K"]). Without this, searches all form types. | |
| limit | No | Results per page. Max 100. | |
| query | Yes | Full-text search query. Supports: exact phrases ("material weakness"), boolean operators (revenue OR income), exclusion (-preliminary), wildcard suffix (account*), entity targeting (ticker:AAPL or cik:320193 in the query). Terms are AND'd by default. | |
| offset | No | Pagination offset. Increment by limit for the next page. EDGAR caps total accessible results at 10,000 — offsets past this return nothing. Under date sort, pagination is bounded to the first 100 hits. | |
| end_date | No | End of date range (YYYY-MM-DD). Both start_date and end_date must be provided for date filtering. | |
| start_date | No | Start of date range (YYYY-MM-DD). Both start_date and end_date must be provided for date filtering. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total matching filings (capped at 10,000). Under entity targeting (ticker:/cik:), this becomes the count of entity-matching hits within the sampled window of search results — a lower bound when more matches exist beyond the window. |
| dataset | No | Canvas dataframe holding the hits already fetched for the inline response. Absent when total ≤ inline limit, canvas is unavailable, or materialization failed. The dataframe contains the raw EFTS results (entity-filtered when ticker:/cik: was used) — query with secedgar_dataframe_query SQL. |
| results | Yes | Matching filings. |
| total_is_exact | Yes | False when total hits the 10,000 cap, or when entity targeting filtered a sample that did not cover the full match set. |
| form_distribution | No | Count of results by form type. Helps narrow follow-up searches. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context not in annotations: temporal coverage ('since 1993') and specific query language capabilities (exact phrases, entity targeting patterns). No contradictions 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?
Two highly efficient sentences. First establishes scope and action; second details query capabilities. No redundant words or generic filler. Information density is high with zero waste.
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 100% schema coverage and presence of output schema, the description provides sufficient high-level context. Mentions critical temporal boundary (1993) and query syntax. Could marginally improve by noting pagination behavior or result limits, but schema adequately covers the 6 parameters.
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%, establishing baseline 3. The description elaborates on query syntax (ticker:AAPL, cik:320193) which overlaps with the schema's query parameter description but serves as useful front-loaded context. Does not compensate for parameters since schema is complete.
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 specific action ('Full-text search'), resource ('EDGAR filing documents'), and temporal scope ('since 1993'). Clearly distinguishes from siblings like secedgar_get_filing (retrieval by ID) and secedgar_company_search (entity lookup) by emphasizing content search across documents.
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 rich syntax guidance for constructing queries (boolean operators, wildcards, entity targeting syntax), implying when to use the tool for complex text searches. However, lacks explicit comparison to siblings or guidance on when to use secedgar_get_filing vs this search tool.
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.
Discussions
No comments yet. Be the first to start the discussion!