sn-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SN_INSTANCE | Yes | The ServiceNow instance URL, e.g. https://dev123456.service-now.com | |
| SN_PASSWORD | Yes | The password for Basic auth against the ServiceNow instance | |
| SN_USERNAME | Yes | The username for Basic auth against the ServiceNow instance | |
| BUILDER_MODE | No | Set to 'true' to enable write tools (create, update, delete, execute_script). Leave unset or set to 'false' to keep them disabled. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| query_tableA | Query any ServiceNow table using a sysparm_query filter. Use this to find records — incidents, change requests, hardware assets, anything. Returns human-readable display values for reference fields. Subject to the table + field allowlist; some tables and fields will be denied. |
| get_recordA | Fetch a single ServiceNow record by its sys_id. Use this when you already know the sys_id from a prior query_table call and need the full details of that specific record. Subject to the table + field allowlist. |
| search_kbA | Search the ServiceNow knowledge base for published articles matching a text query. Use this when the user is asking how to do something, troubleshooting, or looking for documented procedures. Only returns published articles. Subject to the kb_knowledge field allowlist. |
| create_recordA | Create a new record on any ServiceNow table. Use this to deploy solutions: Business Rules (sys_script), Script Includes (sys_script_include), Scripted REST APIs (sys_ws_definition + sys_ws_operation), UI Pages, or any other table. No table restrictions — the PDI is the sandbox. |
| update_recordA | Update an existing record on any ServiceNow table by sys_id. Only the fields you provide will be changed — other fields are untouched. |
| delete_recordA | Delete a record from any ServiceNow table by sys_id. Returns confirmation. Use for cleanup after testing. |
| execute_scriptA | Run server-side JavaScript on the ServiceNow PDI. The script runs inside a Scripted REST API resource — use response.setBody({...}) to return data. GlideRecord, GlideDateTime, gs, sn_ws.RESTMessageV2, and all server-side APIs are available. Auto-deploys and auto-cleans up. |
| count_tableA | Count records in a ServiceNow table matching a sysparm_query filter. Returns ONLY an integer count — no record data. Use this for 'how many' questions: 'how many P1 incidents this week?', 'what % of assets are Dell?'. Subject to the same table + query filter allowlist as query_table. |
| health_checkA | Check the MCP server's liveness and control state. Returns status (ok|degraded), uptime, ServiceNow reachability, audit log writability, policy load time, phase, and version. Useful for demos and monitoring. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool has a clearly distinct purpose: querying records, fetching by sys_id, counting records, creating/updating/deleting, searching the KB, running scripts, and checking health. Even query_table and get_record are distinct (filtered search vs. direct ID lookup), so there is no ambiguity.
Most tools follow a consistent verb_noun snake_case pattern (query_table, create_record, delete_record, etc.). The only minor deviation is 'health_check' which uses a noun-verb compound rather than verb_noun, but it remains readable and consistent in casing.
With 9 tools, the server is well-scoped for its purpose. It covers CRUD, querying, counting, KB search, script execution, and health monitoring without unnecessary bloat or missing essentials.
The tool set provides full record lifecycle coverage (create, read, update, delete), flexible searching with query_table and count_table, knowledge base access, arbitrary script execution, and server health checks. There are no obvious gaps for typical ServiceNow automation workflows.