Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ffd-mcp Get the fee exhibit for Apple's latest S-1 filing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for SEC EDGAR Exhibit 107 filing fee disclosure analysis.
Parses ffd: XBRL from registration statements (S-1, S-3, 424B, F-1, etc.) and returns structured fee data through the Model Context Protocol. No API keys required — SEC EDGAR is a free, public API.
7 Tools • 2 Resources • 1 Prompt • STDIO & Streamable HTTP
Tool | Description |
| Fetch and parse a specific Exhibit 107 by accession number + CIK. Returns every security class, fee amounts, fee rate, and net fee due. |
| Find a company's recent registration filings that contain Exhibit 107 fee disclosures. Resolves tickers, names, or CIKs automatically. |
| Fetch and parse all Exhibit 107 fee exhibits for a company in one call. Returns per-filing fee tables plus grand totals. |
| Compare filing fee data across 2-8 companies side by side — latest form, total offering, net fee due, and fee rate. |
| Full-text search across all EDGAR filings since 1993, scoped to registration statements. Supports phrases, boolean operators, and wildcards. |
| Get a company's complete ffd: filing fee history by merging the EDGAR companyfacts API (fast, no lag — covers 424B/S-3/S-8) with Exhibit 107 document parsing (covers S-1/F-1 filings that companyfacts doesn't index). |
| Query fee data and save as CSV. Three modes: |
get_fee_exhibitParse a specific Exhibit 107 (EX-FILING FEES) from an SEC filing.
Requires accession_number and cik
Optionally provide the exhibit_filename for faster parsing, or let the server auto-detect it from the filing index
Returns all ffd: XBRL concepts: every security class, max aggregate offering, fee amounts, fee rate, and net fee due
Includes retry logic for filings within the 24-48h EDGAR indexing lag window
search_fee_filingsFind a company's recent registration statement filings.
Accepts ticker symbols (RDDT), company names (Reddit), or CIK numbers
Defaults to all registration forms: S-1, S-3, S-4, F-1, F-3, F-4, F-6, 424B series, SC TO, PREM14A, DEFM14A, POS AM, S-8
Returns accession numbers, form types, filing dates, and EDGAR URLs
Surfaces a recency warning when results fall within the EDGAR indexing lag window
get_company_fee_historyBatch-parse all fee exhibits for a company across multiple filings.
Parses up to 10 filings in a single call (configurable via limit)
Returns the full structured fee table for each filing plus grand totals
Filterable by form type and start date
compare_fee_ratesSide-by-side comparison of fee data for 2-8 companies.
Shows the latest registration form, total offering, net fee due, and fee rate for each company
Useful for benchmarking offering sizes across a peer set
search_filings_by_feeFull-text search across all EDGAR filing documents, scoped to registration statements.
Find companies that registered a specific security type, used a specific fee rule (e.g. Rule 457(o)), or mentioned specific terms
Supports exact phrases, boolean operators (AND/OR/NOT), and wildcards
get_ffd_concepts_by_companyComplete fee history from two complementary data sources:
Phase 1 — companyfacts API (fast, no indexing lag): Returns ffd: XBRL facts for 424B prospectus supplements, S-3/A, and S-8 employee plans
Phase 2 — Exhibit 107 parsing (backfills the gap): Scans submissions for S-1/F-1 filings that the companyfacts API doesn't index, then fetches and parses each Exhibit 107
Every entry is tagged with source: "companyfacts" or source: "exhibit107"
Optionally filter by specific ffd concepts (FeeAmt, NetFeeAmt, etc.) or form types
export_fee_dataQuery SEC fee data and save the results as a CSV file.
fee_history mode — one row per filing with summary totals: accession number, form type, filing date, total offering, total fee, net fee due, fee rate, security class count
line_items mode — one row per security class across all filings: security type, class title, fee calculation rule, amount registered, price per unit, max aggregate offering, fee rate, fee amount
ffd_concepts mode — one row per ffd: XBRL fact entry from the hybrid companyfacts + Exhibit 107 source: concept tag, label, value, unit, form, filing date, accession, source tag
Writes to output_path if provided, otherwise defaults to ./<TICKER>_<mode>.csv
Filterable by form type and max filing count
Example prompts:
"Export Tesla's filing fee history as a CSV"
"Save Goldman Sachs' complete ffd data to C:\Users\me\Desktop\GS_fees.csv"
"Export the line-item breakdown for all of Reddit's S-1 filings"
CSV columns by mode:
Mode | Columns |
|
|
|
|
|
|
Related MCP server: SEC EDGAR MCP Server
URI | Description |
| Complete ffd: XBRL concept reference for Exhibit 107 — per-row and summary-level concepts, fee calculation rules, and historical SEC fee rates |
| Registration form types that require Exhibit 107 — S-1, S-3, F-1, 424B series, merger proxies, with key dates |
Prompt | Description |
| Guides structured analysis of a company's Exhibit 107 fee disclosures — identify the filing, parse the fee table, analyze the fee structure, and summarize |
Node.js v20 or higher
git clone https://github.com/davidtauriello/ffd-mcp.git
cd ffd-mcp
npm install
npm run buildEDGAR_USER_AGENT="YourApp you@email.com" npm startEDGAR_USER_AGENT="YourApp you@email.com" MCP_TRANSPORT_TYPE=http npm start
# Server listens at http://localhost:3010/mcp
# Health check at http://localhost:3010/healthAdd to claude_desktop_config.json:
{
"mcpServers": {
"filing-fee-mcp": {
"command": "node",
"args": ["/path/to/ffd-mcp/dist/index.js"],
"env": {
"EDGAR_USER_AGENT": "YourApp you@email.com"
}
}
}
}claude mcp add filing-fee-mcp -- node /path/to/ffd-mcp/dist/index.jsAdd to mcp.json:
{
"servers": {
"Filing Fee MCP": {
"type": "stdio",
"command": "node",
"args": [
"/path/to/ffd-mcp/dist/index.js"],
"env": {"EDGAR_USER_AGENT" : "YourApp you@email.com"}
}
},
"inputs": []
}Set EDGAR_USER_AGENT in your environment.
Point any client that supports Streamable HTTP at http://your-server:3010/mcp.
docker build -t filing-fee-mcp .
docker run -d -p 3010:3010 -e EDGAR_USER_AGENT="YourApp you@email.com" filing-fee-mcpThe container defaults to HTTP transport on port 3010. Override the port with -e MCP_HTTP_PORT=8080 -p 8080:8080.
The export_fee_data tool writes CSV files inside the container. Mount a volume to make them accessible on the host:
docker run -d -p 3010:3010 -e EDGAR_USER_AGENT="YourApp you@email.com" -v $(pwd)/exports:/app/exports filing-fee-mcpThen use output_path: "/app/exports/GS_fees.csv" and the file appears in ./exports/ on the host.
curl http://localhost:3010/health
# {"status":"ok","server":"filing-fee-mcp-server","version":"1.0.0"}Variable | Required | Default | Description |
| Yes | — | User-Agent header for SEC compliance. Format: |
| No |
| Max requests/second to SEC APIs. Do not exceed 10. |
| No |
| Seconds to cache the company tickers lookup file. |
| No |
| Transport mode: |
| No |
| HTTP server port (only used when transport is |
src/
index.ts # Server entry point (McpServer + transport)
config/
server-config.ts # Environment variable parsing (Zod)
services/edgar/
edgar-client.ts # Rate-limited SEC EDGAR HTTP client
fee-exhibit-parser.ts # Exhibit 107 iXBRL/HTML parser
fee-exhibit-service.ts # Orchestrates client + parser
types.ts # Domain types
mcp-server/
tools/definitions/
get-fee-exhibit.ts # Parse a specific Exhibit 107
search-fee-filings.ts # Find registration filings
get-company-fee-history.ts # Batch-parse fee exhibits
compare-fee-rates.ts # Cross-company comparison
search-filings-by-fee.ts # Full-text search
get-ffd-concepts-by-company.ts # Hybrid companyfacts + parsing
export-fee-data.ts # CSV export
resources/definitions/
fee-taxonomy.ts # ffd: XBRL concept reference
form-types.ts # Registration form types
prompts/definitions/
fee-disclosure-analysis.ts # Guided analysis promptSince February 2022, the SEC requires all registration statement filers to include Exhibit 107 (EX-FILING FEES) — a machine-readable inline XBRL document disclosing every security class, offering amount, fee calculation rule, fee rate, and net fee due.
This server parses those exhibits using regex-based extraction of ffd: namespace XBRL facts from the iXBRL HTML. It handles both inline XBRL (<ix:nonNumeric>, <ix:nonFraction>) and standalone XML (<ffd:Tag>) formats, with a fallback HTML table parser for non-XBRL exhibits.
EDGAR's submissions API lists new filings immediately, but the per-document index and full-text search can lag 24-48 hours behind acceptance. This server handles the gap with:
Retry logic: When a document index returns empty for a filing within the 48h window, retries up to 3 times with increasing delays
Recency warnings: Tools surface an advisory when results touch the lag window
Companyfacts fast path: The get_ffd_concepts_by_company tool reads from the companyfacts API (no lag) for 424B/S-3/S-8 filings, falling back to document parsing only for S-1/F-1 filings
Apache 2.0. See LICENSE.
Compare Exhibit 107 filing fee data across 2-8 companies side by side. Shows the latest registration form, total offering, net fee due, and fee rate for each company. Note: SEC fee rates are uniform — differences reflect rounding or alternate calculation rules.
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | 2-8 company identifiers (ticker, name, or CIK) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the specific output fields (latest registration form, total offering, net fee due, fee rate) and adds an important interpretive caveat about SEC fee rates being uniform and differences reflecting rounding or alternate calculation rules. It does not mention error handling or data source limitations, but the provided context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose in the first sentence. The second sentence adds essential output details and a valuable caveat. Every sentence earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and no output schema, the description adequately explains what the tool does and what it returns. It lists the key fields it shows and includes a necessary note about fee rate interpretation. It is complete enough for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter: companies (2-8 company identifiers). The description adds 'side by side' and lists output fields, but does not add additional parameter semantics beyond what the schema provides. With schema coverage at 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compare Exhibit 107 filing fee data across 2-8 companies side by side.' It names a specific verb ('compare'), a specific resource (Exhibit 107 filing fee data), and a clear scope (2-8 companies), which distinguishes it from sibling tools like get_fee_exhibit or search_fee_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 implies when to use the tool: when you need a side-by-side comparison of fee data for 2-8 companies. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it over single-company lookup or search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query SEC fee data and save it as a CSV file. Three modes: "fee_history" (one row per filing with summary totals), "line_items" (one row per security class across all filings), "ffd_concepts" (one row per ffd: XBRL fact from companyfacts + parsed exhibits). Writes to the specified output_path or defaults to ./_.csv. The CSV text is also returned in structuredContent.csvText so callers can reconstruct the file locally without depending on the server's filesystem.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Export mode: "fee_history" = one row per filing with summary totals; "line_items" = one row per security class across all filings; "ffd_concepts" = one row per ffd: XBRL fact (companyfacts + parsed exhibits) | |
| limit | No | Max filings to fetch (default 10) | |
| company | Yes | Ticker symbol, company name, or CIK number | |
| form_types | No | Filter to specific form types (e.g. ['S-1', 'S-3']) | |
| output_path | No | File path to write the CSV. Defaults to ./<TICKER>_<mode>.csv in the current directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does well by disclosing key side effects: it writes to a specified output_path or defaults to a local file, and it returns CSV text in structuredContent.csvText for local reconstruction. This gives callers a clear understanding of the tool's write behavior and return value, though it stops short of discussing error handling or edge cases.
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, only three sentences, but it packs a lot of information about modes, file output, and return value. Each sentence contributes a distinct piece of context, though the long enumeration of modes makes it slightly 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 absence of an output schema and annotations, this description provides a solid overview of purpose, modes, output behavior, and return format. It doesn't outline the exact CSV column structure for each mode, but that is reasonably inferred from the mode descriptions and is not essential for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema already describes all five parameters at 100% coverage, the description adds limited but meaningful value by clarifying default filename patterns and by expanding on the 'mode' enum with concrete definitions for fee_history, line_items, and ffd_concepts. This goes beyond simply restating parameter names.
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 'Query SEC fee data and save it as a CSV file', identifying a specific verb, resource, and output format. It also enumerates three distinct modes, which helps distinguish this export-focused tool from sibling retrieval tools like get_company_fee_history and get_ffd_concepts_by_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 useful context by explaining the three modes and the default output file, but it does not explicitly contrast this tool with siblings or state when not to use it. For example, it doesn't mention that if no CSV export is needed, callers might prefer get_company_fee_history instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and parse all Exhibit 107 fee exhibits for a company across multiple filings in one call. Returns the full structured fee table for each filing plus grand totals. Best for understanding a company's full offering history and total fees paid. Slower than get_fee_exhibit since it fetches and parses multiple documents.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max filings to parse (default 5). Higher values are slower. | |
| company | Yes | Ticker symbol, company name, or CIK number | |
| form_types | No | Filter to specific form types | |
| start_date | No | Only include filings on or after this date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool fetches and parses multiple documents, returns a structured fee table per filing plus grand totals, and is slower than get_fee_exhibit. This gives a clear behavioral profile for a read-only aggregation tool, though it omits potential edge cases or error 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 three sentences, each earning its place. It front-loads the core action, then describes the return value, then provides use-case and performance context. No filler 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?
In the absence of an output schema, the description does explain the return format ('full structured fee table for each filing plus grand totals'). It also contextualizes the tool's multi-filing nature and performance trade-off. It is fairly complete for a read-only fetch tool, though it does not detail request/response examples or error conditions.
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 full 100% coverage with descriptions for all four parameters. The tool description does not add additional parameter semantics beyond what the schema already provides, but the schema itself is sufficient, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Fetch and parse all Exhibit 107 fee exhibits'), names the resource ('for a company across multiple filings'), and clearly distinguishes itself from the sibling tool get_fee_exhibit by emphasizing the multi-filing scope. This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Best for understanding a company's full offering history and total fees paid' and contrasts with get_fee_exhibit ('Slower than get_fee_exhibit since it fetches and parses multiple documents'). However, it does not explicitly state when NOT to use it or mention other sibling alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and parse a specific Exhibit 107 (EX-FILING FEES) from an SEC filing. Returns all ffd: XBRL concepts: every security class, max aggregate offering, fee amounts, fee rate, and net fee due. Requires accession_number + cik. Provide the exhibit document filename for faster parsing, or let the server auto-detect it.
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | Company CIK number (10-digit zero-padded or raw integer) | |
| accession_number | Yes | SEC filing accession number (e.g. 0001234567-24-000001) | |
| exhibit_filename | No | Exhibit 107 document filename for faster parsing. If omitted, auto-detected from the filing index. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return contents and the auto-detection behavior when exhibit_filename is omitted. However, it does not mention failure modes, error handling, or any side effects, leaving moderate gaps in expected 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?
Three tight sentences cover purpose, required inputs, optional parameter optimization, and return contents with no fluff. Information is front-loaded and every clause contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by detailing the return payload (security classes, offering amounts, fee rates, etc.). It is sufficient for the tool's moderate complexity, though it misses edge cases like 'exhibit not found' or distinguishing from similar fee-seeking tools.
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 parameters are already documented. The description adds semantic value beyond the schema by explaining that exhibit_filename accelerates parsing and that omission triggers server-side auto-detection. It also reinforces the requirement for accession_number and cik, which helps the agent understand the relationship between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch and parse') and a concrete resource ('a specific Exhibit 107 (EX-FILING FEES)'), clearly distinguishing this from sibling search/history tools. It also outlines exactly what is returned (all ffd XBRL concepts), leaving no ambiguity about the tool's scope.
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 clearly states the required inputs (accession_number + cik) and offers optional guidance for faster parsing (exhibit_filename). It does not explicitly compare against sibling tools like search_fee_filings or compare_fee_rates, but the prerequisites and optional behavior provide clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a company's complete ffd: filing fee history by merging two sources: (1) the EDGAR companyfacts API for 424B/S-3/S-8 filings (fast, no lag), and (2) Exhibit 107 document parsing for S-1/F-1 filings that companyfacts doesn't index. Returns all fee-related facts (FeeAmt, NetFeeAmt, TtlOfferingAmt, FeeRate, etc.) across every form type. Each entry is tagged with its source. Use get_fee_exhibit when you need the full per-security-class line-item breakdown for a single filing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max registration filings to parse in the Exhibit 107 backfill phase (default 10). Only affects S-1/F-1 filings that companyfacts misses. | |
| company | Yes | Ticker symbol, company name, or CIK number | |
| concepts | No | Filter to specific ffd concept tags (e.g. ['FeeAmt', 'NetFeeAmt']). Omit to return every ffd: concept on file. | |
| form_types | No | Filter fact entries to specific form types (e.g. ['S-1', 'S-3']). Omit to include all form types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses the internal merge logic (companyfacts API plus Exhibit 107 parsing), notes the lag characteristics of each source, and mentions that each entry is tagged with its source. It does not address potential rate limits or error behavior, but the key behavioral trait—data assembly from multiple sources—is well documented.
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 well-structured and front-loaded. The first sentence states the core purpose, subsequent sentences provide essential behavioral details, and the final sentence gives an alternative tool pointer. Every sentence contributes useful information without padding.
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, a non-trivial merge of two sources, and no output schema, the description is nearly complete. It covers the main purpose, source behavior, filtering options, and alternative tools. It does not detail the exact return structure (e.g., field names), but the tool name and description imply a list of tagged fee facts, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that 'limit' only affects the Exhibit 107 backfill phase, and clarifies the semantics of 'concepts' and 'form_types' filters (e.g., omitting returns everything). This goes beyond the schema's property 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's purpose: to get a company's complete ffd (filing fee history) by merging two data sources. It specifies the resource (fee-related facts across form types) and explicitly distinguishes itself from the sibling tool get_fee_exhibit, which is used for a different granularity of data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance: it explains when this tool is appropriate (complete filing fee history across form types) and explicitly names an alternative (get_fee_exhibit for per-security-class line-item breakdowns of a single filing). It also clarifies the role of the limit parameter in the backfill phase, giving actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a company's recent registration statement filings that contain Exhibit 107 fee disclosures. Returns accession numbers, form types, filing dates, and EDGAR URLs. Use the results to call get_fee_exhibit for full fee table parsing. Resolves tickers, company names, or CIK numbers automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max filings to return (default 10) | |
| company | Yes | Ticker symbol, company name, or CIK number | |
| form_types | No | Filter to specific form types (e.g. ['S-1', 'S-3']). Defaults to all registration forms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses return fields and the input resolution behavior, which is solid. It omits potential limitations (e.g., what 'recent' means, error handling) but is sufficiently informative for a read-only search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences: purpose, return fields, and workflow. No redundant fluff, front-loaded with the most important 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?
For a simple search tool with 3 params and no output schema, it covers the essential aspects: what it finds, what it returns, and how to proceed. It does not detail ordering/pagination but the limit param in schema addresses one form of control.
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 each parameter already described. The description adds minimal param-specific semantics beyond emphasizing automatic identifier resolution, which is also in the schema. Thus the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds registration statement filings with Exhibit 107 fee disclosures, and specifies the returned fields (accession numbers, form types, filing dates, EDGAR URLs). It differentiates from siblings by directing users to call get_fee_exhibit for full parsing, establishing a clear niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete workflow by instructing to use results with get_fee_exhibit, and states input resolution (tickers, names, CIKs). It does not explicitly list exclusions or alternatives like search_filings_by_fee, but the tool's role is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all EDGAR filing documents since 1993, scoped to registration statements. Use to find all companies that registered a specific security type, used a specific rule (e.g. 457(o)), or mention specific terms in their fee exhibits. Supports phrases, boolean operators, and wildcards.
| Name | Required | Description | Default |
|---|---|---|---|
| forms | No | Form types to search (defaults to registration statements) | |
| limit | No | Max results (default 20) | |
| query | Yes | Full-text search query. Supports phrases ("exact match"), boolean (AND/OR/NOT), and wildcards (*). | |
| end_date | No | End date filter (YYYY-MM-DD) | |
| start_date | No | Start date filter (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the full-text search scope, the 1993 time limit, and support for phrases/boolean/wildcards. However, it does not clarify whether the tool returns filings or companies, nor does it mention read-only nature, pagination, or rate limits—leaving some behavioral ambiguity.
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 three-sentence description is front-loaded with the core action, followed by usage examples and search capabilities. Each sentence adds value with no redundancy, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers scope and use cases well, but the lack of an output schema makes the return value ambiguous (filings vs. companies). It also does not explicitly differentiate from the sibling 'search_fee_filings', which could hinder tool selection in an agentic context.
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 covers 100% of the parameters with descriptions, so the baseline is 3. The description adds context by emphasizing full-text search and registration statement scope, and gives query examples (e.g., rule 457(o)), but it does not add meaning to date or limit parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('full-text search'), the resource ('all EDGAR filing documents since 1993'), and the scope ('registration statements'), with concrete use cases like finding companies by security type or rule. This distinguishes it from broader sibling tools such as 'search_fee_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 gives explicit usage scenarios: 'find all companies that registered a specific security type, used a specific rule... or mention specific terms in their fee exhibits.' It does not explicitly name alternative tools or exclusion criteria, but the 'scoped to registration statements' phrasing implies its specialized niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0compare_fee_ratesexport_fee_dataget_company_fee_historyget_fee_exhibitget_ffd_concepts_by_companysearch_fee_filingssearch_filings_by_feeTools are mostly distinct, but get_company_fee_history and get_ffd_concepts_by_company both provide fee history for a company, which could cause selection confusion. All other tools have clear boundaries.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_fee_exhibit, search_fee_filings, export_fee_data), making the API predictable and easy to navigate.
Seven tools are well-scoped for the domain of SEC fee data, covering all key workflows without being overwhelming. Each tool serves a clear purpose, and none feel redundant.
The set covers discovery (search_fee_filings, search_filings_by_fee), extraction (get_fee_exhibit, get_ffd_concepts_by_company), comparison (compare_fee_rates), historical analysis (get_company_fee_history), and export (export_fee_data). There are no obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cross-model evidence pipeline for financial filings & contracts. x402 pay-per-call.
Scrape SEC EDGAR filings by company, form type, date, or full text. Pay per row.
Access SEC filings efficiently (10-K, 10-Q, etc), save time and tokens, and get cited answers.
SEC/XBRL issuer intelligence for crypto public companies via MCP, OpenAPI, x402, and MPP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidtauriello/ffd-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
