Skip to main content
Glama
cfpb-complaints-mcp

cfpb-complaints-mcp

by bnovarini

trend

Track CFPB complaint counts by month, quarter, or year for one filter set—company, product, issue, state, or date range—to reveal changes over time.

Instructions

Complaints over time (month, quarter or year), for one filter set. Set period to month, quarter or year. The latest period is partial. In progress and Untimely response are CFPB response categories, not outcomes. Filters: company (exact name as in find_company), company_contains (substring), product, sub_product, issue, product: CFPB renamed credit reporting twice, so it appears under three product names (use list_values field=product), company_response (exact CFPB value, case-insensitive), submitted_via, state (2 letters), tag (e.g. 'Servicemember', 'Older American'), timely (true/false), date_from/date_to (YYYY-MM-DD or YYYY-MM, on date received).

Input Schema

NameRequiredDescriptionDefault
tagNo
issueNo
stateNo
periodNomonth
companyNo
date_toNo
productNo
date_fromNo
submitted_viaNo
company_containsNo
company_responseNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations the description carries the full burden, and it does disclose non-obvious data semantics: the latest period is partial, 'In progress'/'Untimely response' are response categories not outcomes, and product names were renamed by CFPB. It stops short of stating read-only behavior or any result-size limits.

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?

Purpose and caveats are front-loaded before a compact filter list. Dense but every clause carries semantic content; the only waste is scope noise such as mentioning sub_product and timely, which are not in the schema.

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?

An output schema exists so return format need not be explained, and the filter semantics, period behavior and data caveats are covered. What is missing is the relationship to sibling tools and how multiple filters combine (AND semantics) for an 11-parameter query.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and it largely does: exact vs substring matching for company vs company_contains, case-insensitivity for company_response, 2-letter state format, YYYY-MM-DD/YYYY-MM date formats, and the date-received basis. It even adds guidance to use list_values for disambiguated product names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: aggregated complaints over time at month/quarter/year granularity for a single filter set. An agent can distinguish it from complaint_counts or company_profile, though the description never names an alternative explicitly.

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?

It explains how to fill in filters and what period values mean, which implies the use case, but it never says when to choose this tool over siblings like complaint_counts or compare_companies. Usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.