Loading ToolBench
MCP server for Windows Task Scheduler management, providing tools to list, create, edit, run, stop, enable, disable, delete, and analyze scheduled tasks
Task Scheduler Studio provides 12 well-named tools with clear, actionable descriptions (avg 180 chars). All tools have explicit JSON Schema input definitions with typed parameters and descriptions. Strengths: verb-noun naming (list_*, get_*, create_*, run_*, stop_*, enable_*, disable_*, delete_*), comprehensive parameter documentation, and structured schemas for complex inputs like create_task. Weaknesses: no output schemas documented (critical gap for LLM planning), no error handling guidance, no pagination support for list_tasks/list_folders despite potentially large result sets, and no confirmation/dry-run pattern for destructive operations (delete_task). Security: no secrets exposed as parameters (good). Composition: tools are single-responsibility and chainable (e.g., list_tasks → get_task → analyze_task). Missing: per-tool error recovery hints, result limits, and output field documentation.
Parse a scheduled task and return a grounded, evidence-based assessment of it: a risk level (Low/Medium/High), a list of findings that each cite the exact command, trigger, principal or setting they are based on, and the observed facts. Useful for deciding whether a task looks legitimate or suspicious. The verdict is derived only from the task's stored definition, not file signatures or runtime behaviour.
Create or update a scheduled task. Provide EITHER 'xml' (raw Task Scheduler XML, full fidelity) OR structured 'triggers' + 'actions'. If a task with the same folder+name exists it is updated. The task is written to the shared Windows store.
Permanently delete a task.
Disable a task (keeps the definition, prevents it from running).
Enable a task.
Return the portable Task Scheduler XML for a task (the interchange format the built-in app uses for Import/Export).
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., task_id from create_task, fields from list_tasks). This forces agents to guess response structure.
list_tasks and list_folders lack pagination (limit, offset, next_cursor) and result-count documentation. Large folder trees or task lists will blow context windows without pagination support.
Destructive operations (delete_task, run_task, stop_task) lack confirmation/dry-run pattern. Agents can irreversibly delete tasks without a safety gate or preview step.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
List tasks that are currently running, with their current action and engine PID.
Get the full definition of one task: principal, settings, triggers, actions, run state, last/next run, and the raw Task Scheduler XML.
List the Task Scheduler folder tree (paths and task counts), rooted at '\'.
List scheduled tasks in a folder with their state, next/last run time, last result, and human-readable trigger and action summaries.
Start a task immediately (on demand).
Stop all running instances of a task.
No error handling guidance. Tools do not document what errors are retryable, user-fixable, or fatal. LLMs receive raw errors with no recovery path (e.g., 'Task not found' should suggest list_tasks).
create_task accepts 'password' as a parameter. Credentials must never be tool parameters, use server-side secret injection via environment variables or vault. Passwords in params leak into logs and traces.