Loading ToolBench
An MCP server that acts as an intermediary between clients and the ServiceNow REST API, providing optimized protocol for efficient communication and operations management.
This MCP ServiceNow server has 5 tools with basic definitions but significant gaps in quality. Tool names follow verb_noun patterns (get, create, update, delete) which is good. However, parameter descriptions are sparse and inconsistent. Several tools lack detailed parameter documentation. Input schemas are present but minimal. No output schemas are documented. Error handling lacks recovery guidance. The code shows custom TCP socket implementation rather than standard MCP transport.
Create a new incident in ServiceNow through the MCP server.
Delete an incident from ServiceNow through the MCP server.
Retrieve a specific incident from ServiceNow through the MCP server.
Retrieve a list of incidents from ServiceNow through the MCP server.
Update an existing incident in ServiceNow through the MCP server.
createIncident has vague 'incident' parameter typed as object with only description 'incident data to create'. No schema for the object structure, field constraints, required fields, or examples. LLMs cannot determine what fields to pass.
updateIncident similarly has an 'incident' parameter of type object with minimal description. No guidance on which fields can be updated, format requirements, or partial vs full object semantics.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls without knowing what fields are returned. For example, getIncidents should document pagination structure, field names in incident objects, and total count.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Destructive tool (deleteIncident) lacks confirmation or dry-run pattern. No error message instructs recovery. Description says 'Delete an incident' but does not warn of irreversibility or suggest confirmation step.
getIncidents has 'limit' parameter but no documented range (e.g., 1-100). Unbounded integers let LLMs request thousands of incidents, causing performance issues or API timeouts.
Tool descriptions are generic and under 100 characters. 'Retrieve a list of incidents from ServiceNow through the MCP server.' does not explain WHEN to use this tool vs getIncident, what query syntax is expected, or what the response contains.
No pagination guidance. getIncidents accepts 'limit' but no 'offset', 'page', or 'cursor' parameter. If results are large, the tool cannot iterate through all incidents.
Error handling is not visible in tool definitions. No guidance on what happens if incident is not found, if query is malformed, or if ServiceNow API fails. Error responses should guide recovery (e.g., 'Try searching with fewer filters').
getIncidents query parameter lacks format specification. Is it a ServiceNow query syntax string? A SQL-like filter? Whitespace-separated keywords? Description does not clarify, forcing LLMs to guess.