What can you do with this server?

The servicenow-mcp server provides read-only access to ServiceNow data and metadata, with optional write operations gated by update-set and docs-precheck controls. You can query any table using encoded queries, with pagination, field selection, and display values. Fetch single records by sys_id, run aggregate statistics (count, avg, sum, min, max) with grouping, and retrieve table schemas including inherited fields, optionally filtered to mandatory ones. Get the current update set. Search and fetch ServiceNow documentation, and access curated best practices. When SN_MCP_ALLOW_WRITES=true, write tools are enabled: create, update, and delete records, with safeguards: writes are refused while the update set is "Default" (unless disabled), deletes require a confirm flag, and a precheck can require signed tokens for medium/high-risk or delete operations. You can also switch the current update set. The server integrates with MCP clients, supports multiple instances, and operates statelessly.

How do I use servicenow-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@servicenow-mcp show me the latest 10 incident records" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

servicenow-mcp

by JoseanMeonez

Overview Schema Source Related Servers Score Discussions

TypeScript

Remote

servicenow-mcp

Standalone MCP server for ServiceNow. Exposes the Table, Aggregate, and schema APIs as tools, with an in-process update-set write gate: write tools are only registered when explicitly enabled, and every write is refused while your current update set is "Default".

Works with Claude Code, Claude Desktop, Antigravity CLI, opencode, GitHub Copilot CLI, GitHub Copilot in VS Code, and any other MCP client (stdio transport).

Requirements

Node.js >= 20.6
A ServiceNow instance reachable with Basic Auth (username/password)

Related MCP server: mfa-servicenow-mcp

Install

git clone https://github.com/JoseanMeonez/servicenow-mcp.git
cd servicenow-mcp
npm install
npm run build

Configuration

All configuration is via environment variables (a .env file in the repo root is also loaded when present — see .env.example):

Variable	Default	Description
`SN_BASE_URL`	— (required)	Instance URL, e.g. `https://dev12345.service-now.com`
`SN_USERNAME`	— (required)	Basic Auth username
`SN_PASSWORD`	— (required)	Basic Auth password
`SN_MCP_ALLOW_WRITES`	`false`	Register write tools (create/update/delete/set update set)
`SN_MCP_REQUIRE_UPDATE_SET`	`true`	Refuse writes while the current update set is "Default"
`SN_MCP_DEFAULT_LIMIT`	`50`	Default query page size
`SN_MCP_MAX_LIMIT`	`500`	Hard ceiling on any requested limit
`SN_MCP_REQUEST_TIMEOUT_MS`	`30000`	Per-request timeout
`SN_MCP_RETRY_MAX_ATTEMPTS`	`3`	Attempts for 429/5xx responses (honors `Retry-After`)
`SN_MCP_REQUIRE_DOCS_PRECHECK`	`false`	Strict mode: require a valid `servicenow_docs_precheck` token before medium/high-risk or delete writes
`SN_MCP_DOCS_RELEASE`	`australia`	ServiceNow release branch used by the docs tools (see branches)

Changing SN_MCP_ALLOW_WRITES requires restarting the MCP server process — tools are registered at startup, not per call.

Instance user setup (required per instance)

Recent ServiceNow releases do not accept Basic Auth on the REST API by default. For every instance you connect, the user in SN_USERNAME must be set up as follows:

Roles: grant snc_basic_auth_api_access (mandatory for Basic Auth REST access) plus the roles needed for the tables you will touch. On a personal dev instance admin is fine; at work prefer least-privilege roles over admin.
Integration user flag: on the sys_user record, set internal_integration_user = true.
Recommended: use a dedicated integration user (e.g. api.tester), never a personal or the admin account, so API access can be rotated or revoked independently.

Symptom when this is missing: every request fails with 401 "User is not authenticated" even though the credentials are correct. The server's error output includes this hint automatically on 401 responses.

Register with Claude Code

claude mcp add servicenow-mcp -- node C:/Users/you/path/to/servicenow-mcp/dist/index.js

or copy .mcp.json.example into your project's .mcp.json and adjust path + env.

Register with Claude Desktop

Claude Desktop uses a different config file than Claude Code: %APPDATA%\Claude\claude_desktop_config.json (Windows). Add under mcpServers, using the full path to node.exe (Desktop may not inherit your shell PATH):

{
  "mcpServers": {
    "servicenow-dev": {
      "command": "C:\\Program Files\\nodejs\\node.exe",
      "args": [
        "--env-file=C:/path/to/servicenow-mcp/instances/dev.env",
        "C:/path/to/servicenow-mcp/dist/index.js"
      ]
    }
  }
}

Then fully quit Claude Desktop (system tray → Quit, not just closing the window) and reopen it — the config is only read at startup.

Register with Antigravity CLI

Antigravity CLI's MCP config lives at ~/.gemini/antigravity-cli/mcp_config.json (it shares the Gemini CLI config layout, not ~/.antigravitycli). Add under mcpServers:

{
  "mcpServers": {
    "servicenow-dev": {
      "command": "node",
      "args": [
        "--env-file=C:/path/to/servicenow-mcp/instances/dev.env",
        "C:/path/to/servicenow-mcp/dist/index.js"
      ]
    }
  }
}

Start a new Antigravity CLI session afterward — config is only read at startup, an existing session won't pick it up.

Prompt to hand to Antigravity CLI (or any agent with file-edit access) to do this for you:

Add a new entry under mcpServers in ~/.gemini/antigravity-cli/mcp_config.json named servicenow-<instance>, pointing to node with args --env-file=<absolute path to instances/<instance>.env> and <absolute path to dist/index.js>. Keep existing entries intact. Then tell me to start a new session for it to take effect.

Register with opencode

Add under mcp in ~/.config/opencode/opencode.json (or your project's opencode.json):

{
  "mcp": {
    "servicenow-dev": {
      "enabled": true,
      "type": "local",
      "command": [
        "node",
        "--env-file=C:/path/to/servicenow-mcp/instances/dev.env",
        "C:/path/to/servicenow-mcp/dist/index.js"
      ]
    }
  }
}

Note the command and its args live together in a single array (unlike Claude's command/args split).

Prompt to hand to opencode:

Add a new entry under mcp in ~/.config/opencode/opencode.json named servicenow-<instance>, with "type": "local", "enabled": true, and command as an array: ["node", "--env-file=<absolute path to instances/<instance>.env>", "<absolute path to dist/index.js>"]. Keep existing entries intact.

Register with GitHub Copilot CLI

Copilot CLI's config lives at ~/.copilot/mcp-config.json (override via COPILOT_HOME). Add under mcpServers, with an explicit "type": "stdio":

{
  "mcpServers": {
    "servicenow-dev": {
      "type": "stdio",
      "command": "node",
      "args": [
        "--env-file=C:/path/to/servicenow-mcp/instances/dev.env",
        "C:/path/to/servicenow-mcp/dist/index.js"
      ],
      "env": {}
    }
  }
}

Or from the terminal: copilot mcp add (interactive), then verify with /mcp show inside a Copilot CLI session.

Prompt to hand to Copilot CLI:

Add a new entry under mcpServers in ~/.copilot/mcp-config.json named servicenow-<instance>, with "type": "stdio", command: "node", and args ["--env-file=<absolute path to instances/<instance>.env>", "<absolute path to dist/index.js>"]. Keep existing entries intact. Then run /mcp show to confirm it loaded.

Register with GitHub Copilot in VS Code

VS Code Copilot uses .vscode/mcp.json in the workspace (commit it to share with your team), with the root key servers — not mcpServers like the other clients:

{
  "servers": {
    "servicenow-dev": {
      "type": "stdio",
      "command": "node",
      "args": [
        "--env-file=C:/path/to/servicenow-mcp/instances/dev.env",
        "C:/path/to/servicenow-mcp/dist/index.js"
      ]
    }
  }
}

Saving the file with valid JSON restarts the Copilot agent and reloads servers automatically — no full VS Code restart needed.

Prompt to hand to Copilot Chat in VS Code:

Create or update .vscode/mcp.json in this workspace: add an entry under servers (not mcpServers) named servicenow-<instance>, with "type": "stdio", command: "node", and args ["--env-file=<absolute path to instances/<instance>.env>", "<absolute path to dist/index.js>"]. Keep existing entries intact.

Multiple instances

The recommended pattern is one server process per instance, each declared as its own entry in .mcp.json and pointed at a per-instance profile file via Node's native --env-file flag (before the script path):

{
  "mcpServers": {
    "servicenow-dev": {
      "command": "node",
      "args": ["--env-file=/path/to/instances/dev.env", "/path/to/dist/index.js"]
    },
    "servicenow-prod": {
      "command": "node",
      "args": ["--env-file=/path/to/instances/prod.env", "/path/to/dist/index.js"]
    }
  }
}

Node fails fast if the profile file is missing, and real environment variables take precedence over file values.

Why per-process instead of one multi-tenant server:

Zero shared state. The server holds no caches and no sessions (see below); separate processes make cross-instance leakage structurally impossible, not just avoided.
Per-instance write policy. A prod profile with SN_MCP_ALLOW_WRITES=false (or simply omitting it) never even registers write tools — the client cannot call what does not exist.
Clear tool naming. Tools surface as mcp__servicenow-dev__* vs mcp__servicenow-prod__*, so it is always explicit which instance a call targets.
Independent rate limits. ServiceNow enforces inbound REST rate limits per user per instance, so parallel processes against different instances never interact.

To add a new instance in one step, use the helper — it writes the profile file with correct password quoting and prints the registration command:

npm run add-instance -- work https://mycompany.service-now.com api.integration 'the-password'

Keep profile files (e.g. instances/*.env) out of git — the .gitignore already excludes .env and instances/.

Statelessness guarantees

No record, schema, or token caching — every tool call hits the instance fresh.
Basic Auth header is computed per request; response cookies are ignored (no cookie jar), so no ServiceNow session is retained between calls.
The write gate re-reads your current update set from the instance on every write.

If a metadata cache (e.g. table schemas) ever becomes worth it, it should be explicit, on-disk, and per-instance — never implicit in-process memory.

Tools

Read tools (always registered):

Tool	Description
`servicenow_query_records`	Query a table with an encoded query; paginated (`hasMore`/`nextOffset`)
`servicenow_get_record`	Fetch one record by sys_id
`servicenow_get_aggregate`	Stats API: count/avg/sum/min/max, optionally grouped
`servicenow_get_table_schema`	Field list from `sys_dictionary`, including inherited fields
`servicenow_get_current_update_set`	Show your current update set
`servicenow_docs_search`	Search the `llms.txt` topic index of `ServiceNow/ServiceNowDocs`
`servicenow_docs_get`	Fetch the full markdown of a specific doc path
`servicenow_best_practices`	Curated, in-repo guidance (update-sets, record-ops, contracts, coding standards); no network I/O
`servicenow_docs_precheck`	Risk-analyze an intended write; issues a signed token for medium/high-risk or delete operations

Write tools (only when SN_MCP_ALLOW_WRITES=true):

Tool	Description
`servicenow_create_record`	Create a record (gated)
`servicenow_update_record`	Update a record (gated)
`servicenow_delete_record`	Delete a record (gated, requires `confirm: true`)
`servicenow_set_current_update_set`	Switch your current update set (how you move off "Default")

The write gate

Every write first resolves your current update set on the instance (sys_user_preference → sys_update_set). If it is "Default", the write is refused with a clear error telling you to switch sets first. This keeps AI-driven changes tracked in a real update set, the same discipline you'd apply by hand. Disable with SN_MCP_REQUIRE_UPDATE_SET=false (e.g. for non-development instances).

Docs-guided writes and the precheck gate

All four write tools also accept an optional precheckToken parameter, obtained by calling servicenow_docs_precheck with the target table and operation (create/update/ delete) beforehand. The precheck report includes a risk level (low/medium/high), matching curated best practices, and — for medium/high-risk operations, or any delete — a signed token valid for approximately 10 minutes.

Advisory mode (default, SN_MCP_REQUIRE_DOCS_PRECHECK=false): the token is accepted but never required; writes behave exactly as before this feature existed.
Strict mode (SN_MCP_REQUIRE_DOCS_PRECHECK=true): a write whose server-recomputed risk is medium/high, or whose operation is delete, is refused unless a valid, unexpired precheckToken bound to that exact table and operation is supplied. Low-risk creates/ updates still proceed without a token.

The token is a compact HMAC-SHA256-signed value, verified without any server-side session or cache (fully self-contained), but signed with a secret generated fresh per process — tokens from one server process are not valid against another (e.g. after a restart). This is intentional: the token is a short-lived confirmation that guidance was consulted, not a durable credential.

Development

npm run dev          # run from source (tsx)
npm test             # unit + in-memory integration tests
npm run test:live    # live smoke tests (needs SN_* env or .env; read-only)
npm run inspect      # MCP Inspector against dist/index.js
npm run ci           # lint + build + test

Known limitations

Basic Auth only (v1). If your instance enforces SSO/MFA for API access, requests fail with a "possible SSO/MFA redirect" error. An OAuth or session-based AuthStrategy is the planned phase 2 (src/client/auth.ts is the single seam to extend).
Schema from sys_dictionary. Portable to every instance (including PDIs), but virtual/ computed fields may be missing compared to /api/now/doc/table/schema.
PDI hibernation. Personal developer instances sleep after inactivity; wake yours in a browser before running live tests.

Available Tools

5 tools

servicenow_get_aggregateAggregate (stats)B

Read-only

Run the Aggregate/Stats API on a table: count, avg/sum/min/max, optionally grouped.

ParametersJSON Schema

Name	Required	Description
`count`	No
`query`	No	Encoded query filter
`table`	Yes
`groupBy`	No
`avgFields`	No
`maxFields`	No
`minFields`	No
`sumFields`	No

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the description carries a lower burden. The description adds that the tool supports grouping and multiple aggregation functions, but does not disclose potential limitations such as maximum output size, behavior on empty tables, or permission requirements. It adequately conveys the read-only nature but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no fluff, achieving high conciseness. However, it could be slightly more structured (e.g., listing parameters) without adding much length. It is not overly verbose, but the brevity sacrifices some clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters (1 required), no output schema, and low documentation coverage, the description is insufficient. It does not explain the return format (e.g., JSON object with aggregate values), any limits on results, or typical usage patterns. The tool's complexity demands more context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 13%, meaning most parameters lack schema descriptions. The description mentions 'count, avg/sum/min/max, optionally grouped', which maps to fields like avgFields, sumFields, groupBy, etc., but does not explain the `query` parameter or `table`. This provides some context beyond the bare schema but is insufficient overall.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs the Aggregate/Stats API on a table and lists specific operations (count, avg/sum/min/max) with optional grouping. It distinguishes itself from siblings like servicenow_get_record and servicenow_query_records, which retrieve individual records or lists rather than summaries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool over its siblings. It does not mention alternatives, prerequisites, or scenarios where aggregate stats are appropriate versus fetching records. For example, it doesn't state 'Use this when you need summary statistics rather than individual records.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

servicenow_get_current_update_setGet current update setA

Read-only

Show the authenticated user's current update set on the instance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already signals safe read-only behavior. The description adds no additional behavioral detail beyond what the annotation provides, which is adequate for a simple read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence that front-loads the purpose. No extraneous words. Every word is earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description sufficiently explains the tool's function. It covers what the tool does and for whom, which is complete enough for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is 100%. The description correctly omits parameter details. Baseline for zero parameters is 4, and no additional info is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Show' and resource 'current update set' for the authenticated user. It distinguishes from siblings like servicenow_get_record which operate on records, not update sets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when/when-not guidance, but the tool name and sibling tools make context obvious. The description implies it's for viewing the current update set, which is a specific use case separate from querying records or aggregates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

servicenow_get_recordGet recordA

Read-only

Fetch a single record by table and sys_id.

ParametersJSON Schema

Name	Required	Description
`sysId`	Yes	sys_id of the record (32 chars)
`table`	Yes	Table name, e.g. "incident"
`fields`	No

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations include readOnlyHint=true, and description states 'Fetch', which is read-only. No additional behavioral details beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Front-loaded with action and key constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with annotations and three parameters, the description is mostly complete. Lacks guidance on fields usage and error scenarios, but sufficient for basic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description only mentions table and sys_id, ignoring the optional 'fields' parameter. Schema provides descriptions for the two required parameters but not for fields. The description adds no extra meaning beyond the schema for the covered parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Fetch a single record by table and sys_id', which is specific verb+resource. It distinguishes from sibling tools like servicenow_query_records (query) and servicenow_get_aggregate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use vs alternatives. Implied by purpose, but lacks when-not-to-use and alternative tool names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

servicenow_get_table_schemaGet table schemaB

Read-only

List fields of a table from sys_dictionary, including inherited fields from parent tables.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes
`mandatoryOnly`	No

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already signals no side effects. The description adds that inherited fields are included, which is useful behavioral context beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, front-loading the core purpose. It could include brief parameter hints without losing conciseness, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple schema-listing tool with no output schema and no param descriptions, the description omits important details about return format and parameter behavior, leaving the agent under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description fails to explain what the 'table' and 'mandatoryOnly' parameters mean. The agent gets no help understanding parameter semantics from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists fields of a table, including inherited fields, which is a specific verb+resource. It is distinct from sibling tools (get_aggregate, get_record, etc.) that deal with data or update sets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention prerequisites like table existence. However, the distinct purpose from sibling tools allows reasonable inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

servicenow_query_recordsQuery recordsA

Read-only

Query a ServiceNow table with an encoded query. Returns records plus pagination info (limit is capped at 500).

ParametersJSON Schema

Name	Required	Description
`limit`	No
`query`	No	Encoded query, e.g. "active=true^priority=1"
`table`	Yes	Table name, e.g. "incident"
`fields`	No	Fields to return (recommended)
`offset`	No
`displayValue`	No

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds valuable behavioral context: limit cap at 500 and return of pagination info. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct sentences. First sentence states the core purpose; second provides critical usage detail (limit cap). No redundant or extraneous content. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 6 parameters and no output schema, the description is minimal. It covers the query mechanism and a key constraint (limit 500), but omits details on pagination format, offset behavior, and return structure. Adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (3 of 6 parameters have descriptions). The description does not clarify the undocumented parameters (limit, offset, displayValue). It adds no parameter-level meaning beyond what the schema provides, and fails to compensate for the gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Query' and resource 'ServiceNow table', and specifies 'encoded query'. It distinguishes from sibling tools like servicenow_get_record (single record) and servicenow_get_aggregate. Includes additional detail about pagination info and limit cap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for querying tables with encoded queries, but does not explicitly state when to use versus alternatives such as servicenow_get_record or servicenow_get_aggregate. No exclusion or when-not guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jul 15, 2026
- First observedservicenow_get_aggregate
- First observedservicenow_get_current_update_set
- First observedservicenow_get_record
- First observedservicenow_get_table_schema
- First observedservicenow_query_records

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct ServiceNow operation: aggregation, user update set, single record retrieval, table schema, and query. There is no ambiguity between them.

Naming Consistency4/5

All tools use the 'servicenow_' prefix and follow a verb_noun pattern (get_aggregate, get_record, etc.). However, 'query_records' deviates from the 'get_' prefix, causing minor inconsistency.

Tool Count5/5

With 5 tools, the server is well-scoped for a basic ServiceNow integration. Each tool serves a clear purpose without unnecessary bloat or missing essentials.

Completeness2/5

The tool set covers read operations (query, get, schema, stats) and user update set retrieval but lacks any write operations (create, update, delete). This is a significant gap for a full CRUD surface.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Security
111

Related MCP Servers

servicenow-mcp
Customer Support Knowledge & Memory App Automation
mady22070
A
license
Not graded
quality
D
maintenance
MCP server to interact with ServiceNow instances, enabling ITSM, CMDB, workflow, and knowledge search operations.
Updated 5 months ago (2026-03-25 06:23 UTC)
MIT
mfa-servicenow-mcp
Cloud Platforms Developer Tools
jshsakura
F
license
C
quality
A
maintenance
An MCP server for ServiceNow that supports multi-factor authentication via real browser (Playwright) and provides tools for reading, writing, and managing ServiceNow artifacts with safety guards.
Updated 4 days ago (2026-09-04 08:25 UTC)
32
2
-
snow-mcp
smitraonline
A
license
A
quality
C
maintenance
An MCP server for interacting with a ServiceNow instance via its Table API, enabling CRUD operations on incident, request, and requested item tables, as well as generic operations on any table by name.
Updated 2 months ago (2026-07-08 17:40 UTC)
22
MIT
ServiceNow Script Manager
Developer Tools Cloud Platforms App Automation
Nahn2000
F
license
Not graded
quality
B
maintenance
MCP server providing CRUD tools for ServiceNow business rules, client scripts, and script includes.
Updated 2 months ago (2026-07-09 18:41 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JoseanMeonez/servicenow-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server