Loading ToolBench
MCP server for processing SEC filings, including downloading, converting HTML to PDF, and extracting markdown content from documents
This MCP server exhibits significant quality gaps across naming, descriptions, and schema completeness. While all three tools are explicitly registered with FastMCP and have basic input schemas, the definitions fall short of production standards. Tool names use wrapper prefixes ('wrapped_*') rather than action verbs, descriptions are terse (10-26 chars, well below the 194-char average), and parameter descriptions are minimal. The server lacks output schema documentation, error handling guidance, and composition clarity. No parameters are validated against constraints (e.g., enums for filing_type, format validation for file paths). Security concerns include file path injection risks and lack of input sanitization.
Convert HTM/HTML to PDF
Convert PDF to MarkDown
Download the latest SEC filing data.
Tool names lack action verbs and use 'wrapped_' prefix. Names like 'wrapped_sec_filing_downloader' obscure intent, should be 'download_sec_filing'. Wrapper prefix violates verb_noun naming convention and signals unnecessary abstraction layer.
Descriptions critically short (10 - 26 chars, far below 194-char baseline). 'Download the latest SEC filing data' and 'Convert HTM/HTML to PDF' lack context for LLM selection. Missing: when to use, prerequisites, what is returned, any constraints.
No output schema documentation. Tools return strings (file paths or markdown content) but LLM does not know what to expect. 'download_sec_filing' returns 'result_path' (string), but is it absolute? relative? can it be empty? No guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 26 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Parameter 'filing_type' in wrapped_sec_filing_downloader accepts free-form string with no enum or constraint. SEC has specific forms (10-K, 10-Q, 8-K, etc.), LLM will hallucinate invalid values. Should be constrained enum or at least documented with examples.
File path parameters ('input_file_path', 'output_file_path', 'output_dir_path') lack validation and are vulnerable to path traversal. No check for absolute vs relative paths, no restriction on directory targets. Malicious or confused input could write outside intended directory.
No error handling guidance. Functions raise generic exceptions ('raise' with no message in process_data, empty 'except' in download_and_extract). LLM receives stack traces, not actionable errors like 'Filing type not found for 2024. Try: 10-K, 10-Q, 8-K'.
Parameters lack descriptions in FastMCP registration. While function docstrings document params (e.g. 'cik: Central Index Key'), FastMCP @mcp.tool() decorator shows no descriptions for 'cik', 'year', 'filing_type', 'output_dir_path'. LLM sees parameter names only.
No composition or chaining. If an agent wants to: download SEC filing → convert HTML to PDF → read as markdown, it must call three separate tools. No batch variant, no pipeline tool, no intermediate result reuse, forces 3 round-trips and manual path threading.
Async/sync inconsistency. wrapped_html_to_pdf is async, others are sync. FastMCP may handle this, but the mixing increases cognitive load and risks deadlocks if called from sync contexts.