Loading ToolBench
Model Context Protocol server for the ServiceNow platform with 480+ auto-generated tools, multi-instance support, and natural language search
The server defines 11 tools with mixed quality. Strengths: most tools have descriptions and input schemas with parameters properly typed. Weaknesses: many descriptions are generic or lack actionable context; several tools lack comprehensive parameter descriptions; no output schemas documented; error handling guidance is minimal; naming conventions are inconsistent (SN- prefix is non-standard and does not follow verb-noun pattern). The docs tools (SN-Docs-*) have reasonable schemas but minimal guidance on when to use each. The instance and query tools (SN-Query-Table, SN-Create-Record, SN-Get-Record) are broad but lack constraints on dangerous operations (create/query on any table without guardrails). Average tool score: 58/100.
Create a record in any ServiceNow table by name. WARNING: For catalog_ui_policy_action table, fields ui_policy and catalog_variable cannot be set via REST API - use SN-Execute-Background-Script with setValue() after creation.
List available ServiceNow documentation families/releases from the official ServiceNowDocs GitHub repository.
Retrieve a ServiceNow documentation markdown document by family and path.
Search locally synced ServiceNow documentation using SQLite FTS, with optional vector search when enabled.
Show local ServiceNow docs cache, FTS index, and optional vector index status.
Download and index a ServiceNowDocs family into the local SQLite FTS cache.
Naming convention does not follow verb-noun pattern. Tools use 'SN-Docs-*' and 'SN-*' prefixes instead of action verbs like 'list_docs', 'search_docs', 'get_instance', 'query_table'. This makes tool intent ambiguous and forces LLM to read descriptions rather than inferring action from name.
SN-Query-Table accepts 'table_name' and arbitrary queries without schema validation or constraints. Description lacks safety guardrails: 'Query any ServiceNow table by name with flexible filtering' invites agents to query sensitive tables (sys_user_grmember, sys_auth_token, etc.). No mention of which tables are off-limits or rate limits. Missing destructive/readOnlyHint annotation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get information about the currently active ServiceNow instance
Get a specific record from any ServiceNow table by sys_id
Query any ServiceNow table by name with flexible filtering
Register non-secret ServiceNow instance metadata using credentials already stored by the local CLI.
Switch to a different ServiceNow instance. Use this at the start of your session to target a specific instance (dev, test, prod, etc.). Lists available instances if no name provided.
SN-Create-Record description includes a footnote about catalog_ui_policy_action requiring a workaround, but the workaround tool (SN-Execute-Background-Script) is NOT listed in the tools inventory. This broken reference leaves agents unable to complete the workflow. Missing tool composition.
No output schemas documented for any tool. Descriptions say what tools do but not what fields they return. LLMs cannot plan downstream calls or extract the right data from responses.
Descriptions lack actionable context on WHEN to use each tool. SN-Docs-Search vs SN-Docs-Get both retrieve docs but the distinction is unclear. 'Search locally synced ServiceNow documentation using SQLite FTS' does not explain whether to use this for broad exploration or precise lookups. When should the LLM call it instead of a similar tool?'
SN-Register-Instance schema includes conditional parameters (grantType, username, clientId are only valid for specific authType values) but does NOT document these dependencies. Parameter descriptions do not state 'Only valid when authType=oauth' or similar.
SN-Docs-Families and SN-Docs-Status have empty input schemas (no properties). This is correct, but descriptions do not explain what these tools return or how the output should be used downstream. No guidance on typical response structure.
SN-Query-Table and SN-Create-Record lack bounds on numeric parameters. 'limit' defaults to 25 with no maximum stated; 'offset' has no bounds.
Error handling and recovery guidance is absent from all tool descriptions. No mention of what errors might occur, how to recover, or when to retry.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are NOT present in tool definitions, despite HTTP/SSE transport supporting them. SN-Create-Record and SN-Query-Table should have destructiveHint and readOnlyHint respectively. This misses protocol capability for better agent planning.