servicenow-mcp-ai

Describe ServiceNow table

servicenow_describe_table

Read-onlyIdempotent

Describe a ServiceNow table by listing its columns from sys_dictionary—including name, label, type, mandatory, reference, default, and flags—with optional choice lists and overrides.

Instructions

List a table's columns from sys_dictionary (name, label, type, mandatory, reference, default, flags). details:true adds choice lists and dictionary overrides.

Input Schema

Name	Required	Description
`table`	Yes	Table, e.g. 'incident'.
`details`	No	Add choice lists and dictionary overrides (two extra reads).
`instance`	No	Profile (default active)

Output Schema

Name	Required	Description	Default
`count`	Yes
`table`	Yes
`columns`	Yes
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv3.0.0Oct 21, 2026

removedInput schema / $schema

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

addedInput schema / properties / details

Added value: +{
+  "description": "Add choice lists and dictionary overrides (two extra reads).",
+  "type": "boolean"
+}

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
```

changedInput schema / properties / table / description

Previous value: -"Table name to describe, e.g. 'incident'."New value: +"Table, e.g. 'incident'."

addedInput schema / properties / table / pattern
```
Added value: +"^[A-Za-z0-9_]{1,80}$"
```

changedOutput schema / (root)

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

First observedv2.0.1Sep 5, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds real value by naming the backing source (sys_dictionary) and disclosing that details:true costs two extra reads, which is a concrete cost signal. It stops short of noting any row/column caps or truncation behavior.

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 tight sentences with zero filler; the core capability is front-loaded and the optional-cost note follows immediately. Every clause earns its place.

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?

With an output schema present and a fully documented input schema plus read-only annotations, the definition is nearly self-sufficient; it doesn't need to explain return values. The missing piece is workflow placement relative to servicenow_query_table and servicenow_list_tables, which is the one thing an agent must still guess.

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%, including the '(two extra reads)' cost note, so the description's details:true sentence largely restates the schema. The `instance` profile parameter is not addressed at all in the description. Baseline 3 is appropriate given the schema carries the parameter burden.

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 ("List a table's columns from sys_dictionary") and enumerates the fields returned (name, label, type, mandatory, reference, default, flags), so an agent knows exactly what it gets. It is implicitly distinguishable from servicenow_list_tables, but the description never names that sibling, so the differentiation requires inference.

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 contains no when-to-use guidance: it never says to call this before servicenow_query_table, nor when to prefer servicenow_explain_policy or servicenow_list_tables. The only conditional content ("details:true adds...") is about a parameter, not about tool selection.

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