ffd-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

ffd-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![ffd-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/davidtauriello/ffd-mcp/badges/card.svg)](https://glama.ai/mcp/servers/davidtauriello/ffd-mcp)

Score Badge

Copy to your README.md:

[![ffd-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/davidtauriello/ffd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/davidtauriello/ffd-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![ffd-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fdavidtauriello%2Fffd-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/davidtauriello/ffd-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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