sp_task_control_get_currentReturns the currently running task so you can check active work in Super Productivity. Use it to identify which task is in progress and manage task control status.
Returns the currently running task (task-control).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it merely restates the title without adding behavioral context. It does not reveal what happens when no task is currently running (null vs. empty vs. error), nor what the 'task-control' qualifier implies about side effects. The read-only nature is implied but the edge-case behavior is entirely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence, front-loaded with the operative verb and free of filler. The only slightly cryptic element is the '(task-control)' parenthetical, which is unexplained but harmless. The length is appropriate for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read with no output schema and no annotations, the description is nearly sufficient but leaves the no-current-task case unstated, which an agent needs to handle the response correctly. It also doesn't relate 'current task' to sibling state concepts like sp_focus_get or the setter sp_task_control_set_current. A single clause covering the empty case would have made it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially 100% covered and there is nothing for the description to explain. The zero-parameter baseline of 4 applies directly, and no deduction is warranted for missing parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and a specific resource ('the currently running task'), which distinguishes it from siblings like sp_task_get (fetch a task by ID) and sp_tasks_list (enumerate tasks). The '(task-control)' parenthetical loosely signals the control family, aligning it with sp_task_control_set_current and sp_task_control_stop. However, it closely paraphrases the title and never explicitly differentiates itself from those control siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to call this tool versus alternatives such as sp_task_get, sp_tasks_list, sp_focus_get, or sp_task_control_stop. With 14 siblings present, an agent is left to infer the usage context purely from the name. There are no exclusions, prerequisites, or scenario-based routing clues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.