Skip to main content
Glama
tedorigawa001

ServiceNow-MCP

by tedorigawa001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_job_run_history

Read-onlyIdempotent

Read scheduler history aggregates by job classification and time window (sys_scheduler_job_history), not individual job success/failure logs. job_sys_id and status filters are unsupported.

Instructions

Read scheduler history aggregates by job classification and time window (sys_scheduler_job_history), not individual job success/failure logs. job_sys_id and status filters are unsupported.

Input Schema

NameRequiredDescriptionDefault
limitNoMax aggregate rows (default: 25), not execution count
job_classificationNoExact scheduler classification (not a sysauto sys_id). Omit to list all classifications.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.15.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / job_classification
      Added value: +{
+  "description": "Exact scheduler classification (not a sysauto sys_id). Omit to list all classifications.",
+  "minLength": 1,
+  "type": "string"
+}
    • removedInput schema / properties / job_sys_id
      Removed value: -{
-  "description": "Filter by specific job sys_id",
-  "type": "string"
-}
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default: 25)"New value: +"Max aggregate rows (default: 25), not execution count"
    • addedInput schema / properties / limit / maximum
      Added value: +1000
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
    • removedInput schema / properties / status
      Removed value: -{
-  "description": "Filter by run status: success, error, canceled",
-  "type": "string"
-}
  2. First observedv1.0.2

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds real behavioral context — that results are aggregates rather than per-execution records and that some filters are rejected — but it never says what is aggregated (counts, durations, failures?) nor what a returned row looks like, and there is no output schema to fill that gap.

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?

Two compact sentences, front-loaded with the operation and immediately followed by the key disambiguation. Little waste, though the unsupported 'time window' claim is a sentence fragment of misinformation that a tighter phrasing would have avoided.

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?

For a read-only aggregate tool with no output schema, the description should clarify what the aggregates contain; it only says 'aggregates' and leaves return shape unknown. The unbacked time-window claim further weakens completeness, though the core read/aggregate distinction and unsupported-filter warnings are present.

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 both parameters are well documented, so the baseline is 3. The description contributes by warning that job_sys_id and status cannot be passed, but it also claims a 'time window' dimension that has no corresponding parameter, which can lead an agent to search for a nonexistent argument.

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 ('Read scheduler history aggregates'), names the backing table (sys_scheduler_job_history), and explicitly contrasts with individual job success/failure logs, so it is distinguishable from list_scheduled_jobs and log-oriented siblings. However, it advertises grouping 'by job classification and time window' when the schema exposes no time-window parameter, leaving the stated scope partly unsupported.

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

Usage Guidelines4/5

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

Gives explicit when-not guidance ('not individual job success/failure logs') and pre-empts two common but unsupported filters (job_sys_id, status), which is genuinely useful routing information. It stops short of naming the sibling tool an agent should use instead for per-job execution detail.

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