servicenow-api

Batch request

servicenow_batch_request

Batch multiple ServiceNow REST API requests into a single call to reduce round trips and return combined responses.

Instructions

Sends multiple REST API requests in a single call.

:param batch_request_id: ID that identifies the batch of requests. :type batch_request_id: str :param rest_requests: List of request objects to include in the batch request. :type rest_requests: list

:return: Response containing the batch results. :rtype: Response

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rest_requests": "<rest_requests>"
    },
    "name": "servicenow_batch_request"
  }
}

Input Schema

Name	Required	Description	Default
`rest_requests`	Yes
`batch_request_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.4.0Oct 19, 2026

TDQS

C2.6/5.0

Behavior2/5

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

Annotations declare readOnlyHint=false and idempotentHint=false, signaling a mutating, non-idempotent operation, but the description never says that batched POST/PUT/PATCH calls can modify or destroy data, nor how partial failures or per-request errors are surfaced. With a false readOnlyHint, the silence on side effects is a real gap.

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

Conciseness3/5

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

The opening sentence is well front-loaded and efficient, but the Sphinx-style :param/:type/:return block mostly duplicates the schema and the return type note ('Response') adds nothing since no output schema exists to compare against. Roughly half the text is boilerplate.

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 tool that fans out arbitrary HTTP calls (including writes) in one shot, the definition omits batch size limits, execution order, failure semantics, and any note that individual request bodies must be base64 encoded. No output schema exists, so the terse ':return: Response' leaves return structure entirely unexplained.

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?

Top-level schema description coverage is 0%, so the description carries the burden, yet it only restates types ('str', 'list') for batch_request_id and rest_requests. It adds no meaning about the required per-request fields (id, method, url) or the base64-encoded body convention that the nested schema documents.

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?

The first sentence states a specific verb and resource ('Sends multiple REST API requests in a single call'), and the word 'multiple' implicitly contrasts with the single-request sibling servicenow_api_request. It stops short of naming that sibling explicitly, so an agent must infer the routing distinction.

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?

There is no guidance on when to batch versus calling servicenow_api_request repeatedly, no mention of batch size limits, ordering guarantees, or whether requests execute transactionally. The reader must guess at the intended usage envelope.

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

Deploy Server