Find public problem reports and submit approved observations for private CleanApp review.
Scored across 5 tools
The tools mostly map to distinct steps and resources: opening the app, preparing a report, submitting it, checking status, and searching existing reports. The main overlap is that cleanapp_open mentions reporting problems, which could be confused with cleanapp_prepare_report, though the descriptions otherwise clarify the workflow boundaries.
All tool names use a consistent cleanapp_ prefix plus snake_case action-oriented phrasing. The verb patterns are predictable (open, prepare_report, report_status, search_reports, submit_report) and no mixed conventions appear.
Five tools is well-scoped for a focused reporting miniapp workflow. Each tool earns its place by covering a distinct stage: entry, draft preparation, submission, status lookup, and public search.
The core lifecycle is covered: open/browse, prepare, submit, check status, and search existing reports. Minor gaps remain around editing or withdrawing a submitted report and retrieving full report details, but the main reporting workflow is complete.
Use this when the user wants to open CleanApp, report a real-world or digital problem, or browse the CleanApp miniapp. Do not use for household cleaning advice or computer disk-cleaning tasks.
Inputs: no named parameters. Returns: view, message
Use this when the user wants to report an observed physical or digital problem: a pothole, dumped waste, unsafe infrastructure, accessibility barrier, pollution, software bug, suspected scam or service failure. Prepare a factual preview from user-provided details. No submission occurs. Ask for the affected place or product if missing; never infer precise location. Do not use for general discussion or emergency dispatch.
Inputs: title (required), domain (required), description (required), problem_type (required), +5 more. Returns: view, message
Use this when the user asks what happened to their CleanApp submission and supplies the private tracking token returned for that report. Returns intake status and lane only, not proof of notification or resolution. Never search for another user’s receipt or guess identifiers.
Inputs: tracking_token (required). Returns: view, message
Use this when the user wants existing CleanApp observations about potholes, litter, illegal dumping, accessibility barriers, infrastructure damage, pollution, software bugs, scams or service problems. The brand need not be mentioned. Returns historical public reports, not an exhaustive or real-time hazard map. Do not use for generic advice, emergency dispatch or private records.
Inputs: query (required), limit, domain, language. Returns: view, message
Use this only after the user approves the exact preview from cleanapp_prepare_report and sending it to CleanApp. Submits to CleanApp’s quarantine review lane and returns a private receipt. Not public publication, emergency dispatch, guaranteed routing or resolution. Reuse the same draft_token on retry. After timeout, check the returned tracking_token before retrying.
Inputs: confirmed (required), draft_token (required). Returns: view, message
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Review connected software projects, submit local findings and read reports with explicit approval.
Search solutions from agent work; optionally publish evidence, report reuse and link improvements.
Synthetic UX reviews, findings, evidence images, and repair prompts. OAuth required.
Finds Trustpilot reviews that break Trustpilot's guidelines and drafts the reports for them.
Add one secure layer between your agents and this server.
