Itential MCP Server

Official

by itential

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Describe Job

describe_job

Read-onlyIdempotent

Retrieve detailed information about a specific Itential Platform job by object ID, including workflow execution status, tasks, metrics, and results.

Instructions

Get detailed information about a specific job from Itential Platform.

Jobs are created automatically when workflows are executed and contain comprehensive information about the workflow execution including status, tasks, metrics, and results.

Input Schema

Name	Required	Description	Default
`object_id`	Yes	The ID used to retrieve the job

Output Schema

Name	Required	Description
`_id`	Yes	Unique job identifier
`name`	Yes	Job name
`type`	Yes	Job type (automation, resource:action, resource:compliance)
`tasks`	Yes	Complete set of tasks executed
`status`	Yes	Current job status (error, complete, running, canceled, incomplete, paused)
`metrics`	Yes	Job execution metrics including start time, end time, and account
`updated`	Yes	Last update timestamp
`variables`	No	Job variable outputs produced during workflow execution
`description`	No	Job description
`pending_manual_tasks`	No	Manual tasks currently waiting on a human. Tri-state: None means unknown (the lookup failed with an error other than not-found, e.g. 403, 500 or a timeout; the rest of this response is still valid). An empty list means none are pending, including when the job is not running (the lookup only runs while status is running). A non-empty list holds the pending tasks; use describe_manual_task with a work_item_id for detail. Detection covers manual tasks attached directly to this job's own ID; tasks inside nested or child runs are not guaranteed to be listed.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.14.1Oct 18, 2026

changedOutput schema / description

Previous value: -"Response model for job detail endpoints.\n\nThis model represents detailed information about a specific job\nfrom the operations manager API, including comprehensive execution\ndetails, status, tasks, metrics, and output variables.\n\nAttributes:\n    object_id: Unique job identifier.\n    name: Job name.\n    description: Job description.\n    job_type: Job type (automation, resource:action, resource:compliance).\n    tasks: Complete set of tasks executed.\n    status: Current job status (error, complete, running, canceled, incomplete, paused).\n    metrics: Job execution metrics including start time, end time, and account.\n    updated: Last update timestamp.\n    variables: Job variable outputs produced during workflow execution."New value: +"Response model for job detail endpoints.\n\nThis model represents detailed information about a specific job\nfrom the operations manager API, including comprehensive execution\ndetails, status, tasks, metrics, and output variables.\n\nAttributes:\n    object_id: Unique job identifier.\n    name: Job name.\n    description: Job description.\n    job_type: Job type (automation, resource:action, resource:compliance).\n    tasks: Complete set of tasks executed.\n    status: Current job status (error, complete, running, canceled, incomplete, paused).\n    metrics: Job execution metrics including start time, end time, and account.\n    updated: Last update timestamp.\n    variables: Job variable outputs produced during workflow execution.\n    pending_manual_tasks: Manual tasks waiting on a human (None if unknown)."

addedOutput schema / properties / pending_manual_tasks

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "description": "Summary of a manual task that is waiting on a human.\n\nAttributes:\n    work_item_id: Work item identifier; pass to describe_manual_task.\n    title: The task's human-readable title, verbatim from the platform.\n    view_type: The task view type (for example \"ViewData\").\n    waiting_age_seconds: Seconds the task has been waiting, or None if\n        the creation time is unavailable.\n    completion_supported: Whether MCP can complete this view type.",
+        "properties": {
+          "completion_supported": {
+            "default": false,
+            "description": "True if this view type is one that MCP can complete (ViewData,\nViewHTML, InteractiveHTML); False for form views and unknown\nview types",
+            "title": "Completion Supported",
+            "type": "boolean"
+          },
+          "title": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null,
+            "description": "Human-readable title of the manual task, as set by the\nworkflow author",
+            "title": "Title"
+          },
+          "view_type": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null,
+            "description": "Manual task view type, for example ViewData, ViewHTML,\nInteractiveHTML or RenderJsonSchema",
+            "title": "View Type"
+          },
+          "waiting_age_seconds": {
+            "anyOf": [
+              {
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ],
+            "default": null,
+            "description": "Seconds the task has been waiting on a human (now minus the\nwork item's creation time); None if unavailable",
+            "title": "Waiting Age Seconds"
+          },
+          "work_item_id": {
+            "description": "Work item identifier; pass to describe_manual_task for detail",
+            "title": "Work Item Id",
+            "type": "string"
+          }
+        },
+        "required": [
+          "work_item_id"
+        ],
+        "title": "ManualTaskSummary",
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Manual tasks currently waiting on a human. Tri-state: None\nmeans unknown (the lookup failed with an error other than\nnot-found, e.g. 403, 500 or a timeout; the rest of this\nresponse is still valid). An empty list means none are\npending, including when the job is not running (the lookup\nonly runs while status is running). A non-empty list holds the\npending tasks; use describe_manual_task with a work_item_id for\ndetail. Detection covers manual tasks attached directly to\nthis job's own ID; tasks inside nested or child runs are not\nguaranteed to be listed.",
+  "title": "Pending Manual Tasks"
+}

First observedv0.1.0Aug 4, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: jobs are auto-created by workflow executions and carry status, tasks, metrics, and results, which tells the agent what kind of record it is reading.

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 short sentences, front-loaded with the action and resource. The second sentence is context rather than filler, though it is mildly explanatory for an agent that only needs to call the tool.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. For a single-parameter read-only tool the description is nearly complete; only the relationship to get_jobs and the job-ID source is left unstated.

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 object_id parameter is fully documented in the schema. The description only implies it is a job identifier; it adds no format, sourcing, or lookup guidance beyond the schema, so baseline 3 applies.

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 (get detailed information) and resource (a specific job from Itential Platform), and the singular framing distinguishes it from the sibling get_jobs list tool. It stops short of naming the alternative explicitly, but an agent can tell it apart.

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

Usage Guidelines3/5

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

Usage is only implied: retrieve details for one job when you have its ID, versus get_jobs for enumeration. The description explains what a job is but never states when to reach for this tool over get_jobs, get_job_metrics, or get_task_metrics.

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

Deploy Server