Loading ToolBench
MCP server integrating Jira, MySQL, MSSQL, and Git
This server exposes 12 tools across Git, Jira, MySQL, and MSSQL with visible Zod schemas and descriptions. However, significant quality gaps prevent a higher score: (1) Descriptions are present but generic and lack actionable context for LLM selection, most are under 100 chars and don't explain WHEN to use the tool or what to do with the output. (2) Parameter descriptions are minimal; many parameters lack context about valid ranges, formats, or dependencies. (3) No output schemas are documented, LLMs cannot predict what fields they'll receive. (4) No error handling guidance, failures will not tell agents what to do next. (5) Critical security issue: mysql_query and mssql_query accept raw SQL strings, inviting SQL injection if the tool is called by an untrusted agent. (6) Multiple tools share similar names (mysql_add_user / mssql_add_user, mysql_get_users / mssql_get_users) without clear distinctions. (7) No pagination support documented; tools like jira_get_issues and mysql_get_users could return unbounded result sets. (8) Tool composition is scattered across unrelated domains (Git, Jira, databases) without clear use-case patterns.
Get the current Git repository status: branch, modified files, ahead/behind
Create a new Jira Epic in the project
Create a new Jira Story from a user record
Create a Sub-task under an existing Jira issue
Get Jira issues for a project ordered by creation date
Insert a row into an MSSQL table
Create a new MSSQL database
Raw SQL execution tools (mysql_query, mssql_query) accept unsanitized SQL strings from agents, creating SQL injection vulnerability if called by untrusted/compromised agents. No input validation or parameterization visible.
No output schemas documented for any tool. LLMs cannot predict response structure, making it impossible to chain tools or extract specific fields without trial-and-error parsing.
Tool descriptions are generic and under 100 chars for most tools. They state WHAT the tool does but not WHEN to use it vs. similar tools, what prerequisites exist, or what the agent should do with results. Example: 'Get all rows from a MySQL table', when should the LLM call this vs. mysql_query? What if it returns 10,000 rows?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Get all rows from an MSSQL table
Insert a row into a MySQL table
Create a new MySQL database
Get all rows from a MySQL table
Execute a raw SQL query on a MySQL database (e.g. SELECT, SHOW TABLES, DESCRIBE)
No error handling guidance. Tools return JSON via HTTP, but if a call fails (database down, invalid query, permission denied), there is no recovery hint for the agent. A raw 500 error tells the LLM nothing.
Confusing similar names across database engines: mysql_add_user / mssql_add_user; mysql_get_users / mssql_get_users. LLMs may conflate them or pick the wrong database. Consider prefixing with database name or clearer ENUM-style parameters.
No pagination support documented for list/get tools (jira_get_issues, mysql_get_users, mssql_get_users). These tools could return unbounded result sets, blowing context windows and costing tokens. Jira and MySQL requests should accept limit/offset params and document max result limits.
Parameter descriptions lack context. 'db' and 'table' are bare strings with no guidance on valid names, character restrictions, or examples. 'sql' parameter has no warning about injection risk or statement type restrictions. LLMs need explicit constraints to avoid invalid input.
No indication which tools require authentication or have permission gates. All database and Jira tools modify or read sensitive data, but the descriptions don't clarify what credentials are needed or what scope/permissions the agent must have.
No audit trail or logging mentioned. Agent calls to destructive tools (create database, add user, modify Jira issues) are not logged, making incident response and compliance audits difficult.
jira_create_story accepts firstName, lastName, email, phone, active, but the description says 'Create a new Jira Story from a user record'. This is confusing: is it creating a Story (issue) or a User (person)? The parameter names suggest user data, not story data. This risks misuse.