Skip to main content
Glama
Xerrion

servicenow-platform-mcp

by Xerrion

query

Read records, aggregates, or a single record from any ServiceNow table. Use encoded queries, field selection, pagination, and aggregation with optional grouping and label resolution.

Instructions

Read records, aggregates, or a single record from any ServiceNow table.

Args: table: ServiceNow table name (e.g. 'incident'). sys_id: When set, fetch a single record by sys_id (other filter args ignored except fields and display_values). encoded_query: ServiceNow encoded query string (e.g. 'state=1^priority=2'). Empty = no filter. fields: Comma-separated field list. Empty returns all (subject to masking). limit: Max rows (1-max_row_limit). Default 20. offset: Pagination offset. order_by: Field name; prefix with '-' for descending (e.g. '-sys_created_on'). display_values: True returns display_value form for reference and choice fields. aggregate: Comma-separated aggregations: 'count', 'avg:', 'sum:', 'min:', 'max:'. When set, returns aggregate result instead of rows. group_by: Field to group aggregate results by (aggregate mode only). resolve_labels: Comma-separated 'field=label' pairs (e.g. 'state=open,priority=high'). Each label is resolved via ChoiceRegistry to its underlying value, then ANDed into encoded_query as 'field=value'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableYes
sys_idNo
encoded_queryNo
fieldsNo
limitNo
offsetNo
order_byNo
display_valuesNo
aggregateNo
group_byNo
resolve_labelsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly explains key behaviors: if sys_id is set, other filters are ignored; fields empty returns all with masking; aggregate mode returns aggregate results; resolve_labels modifies encoded_query. It does not cover error handling or rate limits, but the known behaviors are well-documented.

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 structured with a clear one-line summary followed by an 'Args' section that bullet-points each parameter. While lengthy (about 15 lines), every sentence provides necessary detail. It is front-loaded efficiently, but minor redundancy in examples could be trimmed slightly.

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

Completeness5/5

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

Given the tool's complexity (11 parameters, output schema exists), the description covers all key behaviors: parameter interactions (sys_id mode, aggregate mode), defaults, constraints (max rows), and special features (resolve_labels). Since output schema exists, return values need not be explained. The description is complete for an AI agent to use correctly.

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

Parameters5/5

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

The schema description coverage is 0%, so the description must explain all parameters. It does so thoroughly: each parameter is described with its effect, special conditions (e.g., sys_id ignoring other filters), and examples (e.g., order_by with '-' prefix, aggregate functions). This adds substantial meaning beyond the schema's basic types and defaults.

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 'Read records, aggregates, or a single record from any ServiceNow table', identifying the specific verb and resource. It distinguishes itself from siblings like 'record_read' and 'record_write' by emphasizing the ability to perform aggregated queries and use encoded queries, making its purpose distinct.

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 guidance on when to use this tool versus siblings such as 'record_read' or 'investigate'. It implies usage through parameter details (e.g., when to use sys_id vs encoded_query) but lacks a clear 'when-to-use' or 'when-not-to-use' statement, leaving the agent to infer context.

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

Install Server

Other Tools

Latest Blog Posts

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/Xerrion/servicenow-platform-mcp'

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