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
- 5
- Server Listing
- @cyanheads/secedgar-mcp-server
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.5/5 across 10 of 10 tools scored. Lowest: 3.8/5.
Every tool has a clearly distinct purpose. Company search, filing search, concept search, filing retrieval, financials, insider transactions, institutional holdings, XBRL frames, and dataframe management are all non-overlapping operations. Even related tools (e.g., search vs. get) are well-differentiated by description.
All tools follow a consistent 'secedgar_' prefix plus verb_noun pattern (e.g., company_search, dataframe_query, get_filing). The naming is predictable and uniform, with no mixing of conventions.
With 10 tools, the server is well-scoped for the SEC EDGAR domain. Each tool covers a distinct aspect of EDGAR data access—company info, filings, XBRL data, insider transactions, institutional holdings, and query support—without being bloated or sparse.
The tool set covers the major EDGAR workflows: searching, retrieving filings, XBRL financials, insider transactions, and institutional holdings. Minor gaps exist (e.g., no dedicated tool for 10-K/10-Q retrieval), but these can be addressed via search and get_filing. The presence of dataframe management tools is a bonus.
Available Tools
10 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", "VOO"), name (e.g., "Apple"), or CIK number (e.g., "320193"). Ticker is the fastest lookup and works for equities, ETFs, and mutual funds. Name search matches current and former names. | |
| 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. |
| notice | No | Guidance when include_filings=true but no filings matched the form_types filter. |
| filings | No | Recent filings, filtered by form_types if specified. |
| tickers | Yes | Associated ticker symbols. |
| class_id | No | SEC fund class ID (e.g. "C000092055"). Present when the query resolved via a fund ticker (ETF or mutual fund). |
| exchanges | Yes | Exchanges where listed. |
| series_id | No | SEC fund series ID (e.g. "S000002839"). Present when the query resolved via a fund ticker (ETF or mutual fund). |
| total_filings | No | Total filings matching the filter (may exceed filing_limit). |
| fiscal_year_end | No | Fiscal year end (MM-DD format, e.g., "09-26"). Absent for filers SEC records no fiscal year end for (e.g. private or pre-IPO entities). |
| 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, secedgar_get_financials, secedgar_get_insider_transactions, and secedgar_get_institutional_holdings. 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`. |
| notice | No | Guidance when the query returned no rows, or when results were capped. |
| 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 declare readOnlyHint=true and idempotentHint=true. The description adds substantial behavioral context: listing rejected operations (writes, DDL, etc.), denying system catalogs, explaining that BIGINT columns serialize as JSON strings, and the fresh TTL for register_as. 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, front-loaded with the core action. Each sentence adds essential information (main verb, restrictions, alternative listing tool, optional chaining). No fluff or 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?
Given an output schema exists, the description does not need to explain return values. It covers constraints (row limit, preview, register_as), persistence, and references sibling tools for listing dataframes. For a query tool with good annotations and schema, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds value beyond schema: explains BIGINT serialization, df_<id> naming convention, guidance on preview and row_limit for chaining, and that register_as creates a fresh TTL. This enrichment justifies above baseline but not a full 5 since schema descriptions are already strong.
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 runs a single-statement SELECT against canvas dataframes registered by specific sibling tools (secedgar_fetch_frames, secedgar_search_filings, secedgar_get_financials). It distinctively contrasts with secedgar_dataframe_describe which lists dataframes, and the verb 'Run a SELECT' with resource 'canvas dataframes' is precise.
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 says when to use (for SELECT queries on registered dataframes), what is rejected (writes, DDL, DROP, COPY, PRAGMA, ATTACH, external-file table functions), and how to list dataframes via secedgar_dataframe_describe. It also mentions optional register_as for chaining analyses, providing clear when-not and alternatives.
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 same-meaning 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). The response's related_tags separately flags alternate-DEFINITION tags a meaningful share of filers use as their primary line (e.g. cash incl. restricted cash, equity incl. noncontrolling interest) — a whole-universe screen on the base tag silently omits those filers; query them separately, but do not blindly union (the semantics differ). 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. |
| related_tags | Yes | Alternate-DEFINITION XBRL tags (distinct from same-meaning `unqueried_tags`) that a meaningful share of filers use as their primary line for this metric — e.g. `cash` filers reporting `CashCashEquivalentsRestrictedCashAndRestrictedCashEquivalents` (incl. restricted cash), `equity` filers reporting `StockholdersEquityIncludingPortionAttributableToNoncontrollingInterest` (incl. noncontrolling interest). These filers are NOT in `data` or the dataframe, so a whole-universe screen on the base tag silently under-counts. To recover them, run a separate fetch_frames against the alternate tag — do NOT blindly UNION (definitions differ; you would mix or double-count). Empty when the concept has no known high-coverage alternate. |
| unqueried_tags | Yes | Other same-meaning XBRL tags in the friendly-name mapping that this call did NOT query (historical/variant spellings of the same metric). Empty for raw tags or single-tag concepts — for alternate-DEFINITION tags some filers use instead, see `related_tags`. 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds operational details: inline returns top N, full frames materialized as df_<id>, response includes value_distribution and period_end_range for anomaly detection. No contradiction.
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 covering multiple aspects. It is concise but could benefit from structuring (e.g., bullet points or separate sentences for key behaviors). No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description explains the two output modes (inline, full frames), materialization as df_<id>, and includes edge cases (unqueried_tags, scale-factor anomalies). It is sufficiently complete for a non-trivial 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 coverage is 100%, but the description significantly extends meaning: explains concept can be friendly names or raw tags, how to discover via secedgar_search_concepts, handling of multiple tags, and period syntax. This adds crucial context beyond 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 companies. It distinguishes between inline and full frames responses and mentions related tools (secedgar_dataframe_query, secedgar_search_concepts), differentiating it from siblings.
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 explicit guidance: one call per XBRL tag, how to handle multiple tags with UNION/COALESCE in SQL, period format distinctions (duration vs instant), and unit usage. It implicitly advises when not to use (e.g., single company queries not mentioned).
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 filing's actual primary document (e.g., the 10-K HTML file). |
| content_truncated | Yes | True if content was truncated. |
| requested_document | No | Filename of the specific document requested via the document param. Only present when document differs from primary_document. |
| 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 |
|---|---|---|---|
| limit | No | Cap the inline data[] to the most-recent N periods (the series is newest-first). The full series is always registered to the dataframe, so older periods stay queryable via secedgar_dataframe_query. Omit to return every period inline. | |
| 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"; instant (balance-sheet) concepts automatically fall back to returning the full series on the first call when the annual filter yields nothing (#48). |
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_get_insider_transactionsGet Insider TransactionsARead-onlyIdempotentInspect
Fetch Form 4 insider transactions (purchases, sales, grants, exercises) for a company by parsing SEC EDGAR ownership XML. Returns the reporting person, their relationship to the issuer, transaction date, type, shares traded (absolute magnitude), direction (acquire/dispose), price per share, and shares owned after the transaction. Covers nonDerivative transactions (open-market buys/sells, gifts) and derivative transactions (option exercises, RSU vests). When a canvas is available, the full set of transactions parsed from the scanned recent filings is materialized as df_ (the inline list is a preview capped at limit) — query it with secedgar_dataframe_query to aggregate net buy/sell by insider: SUM(CASE WHEN direction='dispose' THEN -shares_traded ELSE shares_traded END). Use secedgar_search_filings with forms=["4"] for broader date-range queries or to search across all companies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of transactions to return across all Form 4 filings fetched. Filings are scanned newest-first. Default 20. | |
| ticker_or_cik | Yes | Company ticker symbol (e.g., "AAPL") or 10-digit CIK number (e.g., "0000320193"). The issuer, not the reporting person. | |
| transaction_type | No | Filter by direction. "purchase" = open-market buys (code P). "sale" = open-market sells (code S). "all" includes grants, awards, exercises, gifts, and other coded transaction types as well. | all |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when results are empty after filtering — explains the filter applied and suggests alternatives. |
| dataset | No | Canvas dataframe holding the full parsed transaction set from the scanned filings (the inline transactions[] is a preview capped at limit). Each row carries the issuer (issuer_cik, issuer_ticker) plus the transaction fields, so it aggregates net buy/sell by insider and joins across issuers. Query with secedgar_dataframe_query. Absent when canvas is unavailable or no transactions were parsed. |
| issuer_cik | Yes | Issuer CIK, zero-padded to 10 digits. |
| issuer_name | Yes | Issuer entity name (SEC-conformed). |
| transactions | Yes | Insider transactions, newest filing first. Preview capped at `limit` — the full scanned set lives on the canvas dataframe (see `dataset`). |
| issuer_ticker | No | Issuer ticker symbol when available. |
| filings_scanned | Yes | Number of Form 4 filings scanned to produce the result. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds context: scans filings newest-first, returns specific fields, covers nonDerivative and derivative transactions, and that the full set is materialized as a dataframe. 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?
Well-structured and front-loaded with main purpose. Some redundancy (e.g., mentions dataframe twice) but every sentence adds value. Could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 params, output schema exists, annotations present), the description fully explains return fields, inline list vs dataframe behavior, and how to query the dataframe. It also references sibling tools for alternative use cases.
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 descriptions for all 3 parameters. The description further clarifies the direction filter, limit defaults, and that ticker_or_cik is for the issuer, 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 fetches Form 4 insider transactions for a company via SEC EDGAR XML, using specific verbs ('Fetch') and resources ('insider transactions'). It distinguishes from siblings by mentioning secedgar_search_filings for broader queries.
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 explains when to use vs alternatives: when a canvas is available, query the dataframe with secedgar_dataframe_query, and use secedgar_search_filings for broader date-range or cross-company searches. Also explains the limit and transaction_type filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
secedgar_get_institutional_holdingsGet Institutional HoldingsARead-onlyIdempotentInspect
Fetch 13F-HR quarterly institutional holdings by parsing the SEC EDGAR information table XML. Use ticker_or_cik to look up an institution (e.g., "Vanguard Group" or its CIK) and see what it holds — or pass a company ticker/CIK to find which institutions filed 13Fs covering that period. The 13F information table lists each position: issuer name, CUSIP, shares held, market value (in whole USD), and put/call designation for options. Sub-lines for the same security are consolidated into distinct positions sorted by value by default (set consolidate=false for raw filing rows). The full parsed holdings set is materialized as df_ when a canvas is available — the inline holdings list is a preview capped at limit — so query it with secedgar_dataframe_query to aggregate the whole filing or self-join across quarters on cusip + reporting_period. Institutions with less than $100M in 13(f) securities are exempt and may not file. Use secedgar_search_filings with forms=["13F-HR"] for broader search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of holdings rows to return. 13F filings from large institutions can contain thousands of positions. Default 20. | |
| quarter | No | Reporting quarter to target, in "YYYY-QN" format (e.g., "2025-Q4"). When omitted, returns the most recent 13F-HR available. Quarters map to the filing window: Q4 2025 = filings submitted roughly Jan–Mar 2026. | |
| consolidate | No | When true (default), info-table sub-lines for the same security (CUSIP + class + put/call) are summed into one position and results are sorted by market value descending, so `limit` returns the largest distinct holdings. Set false to return raw information-table rows in filing order (one per investment-discretion/manager sub-line), preserving investment_discretion. | |
| ticker_or_cik | Yes | Ticker symbol or CIK of the institutional filer (e.g., "0000102909" for Vanguard) or a company name. For institution lookups, CIK or the full legal name resolves most reliably — tickers are typically for operating companies, not fund managers. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when no filings were found or the result set is empty — suggests alternatives. |
| dataset | No | Canvas dataframe holding every parsed position from this 13F filing (the inline holdings[] is a preview capped at limit). Each row carries the filer metadata (filer_cik, filer_name, reporting_period, filing_date, accession_number) plus the position fields, so it self-joins across quarters/filers on cusip + reporting_period. Reflects the consolidate setting (consolidated positions when true, raw info-table sub-lines with investment_discretion when false). Query with secedgar_dataframe_query. Absent when canvas is unavailable or the filing had no holdings. |
| holdings | Yes | Holdings truncated to limit — consolidated positions sorted by market value when consolidate=true, else raw information-table rows in filing order. |
| filer_cik | Yes | CIK of the 13F filer, zero-padded to 10 digits. |
| filer_name | Yes | Name of the institutional filer (the 13F submitter). |
| filing_date | Yes | Date the 13F was submitted (YYYY-MM-DD). |
| total_positions | No | Number of distinct positions after consolidating info-table sub-lines, before the limit. Present only when consolidate=true. |
| accession_number | Yes | Accession number for this 13F-HR filing — pass to secedgar_get_filing for the full document. |
| reporting_period | No | The calendar-quarter end date this 13F covers (YYYY-MM-DD), from the filing cover page. Absent if not surfaced in the filing. |
| total_holdings_in_filing | Yes | Total number of raw information-table rows in this filing, before consolidation and the limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint; description enriches with specifics: consolidation of sub-lines, preview vs. materialized dataframe, quarter mapping to filing window, and exemption for small institutions. 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 detailed but well-structured, starting with primary purpose then paramby-param explanation and edge cases. Slightly long but every sentence adds value; could be slightly more concise but excellent overall.
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 output schema exists, description covers return format (preview vs. dataframe), edge cases (exemptions, consolidation), and provides enough contextual completeness for effective tool 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 has 100% coverage with descriptions; description adds significant context: ticker_or_cik resolution advice, quarter date mapping, consolidation behavior, and limit rationale. This 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 fetches 13F-HR quarterly institutional holdings by parsing SEC EDGAR XML, specifies the verb 'Fetch' and resource 'institutional holdings', and distinguishes from siblings like secedgar_search_filings by explicitly mentioning it for broader searches.
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 when-to-use: to see institutional holdings or find institutions holding a company, and when-not-to-use: institutions with less than $100M may not file. It suggests alternatives like secedgar_search_filings for broader search and secedgar_dataframe_query for aggregation, offering clear usage guidance.
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_fetch_frames 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_fetch_frames); 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. |
| notice | No | Guidance when no concepts matched — echoes the search term and suggests alternatives. |
| 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. Note: "10-K" also matches amendments filed as 10-K/A. Ownership forms (3, 4, 5) are indexed by the reporting person (e.g., "LEVINSON ARTHUR D"), not the issuer — rows carry no transaction code, share count, or price. Use secedgar_get_insider_transactions to retrieve parsed ownership XML with person, relationship, transaction code, shares, and price. | |
| 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). Entity targeting (ticker:/cik:) scopes server-side via the EFTS ciks param, so this is the entity's exact match count up to the cap. |
| notice | No | Guidance when no results were returned — echoes the query and suggests how to broaden. |
| 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-scoped server-side via the ciks param when ticker:/cik: was used) — query with secedgar_dataframe_query SQL. |
| results | Yes | Matching filings. |
| effectiveQuery | Yes | The query as executed against EDGAR (ticker/cik: tokens resolved to entity names). |
| total_is_exact | Yes | False only when total hits the 10,000 cap. |
| 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!
Your Connectors
Sign in to create a connector for this server.