Loading ToolBench
AI-powered civic infrastructure reporting system for Bengaluru that classifies complaints, generates emails and tweets, and monitors Twitter for infrastructure issues
This server presents 12 tools across an HTTP API, but exhibits significant gaps in definition quality. While tool names use action verbs (classify, generate, create, list, get, post, notify, monitor), many lack adequate parameter descriptions and schema clarity. The gateway server (mcp-gateway/server.js) shows manual HTTP parsing without formal MCP protocol implementation. Descriptions are present but often generic. Critical issues: (1) tools infer input schemas from code rather than explicit registration; (2) parameters lack comprehensive descriptions; (3) no visible output schema documentation; (4) error handling is minimal; (5) file upload handling (photo parameter in create.report) lacks validation or format constraints; (6) multiple tools with combined responsibilities (e.g., monitor.twitter both monitors AND posts replies, generate.email AND generate.tweet do similar work). The server appears to be a Next.js API gateway wrapping Cerebras LLM calls, not a proper MCP server implementation.
Classify infrastructure reports into category and severity using Cerebras LLaMA AI via MCP gateway
Create new infrastructure report with photo, description, and GPS location
Generate formal email to Bangalore civic authorities about infrastructure issues
Generate civic infrastructure tweet for Bangalore authorities mentioning relevant handles and locations
Get current AI classification usage statistics for cost control
Check health status of server and connected services (PostgreSQL, MCP gateway)
Retrieve photo attachment for a specific infrastructure report
No formal MCP server implementation detected. Code shows Next.js HTTP API routes and a minimal Node.js HTTP gateway (mcp-gateway/server.js) that manually parse JSON without MCP protocol compliance. Tool definitions are inferred from route handlers, not explicitly registered with the MCP server.
Tool parameter schemas lack required descriptions for several fields. For example, create.report's 'lat' and 'lng' parameters have minimal descriptions ('Latitude coordinate', 'Longitude coordinate') with no mention of valid ranges (-90 to 90, -180 to 180), validation rules, or edge cases. notify.email and post.tweet only specify reportId with no enum, format, or lookup guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Retrieve civic budget allocations and contractor information with optional filtering
Retrieve paginated list of infrastructure reports with optional search filter
Monitor Twitter mentions and replies for infrastructure complaints, classify them, generate AI responses, and post replies
Send email notification to civic authorities about infrastructure report with optional photo attachment
Post infrastructure report as tweet to Twitter with optional photo attachment, respecting daily rate limits
No output schemas documented for any tool. Callers cannot know what fields to expect in responses. For instance, classify.report returns {category, severity, simulated} based on code inspection (mcp-gateway/server.js lines 60 - 72), but this is not formally declared. generate.email and generate.tweet return {subject, body} and {tweet_content, ...} respectively, but these are inferred, not documented.
File upload handling (photo parameter in create.report) has no validation constraints. No mention of file size limits, accepted MIME types (JPEG, JPG, PNG are stated but not enforced in schema), image dimensions, or storage location. Agents cannot reason about what files are safe to upload.
monitor.twitter tool has empty input schema {} and a vague description ('Monitor Twitter mentions and replies...'). It is not clear what triggers the monitor, what parameters control filtering (time range? search keywords? account to monitor?), or what the output structure is. This violates single-responsibility principle, it both retrieves mentions AND generates responses AND posts tweets in one tool.
Minimal error handling guidance. Tools return raw HTTP status codes and error messages (e.g., mcp-gateway/server.js line 75: 'Invalid JSON from Cerebras'). No indication of retryability, user-fixable errors, or recovery actions. For example, if Cerebras API fails, the agent receives an error but has no guidance on whether to retry, adjust input, or escalate.
Naming ambiguities and tool overlap. generate.email and generate.tweet both prepare content to be sent; notify.email and post.tweet both send that content. The naming does not make this split clear, an LLM may call notify.email expecting it to generate AND send, or call generate.email then forget to send. Recommend renaming to clarify: prepare_email_notification / send_email_notification.
Credentials and API keys exposed in code. CEREBRAS_API_KEY is injected as an environment variable (mcp-gateway/server.js line 6), which is correct. However, Twitter API tokens (twitter-api-v2 library in package.json) are likely configured similarly. No evidence of token rotation, scoping to least-privilege, or rate limiting. No audit logging of who called what tool.
Pagination not implemented. list.reports accepts limit (1-100, default 50) and q (search query), but there is no offset, cursor, total count, or has_more field in the response. Large result sets could exceed LLM context windows, and agents cannot iterate through all reports.
Destructive operations (delete via PUT /reports/[id]/delete, if it exists, or modify via POST) lack confirmation or dry-run patterns. No evidence of idempotency checks. An agent could retry a failed POST /reports in a loop, creating duplicate reports.