Loading ToolBench
MCP server that exposes tools for searching knowledge base and incident records in MySQL databases, creating incidents, and sending mock email notifications for testing incident management workflows
This server has 4 tools with reasonable descriptions and type-annotated parameters, but falls short of production quality due to missing output schema documentation, incomplete parameter descriptions, and absence of security/error-handling guidance. Tool naming is clear (search_*, create_*, email_send_mock), but schema completeness and parameter detail vary. Average across tools: 62/100.
Insert a new incident record into the incident database.
Simulates sending an email notification (mock only).
Search Incident records using meaningful keywords.
Search Knowledge Base articles using meaningful keywords.
No output schemas documented for any tool. LLMs cannot predict response structure (fields, types, array vs object). This forces agents to make assumptions or fail on unexpected shapes.
search_knowledge_base and search_incidents have no pagination guidance. Tool description does not mention 'limit' parameter or note that results may be truncated. The 'limit' default of 10 is good, but LLMs should be told that exceeding context window is a risk with large result sets.
No error handling guidance. Tools do not document what happens if database is unavailable, SQL query fails, or parameters are invalid. Responses do not guide LLM on recovery (retry, ask user, fail). For example, create_incident will fail silently if the incident number already exists or if the database connection is lost.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
create_incident has no confirmation or dry-run mechanism. This is a destructive write operation that inserts into the database. If an LLM makes a mistake (wrong incident number, incorrect description), there is no undo tool and no way to preview before committing.
Database credentials (DB_HOST, DB_USER, DB_PASS) are hardcoded in server.py. Credentials must never be in source code. Use environment variables or a secrets manager (e.g., os.getenv('DB_PASS')).
No permission gates. Any agent or caller can search incidents, create incidents, or send emails without authentication or authorization checks. Destructive operations like create_incident should verify the caller has 'write:incident' permission.
No audit logging. The server logs to INFO level but does not record who called which tool, with what parameters, or what the outcome was. This is essential for compliance, debugging, and incident response in production incident management.
SQL injection risk. search_knowledge_base and search_incidents build SQL with user-provided keywords but use parameterized queries (good). However, the keyword extraction and filtering logic (stopwords) could be bypassed. More critically, there is no input validation or length limits on the 'short_description_contains' parameter. A 10MB string will be processed, potentially causing DoS.
create_incident parameter 'opened' requires ISO timestamp but description does not specify format (YYYY-MM-DDTHH:MM:SSZ). LLMs will guess; many will provide local timestamps or wrong formats. The constraint should be explicit in the description.
email_send_mock tool name is ambiguous. The 'mock' suffix confuses the intended behavior, is this a real email that happens to be named 'mock', or a simulation? Rename to 'send_email_mock' or 'send_email_simulation' and clarify in the description that NO EMAIL IS ACTUALLY SENT.