Skip to main content
Glama
tedorigawa001

ServiceNow-MCP

by tedorigawa001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_active_events

Read-onlyIdempotent

List Event Management events (em_event), newest first. Defaults to unprocessed events (state Ready or Error); pass state "all" for every event. For the alerts operators act on, use list_alerts.

Instructions

List Event Management events (em_event), newest first. Defaults to unprocessed events (state Ready or Error); pass state "all" for every event. For the alerts operators act on, use list_alerts.

Input Schema

NameRequiredDescriptionDefault
limitNoMax events (default: 10)
queryNoAdditional encoded query (e.g., "severity=1"). A state clause here overrides the state default.
stateNounprocessed (default: Ready + Error) | Ready | Processed | Error | Ignored | all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.15.1
    • changedInput schema / properties / query / description
      Previous value: -"Filter events (e.g., \"severity=1\")"New value: +"Additional encoded query (e.g., \"severity=1\"). A state clause here overrides the state default."
    • addedInput schema / properties / state
      Added value: +{
+  "description": "unprocessed (default: Ready + Error) | Ready | Processed | Error | Ignored | all",
+  "type": "string"
+}
  2. First observedv1.0.2

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint) and scope (openWorldHint), so the description's job is to disclose filtering and ordering semantics; it does that by naming the hidden default state filter and the sort order. It doesn't mention pagination or result volume for large event tables, which is the main remaining gap.

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 sentences, both front-loaded with the resource and the default filter. No filler, no restatement of the tool name as a purpose.

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 three-optional-parameter read-only list tool with full schema coverage and no output schema, the definition covers scope, defaults, ordering, and the sibling alternative. Only return-shape and pagination guidance are absent, which is minor here.

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 each parameter already documents its default and enum-like values, so the description mostly restates what the schema provides. The note that a state clause in 'query' overrides the state default is useful but is already present in the query parameter's schema description.

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?

States a specific verb and resource ('List Event Management events (em_event)') plus ordering ('newest first'), and names the sibling list_alerts as the adjacent alternative. An agent can distinguish it from list_event_log, list_event_registry, and list_alerts without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the default behavior (unprocessed = Ready + Error), the escape hatch (state "all"), and an explicit routing rule: 'For the alerts operators act on, use list_alerts.' When-to-use and when-to-use-something-else are both stated.

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