Loading ToolBench
You are a helpful assistant that can search and fetch FCC filings.
This server has critical gaps in definition quality. All three tools have explicit schemas and descriptions visible in server.py, but the descriptions are generic and many parameters lack any guidance. The get_api_key tool exposes a security anti-pattern (though mitigated by not requiring parameters). The search and fetch tools have acceptable parameter typing but descriptions lack actionable detail for LLM decision-making. Output schemas are undocumented. Error handling is absent, no guidance on retries, user-fixable errors, or recovery paths. The server follows basic FastMCP conventions but does not align with production tool patterns.
Fetch a single FCC filing by Submission ID using the /filing/{id_submission} endpoint.
Get the API key from the environment variable
Search for FCC filings using the /filings endpoint. All parameters are optional except the API key (from env).
get_api_key tool exposes credential retrieval as a callable operation. This violates the secret-injection pattern, credentials should never be exposed to agents.
Output schemas are completely undocumented. LLMs cannot plan downstream tool calls or understand what fields to extract from search() and fetch() responses. This forces LLMs to guess or call the API blindly.
No error handling or recovery guidance. If search() returns 0 results, fetch() fails with a 404, or the API times out, the server provides no actionable message. LLMs cannot self-correct or retry intelligently.
Parameter descriptions lack constraints and format guidance. 'id_submission' is required but has no pattern, length bounds, or examples. 'q' lacks guidance on valid query syntax or length limits. 'limit' and 'offset' lack min/max bounds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Incomplete parameter implementation. Date filter parameters (date_submission, date_received, date_disseminated, date_comment_period, date_reply_comment) are declared in the schema but commented out in the function body. Sort and offset are similarly inconsistent. This creates confusion about which parameters actually work.
Tool descriptions do not explain when to use search vs fetch, or what the FCC ECFS API returns. A user reading 'Search for FCC filings' does not know whether results are paginated, how many are returned by default, or if they contain the full filing content.
No pagination guidance. search() declares limit and offset parameters, but does not document maximum result count, whether offsets are zero-based, or if a total count is returned. Without this, LLMs cannot compose safe pagination loops.