servicenow-mcp-ai

List connection profiles

servicenow_list_instances

Read-onlyIdempotent

Lists ServiceNow connection profiles with host, user, auth method, refresh-token state, read-only/write mode, and credential completeness—excluding secrets—to help select the correct instance.

Instructions

List the connection profiles: name, host, user, auth method (and OAuth grant), refresh-token state, read-only flag, write mode, credentials complete. Secrets are never included.

Input Schema

Name	Required	Description	Default
`instance`	No	Profile (default active)

Output Schema

Name	Required	Description	Default
`count`	Yes
`profiles`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv3.0.0Oct 21, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

changedInput schema / properties / instance / description

Previous value: -"Connection profile to use for this call (default: the active profile). See servicenow_list_instances."New value: +"Profile (default active)"

addedInput schema / properties / instance / maxLength
```
Added value: +128
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": {},
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "profiles": {
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "profiles"
+  ],
+  "type": "object"
+}

First observedv2.0.1Sep 5, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely useful context beyond them: the exact fields surfaced (auth method, OAuth grant, refresh-token state, write mode, credentials complete) and the security guarantee that secrets are never returned. It omits any note on ordering or volume when many profiles exist, which keeps it short of a 5.

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?

One front-loaded clause stating the action followed by a compact field list — no filler. The field enumeration partly duplicates what the output schema already conveys, so it is not maximally economical, but it remains tight.

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?

Safety profile is covered by annotations and return shape by the output schema, so the description only needs to situate the tool in the profile workflow. It fails to do that: nothing explains the relationship to use_instance/set_credentials or whether the optional instance param filters or targets a profile.

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 coverage is 100% and the single optional 'instance' param is documented there as 'Profile (default active)'. The description adds no extra meaning and in fact reads as listing all profiles, leaving mild ambiguity about whether the param narrows the result to one profile. Baseline 3 applies when the schema carries the load.

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 (List) and resource (connection profiles) and enumerates the fields returned, so the agent knows exactly what this yields versus the record/table tools. It does not, however, differentiate from the closest siblings like servicenow_use_instance or servicenow_set_credentials that also deal with profiles.

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 gives no when-to-use guidance: it doesn't say to call this before servicenow_use_instance to discover profile names, or that it is the inspection counterpart to servicenow_set_credentials. An agent must infer its role in the profile workflow purely from the name.

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