Loading ToolBench
Unified ServiceNow MCP server with 400+ snow_* tools, blast-radius analysis, stdio + HTTP transports, and enterprise proxy support for lazy-loaded integration tools (Jira, Azure DevOps, Confluence, GitHub, GitLab, Process Mining).
This server exposes 4 meta-tools that act as discovery and execution wrappers around a larger enterprise tool ecosystem (76+ tools claimed). However, the 4 primary tools have significant quality gaps: descriptions are present but generic, parameters lack proper type constraints, and most critically, the actual enterprise tools being wrapped are not directly visible in the provided source code. The tool_search and enterprise_tool_search tools claim to return 'full schemas' but those schemas are not documented in the definitions themselves. The server follows a proxy pattern where tools are 'enabled' dynamically after search, which creates a bootstrapping problem, agents cannot plan tool use without calling search first, and the downstream tools' quality is opaque. Schema definitions are minimal (additionalProperties:true on args is a red flag), and error handling strategies are not evident. The HTTP transport is positive, but the definition quality does not support confident production use.
Execute an enterprise tool by name. Use enterprise_tool_search first to discover available tools. After searching, tools are enabled and can also be called directly by name without this wrapper.
Search through 76+ enterprise integration tools (Jira, Azure DevOps, Confluence, GitHub, GitLab, Process Mining). Returns matching tools with their full schemas. Found tools are automatically enabled for the session so you can call them directly. Always search before using an enterprise tool for the first time.
Meta-tool for executing an enabled enterprise tool by name. Use tool_search first to discover available tools. After searching, tools are enabled and can also be called directly by name.
Meta-tool for searching through available tools by name, domain, or action keywords. Returns matching tools with their full schemas and automatically enables them for the session.
Tool definitions are wrappers with opaque downstream schemas. The 4 primary tools claim to return full schemas for 76+ enterprise tools, but those schemas are not included in the primary tool definitions. Agents cannot validate parameters against the actual downstream tools without calling search first, then parsing the response for schema info, then calling execute. This is a multi-round-trip discovery tax and violates the single-responsibility principle.
'args' parameter in tool_execute and enterprise_tool_execute is defined as 'object' with additionalProperties:true, providing zero type safety or validation guidance. LLMs cannot infer what parameters to pass without explicit per-tool schema documentation. This violates pattern:constrained-input and pattern:tool-description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Output schemas are not documented for any of the 4 tools. Agents do not know what fields search results contain, how to extract tool names or schemas, or what pagination structure to expect. This violates pattern:tool and makes downstream planning unreliable.
Description for tool_search and enterprise_tool_search include example values ('jira_create_issue', 'confluence') in the parameter descriptions. Per pattern:tool-description, examples in descriptions risk LLMs treating them as literal required values or the only valid options. Use enums or formal constraints instead.
No error handling guidance. Descriptions do not explain what happens if a tool is not found, if args are invalid, or if the downstream service fails. Per pattern:recovery-guide, error responses should tell the LLM what to do next (e.g., 'Try a broader search query' or 'Check the tool schema returned by enterprise_tool_search').
The 'enable' parameter (default: true) in search tools could enable tools unintentionally. Per pattern:default-values, defaults must not cause unintended side effects. If 'enable' defaults to true, agents may be surprised when a search call silently enables tools. Document the implications or default to false.
No documentation of idempotency. If an agent retries tool_execute with the same args, does it re-execute the downstream tool (risk of duplicate side effects like creating two tickets)? Per pattern:idempotent-operation, agents retry on ambiguous failures, the server must clarify whether repeated calls are safe.