N-central MCP Server

get_scheduled_task_context

Read-only

Retrieve a scheduled task's definition and optionally its execution status to monitor automation from N-central. Get aggregate or per-device results for a given task ID.

Instructions

Load a scheduled-task definition and optionally its aggregate or per-device execution status.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "taskId": "<taskId>"
    },
    "name": "get_scheduled_task_context"
  }
}

Input Schema

Name	Required	Description
`taskId`	Yes	Scheduled-task identifier.
`includeStatus`	No	Include execution status.
`detailedStatus`	No	Use per-device status; valid only for system/customer task IDs.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Addedv3.0.0Sep 18, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by clarifying the distinction between aggregate and per-device execution status, which is not fully captured in the schema. This enhances behavioral understanding beyond the structured fields.

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?

The description is a single, front-loaded sentence that efficiently conveys the main purpose and the optional status feature without any waste. It is concise and well-structured.

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 simple 3-parameter read-only tool, the description covers the essential behavior. It does not mention prerequisites like task existence, but these are implicit and the schema and annotations fill in the remaining gaps. The description is adequate for an agent to call it correctly.

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 meaning by explicitly naming 'aggregate or per-device' status, which maps to includeStatus and detailedStatus respectively, and clarifies the relationship between these booleans beyond the schema's individual descriptions.

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 states a specific verb ('Load') and resource ('scheduled-task definition') and clearly distinguishes the tool's scope from siblings like list_device_scheduled_tasks, which lists tasks rather than loading a specific one. It also mentions the optional status retrieval, making the purpose unambiguous.

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 usage when a specific scheduled task's definition or status is needed, but it does not explicitly contrast with sibling tools or state when not to use it. No alternatives or exclusions are mentioned, leaving the agent to infer from the name and context.

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

Deploy Server