Skip to main content
Glama
jschuller

ServiceNow MCP Server

by jschuller
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get Record

get_record
Read-onlyIdempotent

Retrieve a single ServiceNow table record by sys_id and optionally select fields or display values, so you can inspect exact record details without listing the full table.

Instructions

Get a single record from a ServiceNow table by sys_id.

If this is refused (401) while list_records works, call list_records with query="sys_id=<sys_id>" and limit=1 instead.

Input Schema

NameRequiredDescriptionDefault
fieldsNoComma-separated list of fields to return
sys_idYesThe sys_id of the record
table_nameYesThe ServiceNow table name
display_valueNo'false' (default) returns stored values; 'true' returns labels in place of sys_ids and choice values; 'all' returns {display_value, value} per field, which keeps the sys_id beside the name. query= still filters on stored values, not labels. With 'true' or 'all', dates come back in this identity's time zone and formatfalse

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.2
    • addedInput schema / properties / display_value
      Added value: +{
+  "default": "false",
+  "description": "'false' (default) returns stored values; 'true' returns labels in place of sys_ids and choice values; 'all' returns {display_value, value} per field, which keeps the sys_id beside the name. query= still filters on stored values, not labels. With 'true' or 'all', dates come back in this identity's time zone and format",
+  "enum": [
+    "false",
+    "true",
+    "all"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changedv0.7.0
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  3. First observedv0.5.1

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the safety profile is settled. The description adds value beyond that by disclosing a specific failure mode (401 per-record refusal) and a concrete remediation, which the agent cannot infer from annotations or schema.

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 short sentences, purpose front-loaded, fallback placed after the primary statement. Nothing is redundant and nothing could be removed without losing the 401 workaround.

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 idempotent read with a fully documented 4-parameter schema, this is nearly complete; the only gap is no note on what happens when the sys_id does not exist (empty vs error), which the agent must discover at call time.

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

Parameters3/5

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

Schema description coverage is 100% and the display_value description is unusually rich (label vs stored value, 'all' shape, time-zone effects). The description adds no parameter-level meaning on top of that, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ("Get a single record from a ServiceNow table by sys_id") and names the lookup key, which cleanly separates it from list_records, aggregate_records, and get_ci. It does not explicitly contrast with sibling getters (get_ci, get_update_set), so differentiation is implied rather than stated.

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?

Explicitly gives the alternative (list_records with query="sys_id=<sys_id>" and limit=1) and the exact condition that selects it (a 401 refusal while list_records works). That is a real routing rule, though it covers only the failure path and says nothing about when to prefer this over list_records in normal operation.

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

Deploy Server

Other Tools