N-central MCP Server

list_job_statuses

Read-only

Retrieve asynchronous N-central job statuses for an organization, with optional filters for job ID, device, status, or timestamp, and paginated compact results.

Instructions

List asynchronous N-central job statuses with local filtering, bounded pagination, and a compact default projection.

Input Schema

TableJSON Schema

Name	Required	Description
`jobId`	No	Optional exact job identifier filter.
`since`	No	Keep jobs scheduled or completed at or after this ISO 8601 timestamp.
`status`	No	Optional case-insensitive exact status filter.
`deviceId`	No	Optional exact device identifier filter.
`pageSize`	No	Local result page size from 1-100; defaults to 25.
`orgUnitId`	Yes	Organization unit identifier.
`pageNumber`	No	Local result page number; defaults to 1.
`detailLevel`	No	compact (default) removes the unbounded _extra object; full retains complete rows.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`meta`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv3.0.0Sep 18, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / detailLevel

Added value: +{
+  "description": "compact (default) removes the unbounded _extra object; full retains complete rows.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / deviceId

Added value: +{
+  "anyOf": [
+    {
+      "description": "Optional exact device identifier filter.",
+      "type": "string"
+    },
+    {
+      "description": "Optional exact device identifier filter.",
+      "type": "number"
+    }
+  ],
+  "description": "Optional exact device identifier filter."
+}

removedInput schema / properties / format

Removed value: -{
-  "description": "Output format: \"csv\" or \"json\". Default varies by tool — list_* default to json; report_* default to csv.",
-  "enum": [
-    "csv",
-    "json"
-  ],
-  "type": "string"
-}

addedInput schema / properties / jobId

Added value: +{
+  "anyOf": [
+    {
+      "description": "Optional exact job identifier filter.",
+      "type": "string"
+    },
+    {
+      "description": "Optional exact job identifier filter.",
+      "type": "number"
+    }
+  ],
+  "description": "Optional exact job identifier filter."
+}

addedInput schema / properties / orgUnitId / anyOf

Added value: +[
+  {
+    "description": "Organization unit identifier.",
+    "type": "string"
+  },
+  {
+    "description": "Organization unit identifier.",
+    "type": "number"
+  }
+]

changedInput schema / properties / orgUnitId / description

Previous value: -"The organization unit ID"New value: +"Organization unit identifier."

removedInput schema / properties / orgUnitId / type
```
Removed value: -"number"
```

addedInput schema / properties / pageNumber

Added value: +{
+  "description": "Local result page number; defaults to 1.",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / pageSize

Added value: +{
+  "description": "Local result page size from 1-100; defaults to 25.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / since

Added value: +{
+  "description": "Keep jobs scheduled or completed at or after this ISO 8601 timestamp.",
+  "type": "string"
+}

addedInput schema / properties / status

Added value: +{
+  "description": "Optional case-insensitive exact status filter.",
+  "maxLength": 100,
+  "minLength": 1,
+  "pattern": ".*\\S.*",
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "data": {},
+    "meta": {
+      "additionalProperties": false,
+      "properties": {
+        "errors": {
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "code": {
+                "type": "string"
+              },
+              "component": {
+                "type": "string"
+              },
+              "message": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "component",
+              "code",
+              "message"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "operations": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "page": {},
+        "partial": {
+          "type": "boolean"
+        },
+        "truncated": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "operations",
+        "partial",
+        "errors",
+        "page",
+        "truncated"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "data",
+    "meta"
+  ],
+  "type": "object"
+}

First observedv2.1.0Jun 21, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already signal a safe read operation via readOnlyHint and destructiveHint. The description adds meaningful behavioral detail beyond annotations: 'local filtering' indicates filters are applied after retrieval, 'bounded pagination' tells the agent results are limited and pageable, and 'compact default projection' explains the default output shape without requiring the agent to inspect the schema first.

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?

A single, information-dense sentence with zero filler. The core action and resource are front-loaded, followed by three distinct behavioral characteristics that summarize the tool's personality. Every phrase 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?

For an 8-parameter read-only listing tool with a complete output schema and fully described parameters, the description covers the essential behavioral context: what is listed, how results are filtered, how pagination works, and what the default projection is. It could name the required orgUnitId explicitly, but the schema already requires it, so the agent can proceed confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that filters are local and pagination is bounded, which helps an agent reason about how parameters like since, status, deviceId, pageSize, and pageNumber interact. It also reinforces that the default detailLevel is compact, aligning with the schema's default 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?

The description opens with a specific verb and resource: 'List asynchronous N-central job statuses.' It also distinguishes this tool from siblings by adding behavioral qualifiers—'local filtering, bounded pagination, and a compact default projection'—so an agent can differentiate it from list_device_scheduled_tasks and other list/search tools.

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?

The description implies the tool is for retrieving job statuses, and the resource scope is clear, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. The sibling list does not include a directly competing 'list jobs' tool, so the lack of explicit exclusions is less harmful, but guidance is still only implied.

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

Deploy Server