How do I use Subconductor?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Subconductor Initialize a checklist for deploying v2.1" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Subconductor

by PaulBenchea

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Subconductor

A persistent state machine and notification system for AI agents to manage complex, multi-step workflows via the Model Context Protocol (MCP).

Subconductor prevents "context drift" by maintaining a single source of truth for project progress across multiple independent checklists. It stores these in a structured .subconductor/checklists/ directory along with a global .subconductor/checklists.md index file. It keeps the user informed through a robust notification system that triggers during long-running tasks or checklist completion. This allows agents to "remember" their exact state, completed milestones, and remaining blockers across multiple sessions and parallel workflows.

Quick Start

Add Subconductor to your MCP-compatible host (e.g., Claude Desktop or Gemini) using npx:

"subconductor": {
  "command": "npx",
  "args": ["-y", "@psno/subconductor"]
}

Configuration Flags

You can customize the server behavior using the following flags:

--disable-batch (or -b): Disable batch operation tools (get_pending_tasks, mark_tasks_done, unmark_tasks, add_tasks, remove_tasks).
--disable-alerts (or -a): Disable all desktop notifications and the alert tool.

Related MCP server: Tycana

Tools Included

`init_checklist`

Initialize a new task checklist. This automatically creates a dedicated folder and registers the checklist in the central index.

Arguments:
- tasks (array): List of tasks to perform. Can be strings or objects with name and an optional note.
- goal (string): The high-level objective of the workflow.
- columns (string[], optional): Custom columns for the task table. Status, ID, and Name are always included.
Effect: Creates a nested .subconductor/checklists/<goal-slug>/checklist.md file and updates the active pointer in .subconductor/checklists.md.

`activate_checklist`

Switch the active context to a different, previously initialized checklist.

Arguments:
- checklistName (string): The numeric ID from the index, or a partial string match of the checklist's goal name.
Effect: Updates .subconductor/checklists.md to mark the targeted checklist as Active and all others as Idle.

`archive_checklist`

Moves a checklist to the archive directory to keep the active index clean.

Arguments:
- checklistIdentifier (string): The numeric ID from the index, or a partial string match of the checklist's goal name.
Effect: Moves the checklist folder to .subconductor/archive/checklists/ and updates its status to Archived in the index table.

`get_pending_task`

Retrieves the next uncompleted task from the active checklist.

Effect: Returns the first task with an ID prefix (e.g., (#1) Task Name). Returns DONE if all tasks are completed.

`get_pending_tasks`

Retrieves a batch of uncompleted tasks from the active checklist (requires batch tools enabled).

Arguments:
- count (number): The number of pending tasks to retrieve (default: 5).
Effect: Returns a list of tasks with ID prefixes or DONE.

`add_task`

Appends a new task to the active checklist dynamically.

Arguments:
- name (string): The name of the task.
- note (string, optional): An optional note.
Effect: Appends the task, automatically assigns a monotonic immutable ID, and updates the completion header.

`add_tasks`

Appends multiple new tasks to the active checklist dynamically.

Arguments:
- tasks (array): List of tasks to add (objects with name and optional note).
Effect: Appends all tasks sequentially, automatically assigning immutable IDs.

`remove_task`

Deletes a task from the active checklist.

Arguments:
- task (string): The task ID (e.g., "1") or the full task name.
Effect: Removes the task row and updates the completion header. Note: Existing task IDs remain immutable and are not shifted.

`remove_tasks`

Deletes multiple tasks from the active checklist in a single batch operation.

Arguments:
- tasks (array): List of task IDs or names to remove.
Effect: Removes all specified task rows safely.

`mark_task_done`

Updates a specific task's status to completed in the active checklist.

Arguments:
- task (string): The task ID (e.g., "1") or the full task name.
- note (string, optional): An additional note or status message.
Effect: Updates the status to Done and records the note in the Notes column. Automatically triggers a notification upon completion of the final task in the active checklist.

`mark_tasks_done`

Updates multiple tasks' statuses to completed in the active checklist.

Arguments:
- tasks (array): List of objects containing name (ID or task name) and an optional note.
Effect: Marks all specified tasks as Done and evaluates overall checklist completion.

`unmark_task`

Reverts a completed task back to pending status.

Arguments:
- task (string): The task ID (e.g., "1") or the full task name.
Effect: Reverts status to Pending (Idle), clears associated notes, and rolls back the completion goal header.

`unmark_tasks`

Reverts multiple completed tasks back to pending status in a single batch operation.

Arguments:
- tasks (array): List of task IDs or names to unmark.
Effect: Reverts all specified tasks to Pending (Idle).

`alert`

Sends a system-level notification with sound and icon support.

Arguments:
- title (string): The title of the notification.
- message (string): The message body.
- status ('info' | 'warn' | 'error'): The severity level (default: 'info').
Effect: Triggers a desktop notification with status-specific icons and sounds.

Resources

Changelog - Check out the latest changes.

License & Attribution

This project is licensed under the Apache License 2.0.

Important Attribution Requirement: In accordance with Section 4(d) of the Apache License, if you modify this software or build new features based on this codebase, you must retain the attribution to Paul Benchea as the original author. Please refer to the NOTICE file for specific details.

Built with the Model Context Protocol.

Available Tools

14 tools

activate_checklistA

Activate a previously initialized checklist by its goal name or a substring of it. The activated checklist will receive all subsequent task operations.

ParametersJSON Schema

Name	Required	Description	Default
`checklistName`	Yes	The goal name of the checklist to activate, or a distinctive part of it.

TDQS

A4/5.0

Behavior4/5

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

The description discloses the key behavioral trait that the activated checklist will receive all subsequent task operations. However, it does not specify whether only one checklist can be active at a time or if activation deactivates previous ones, leaving some state behavior ambiguous.

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 two sentences, front-loaded with the main action, and contains no fluff. Every sentence adds necessary context, making it highly concise and easy to parse.

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?

Given the simple single-parameter input and no output schema, the description covers the essential purpose and effect. It could be slightly more complete by noting the singleton nature of active checklists, but overall it is adequate.

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 description coverage is 100%, and the parameter description in the schema already explains the substring matching. The tool description adds no new semantic value beyond what the schema provides, meeting the baseline.

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 clearly states the verb 'activate' and the resource 'checklist', specifies identification by goal name or substring, and implies the role as setting active context for subsequent task operations, effectively distinguishing it from siblings like init_checklist and task operations.

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 use after initialization ('previously initialized checklist') but does not explicitly state when or when not to use, nor mention alternatives or exclusions. No guidance on prerequisites or ordering is provided.

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

add_taskB

Add a new task to the active checklist. The task is appended to the end of the list and automatically assigned a new ID.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	The name of the task to add
`note`	No	An optional note for the task

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, description carries full burden. It mentions append and ID assignment but omits other behavioral traits like side effects, limits, or what happens if no active checklist exists.

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?

Single sentence, front-loaded with purpose, no wasted words. Extremely concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 2 params and no output schema, description is adequate but missing contextual details (e.g., must have active checklist, return value). Completeness is average.

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% with parameter descriptions. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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?

Description clearly states verb 'Add a new task to the active checklist' and specifies key behaviors (appended to end, automatically assigned ID). It distinguishes from siblings like 'add_tasks' (plural) and 'init_checklist'.

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

Usage Guidelines2/5

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

No guidance on when to use this vs alternatives (e.g., 'add_tasks' for bulk). Does not mention prerequisites like requiring an active checklist. Lacks when-not-to-use or context.

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

add_tasksA

Add multiple new tasks to the active checklist. Tasks are appended to the end of the list and automatically assigned new IDs.

ParametersJSON Schema

Name	Required	Description	Default
`tasks`	Yes	List of tasks to add

TDQS

A3.9/5.0

Behavior3/5

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

Discloses tasks are appended and auto-assign IDs, which is useful. However, no annotations exist, so the description carries the burden but omits error handling or requirements (e.g., active checklist existence). Adequate but not comprehensive.

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?

Single sentence, front-loaded with purpose and key details, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but return values are not described. For a simple add tool, this is adequate; however, mentioning success indication would complete the picture.

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 coverage is 100% (tasks array). The description adds behavioral meaning: multiple tasks, appended, auto-ID assignment, which goes beyond the schema's generic 'List of tasks to add'.

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 clearly states the tool adds multiple tasks to the active checklist, distinguishes from siblings like add_task (singular) and remove_tasks, and specifies behavior (append, auto-assign IDs).

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?

No explicit when-to-use or alternatives mentioned, but the context implies bulk addition vs. single-task sibling add_task. More specific guidance would improve agent decision-making.

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

alertA

Trigger a desktop notification with a custom title, message, and severity level (info, warn, error). This is useful for providing immediate feedback on background task completion or issues.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	The title of the notification
`message`	Yes	The message body
`status`	No	The severity level	info

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description bears full burden. It discloses the effect (desktop notification) and the three parameters. Missing details on whether the notification is blocking, permission requirements, or return value, but for a simple notification, it is adequate.

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?

Two sentences, zero wasted words. First sentence states purpose and parameters, second sentence provides usage context. Perfectly concise.

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 a simple tool with 3 parameters, no output schema, and no annotations, the description covers the main points. Lacks mention of return value or asynchronous behavior, but overall reasonable.

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 coverage is 100%, baseline 3. The description adds value by explaining the fields and listing the severity enum options inline, going beyond the schema's 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 clearly states the verb 'trigger', the resource 'desktop notification', and specifies customizable fields (title, message, severity). It is distinct from sibling tools which are all checklist/task related.

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

Usage Guidelines4/5

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

Provides explicit context: 'useful for providing immediate feedback on background task completion or issues.' Does not specify when not to use or mention alternatives, but given sibling tools are unrelated, this is sufficient.

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

archive_checklistA

Archive a checklist by its goal name, a substring of it, or its numeric ID. The checklist will be moved to the archive directory and marked as Archived in the global index.

ParametersJSON Schema

Name	Required	Description	Default
`checklistIdentifier`	Yes	The goal name, a distinctive part of it, or the numeric ID of the checklist to archive.

TDQS

A4.2/5.0

Behavior4/5

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

Describes that checklist is moved to archive directory and marked Archived. No annotations, but description covers main behavioral effect without contradictions.

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?

Two sentences: first specifies action and identifier types, second explains consequence. No extraneous text, highly efficient.

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?

Adequately covers purpose and effect for a simple tool with one parameter and no output schema. Missing error handling details, but not essential for basic use.

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?

Single parameter documented in schema (100% coverage). Description repeats schema content without adding further nuance, meeting baseline.

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 clearly states the tool archives a checklist using goal name, substring, or numeric ID, and explains the outcome. Distinguishes from siblings like activate_checklist and init_checklist.

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

Usage Guidelines4/5

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

Implicitly guides when to use (to archive a checklist), but no explicit when-not-to-use or alternatives mentioned. Context suggests distinct purpose among siblings.

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

get_pending_taskA

Retrieve the next single pending task from the active checklist. Returns "DONE" if all tasks are finished. Tasks are returned with an ID (e.g., "(#1) Task Name") which can be used to reference them efficiently.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so the description carries full weight. It discloses the return value 'DONE' for completion and the ID format (e.g., '(#1) Task Name'), which is helpful for agent behavior.

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?

Two sentences, front-loaded with purpose, and no wasted words. Each sentence adds essential information.

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 a no-parameter tool with no output schema, the description provides sufficient behavior (return values, ID format). It does not explain 'active checklist' concept, but given simplicity, it is largely complete.

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?

The tool has zero parameters, and schema coverage is 100%. The description confirms no parameters needed and adds context about return values, meeting the baseline for 0-parameter tools.

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?

Description states 'Retrieve the next single pending task from the active checklist,' using a specific verb and resource, clearly distinguishing it from sibling 'get_pending_tasks' (plural) and other task management 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?

Usage is implied by the name and description, but no explicit guidance on when to choose this over the plural variant or other alternatives like `add_task` or `get_pending_tasks`.

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

get_pending_tasksA

Retrieve a batch of multiple pending tasks from the active checklist. Tasks are returned with an ID (e.g., "(#1) Task Name") which can be used to reference them efficiently. This is useful for getting an overview of upcoming work or for efficiently processing multiple simple tasks in a single turn.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	The number of pending tasks to retrieve

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that tasks are returned with an ID format and implies read-only retrieval. Could be more explicit about side effects, but adequate.

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?

Two concise sentences with no wasted words. First sentence states action, second adds useful detail about return format and use case. Front-loaded with core purpose.

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?

Given simple tool with one parameter and no output schema, description covers what it does, return format, and typical use. Doesn't mention prerequisites (e.g., active checklist exists) but is adequate for agent selection.

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% for the only parameter 'count'. Description does not add extra meaning beyond what the schema already provides. Baseline 3 is appropriate.

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?

Clearly states it retrieves multiple pending tasks from the active checklist, uses specific verb 'retrieve' and resource 'pending tasks', and distinguishes from sibling 'get_pending_task' by emphasizing batch operation.

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

Usage Guidelines4/5

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

Explains it's useful for overview or processing multiple tasks in one turn, but does not explicitly mention when not to use or alternatives (e.g., get_pending_task for single task). Implicit context is clear.

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

init_checklistA

Initialize a new task checklist for the current subconductor run. This tool creates a task table with Status, ID, Name, and optional custom columns. It also natively sets up goal tracking to monitor completion progress.

ParametersJSON Schema

Name	Required	Description
`tasks`	Yes	List of tasks to perform. Must be objects with "name" and optional "note".
`goal`	Yes	The overall goal of this subconductor run
`columns`	No	Optional list of custom columns for the task table. "Status", "ID", and "Name" are always included.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool creates a table and sets up goal tracking, but does not mention whether it overwrites an existing checklist, requires specific permissions, or what happens on repeated calls. Some behavior is described but important details are missing.

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 two sentences, front-loaded with the core purpose, and every sentence adds meaningful information. No unnecessary words or redundancy.

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?

The description covers the essential effects of the tool (creating a table, setting up goal tracking) and all three parameters are addressed. However, it does not specify the return value (e.g., whether a checklist ID is returned), which would be helpful for subsequent operations. Given the absence of an output schema, this is a minor gap.

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 coverage is 100% and already describes the parameters. The description adds value by explaining that the 'goal' parameter enables progress tracking and that custom columns are optional. This extra context enhances understanding beyond the schema alone.

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 clearly states the tool initializes a new task checklist for the current subconductor run, creating a task table with specific columns and goal tracking. This distinctly sets it apart from sibling tools like add_task or mark_task_done, which operate on existing checklists.

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

Usage Guidelines4/5

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

The description implies this tool is the first step before using other checklist tools, but it does not explicitly state when to use it or when not to, nor does it mention alternatives. The context of sibling names makes the usage clear, but a direct statement would improve guidance.

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

mark_task_doneA

Mark a specific task as completed in the active checklist. You can reference the task by its ID (e.g., "1" or "#1") for efficiency, or by its full name. You can optionally provide a note detailing the progress or result.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	The task ID (e.g., "1") or task name to mark as completed
`note`	No	An optional note to add or append to the task

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the core behavior (mark as completed, add optional note) and input formats. However, it omits effects like idempotency, error handling for non-existent tasks, or side effects on related checklists.

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 two sentences with no fluff. The first sentence states the purpose, and the second provides actionable usage details. Every sentence 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 a simple tool with two parameters and no output schema, the description covers core functionality and input formatting. It mentions 'active checklist,' linking to system state. Missing details on edge cases and sibling differentiation, but adequate overall.

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 coverage is 100% with clear descriptions. The description adds value with ID format examples ('1' or '#1') and efficiency guidance. This enriches the schema beyond literal 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 clearly states the action 'Mark a specific task as completed in the active checklist,' using a verb ('Mark as completed') and specifying the resource (task in active checklist). It distinguishes from sibling 'mark_tasks_done' by emphasizing a single task, and from 'unmark_task' by the action.

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 provides tips on referencing tasks (by ID or name) and optional notes, but does not explicitly compare to alternatives like 'mark_tasks_done' or 'unmark_task'. It implies use for single-task completion but lacks when-not-to-use guidance.

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

mark_tasks_doneA

Mark multiple tasks as completed in a single batch operation. You can reference tasks by their ID (e.g., "1" or "#1") or by their full name. This is efficient when several tasks are finished simultaneously. Like mark_task_done, you can optionally provide a note for each task to document progress or results.

ParametersJSON Schema

Name	Required	Description	Default
`tasks`	Yes	List of tasks to mark as completed

TDQS

A4.4/5.0

Behavior4/5

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

Discloses batch behavior, optional per-task notes, and reference formats. No annotations provided, so the description carries the full burden; it does a good job for a simple mutation tool.

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?

Two concise sentences with no redundancy. The key information is front-loaded, and every sentence serves a purpose.

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 a simple batch update tool without an output schema, the description covers purpose, usage, and parameters adequately. It could mention error handling (e.g., missing tasks), but overall sufficient.

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?

The input schema has 100% description coverage. The description adds value by explaining how to reference tasks (ID like '1' or '#1') and that notes are optional, enriching the schema's basic definitions.

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 clearly states it marks multiple tasks as completed in a batch operation, with specific reference formats (ID or name). It differentiates from the singular sibling mark_task_done, making the tool's 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 Guidelines4/5

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

Explicitly says it's efficient when several tasks are finished simultaneously, and mentions the singular alternative mark_task_done. Lacks explicit when-not-to-use scenarios, but the guidance is adequate.

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

remove_taskA

Remove a task from the active checklist. Warning: Removing a task will automatically re-index the IDs of all subsequent tasks in the checklist.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	The task ID (e.g., "1") or task name to remove

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries full burden and discloses the important side effect of re-indexing subsequent task IDs, though it could mention other potential impacts.

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?

Two concise sentences with the purpose first, followed by a critical warning, no unnecessary words.

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 a simple tool with no output schema, the description covers the essential purpose, parameter, and a key behavioral effect, though it could clarify return behavior.

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?

The schema already describes the parameter well (ID or name). The description adds the context 'from the active checklist' but doesn't significantly extend beyond the schema.

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 uses a specific verb ('Remove') and resource ('task from active checklist'), clearly distinguishing it from siblings like 'add_task' and 'remove_tasks'.

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 includes a warning about re-indexing but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'remove_tasks' for bulk removal) or when not to use it.

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

remove_tasksA

Remove multiple tasks from the active checklist. Safe for batch deletion, as remaining tasks are dynamically re-indexed only after all specified removals are processed.

ParametersJSON Schema

Name	Required	Description	Default
`tasks`	Yes	List of tasks to remove

TDQS

A4/5.0

Behavior4/5

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

Discloses safety and dynamic re-indexing behavior, which is critical for a deletion tool and not present in annotations (none provided). Adds value beyond basic operation.

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?

Two efficient sentences, front-loaded with purpose, no wasted words.

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?

Covers core behavior and safety, but lacks details on error handling, return values, or behavior with empty lists. Without output schema, agent may need more guidance.

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%, so description adds no additional meaning to the 'tasks' parameter beyond what the schema already provides. Baseline score is appropriate.

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?

Clearly states verb 'Remove' and resource 'multiple tasks' from 'active checklist'. Distinguishes from sibling 'remove_task' by specifying batch operation.

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?

Implies batch deletion use case but does not explicitly advise when to use versus 'remove_task' or other sibling tools. No when-not conditions.

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

unmark_taskA

Revert a completed task back to pending status in the active checklist. You can reference the task by its ID (e.g., "1" or "#1") or by its full name. Any completion notes will be removed.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	The task ID (e.g., "1") or task name to unmark

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description reveals an important side effect: completion notes will be removed. It clearly states the tool reverts a completed task, implying mutation. It does not cover permissions or error cases, but given the tool's simplicity, this is sufficient.

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 concise (two sentences) with the primary purpose in the first sentence. No redundant or unnecessary information is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter mutation tool with no output schema, the description covers the core function, parameter usage, side effect, and scope (active checklist). It is complete for its complexity level.

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?

The schema already describes the 'task' parameter as an ID or name. The description repeats this information with an additional format hint ('#1'), adding minimal value. Since schema coverage is 100%, the description does not significantly enhance parameter understanding.

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 clearly states the action (revert), the resource (completed task), and the result (back to pending status) with the scope 'active checklist'. It implicitly distinguishes from siblings like mark_task_done and unmark_tasks by focusing on singular unmarking and referencing completed status.

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 explains what the tool does but does not explicitly provide guidance on when to use this tool versus alternatives (e.g., unmark_tasks for batch or mark_task_done for the reverse). No prerequisites or exclusions are mentioned, leaving usage partially ambiguous.

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

unmark_tasksA

Revert multiple completed tasks back to pending status in a single batch operation. You can reference tasks by their ID (e.g., "1" or "#1") or by their full name.

ParametersJSON Schema

Name	Required	Description	Default
`tasks`	Yes	List of tasks to unmark

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the operation changes status from completed to pending in a batch, which is adequate for a simple mutation. No mention of error handling or idempotency.

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?

Two concise sentences with no wasted words, front-loaded with the main action and key details.

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?

Given a single-parameter tool with no output schema, the description covers the core functionality and parameter format adequately. Could mention error conditions or prerequisites (tasks must be completed).

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 coverage is 100% and description adds value by providing examples (e.g., '1' or '#1') and clarifying 'full name' beyond schema's 'task name'.

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 clearly states the tool reverts multiple completed tasks to pending status in a single batch operation, specifying how to reference tasks. It distinguishes from sibling 'unmark_task' which is singular.

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

Usage Guidelines4/5

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

The description implies when to use (batch revert) and hints at alternatives (unmark_task for singular) but does not explicitly state when not to use or compare to other siblings like 'mark_tasks_done'.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

14 tool updatesv1.2.0Jun 14, 2026
- First observedactivate_checklist
- First observedadd_task
- First observedadd_tasks
- First observedalert
- First observedarchive_checklist
- First observedget_pending_task
- First observedget_pending_tasks
- First observedinit_checklist
- First observedmark_task_done
- First observedmark_tasks_done
- First observedremove_task
- First observedremove_tasks
- First observedunmark_task
- First observedunmark_tasks

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-06-15 00:02 across 14 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: operations on checklists (init, activate, archive) and tasks (add, get, mark, remove, unmark) are well-separated, including singular/plural variants for batch operations. The alert tool is unrelated but not overlapping.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (e.g., add_task, mark_task_done). The only deviation is 'alert', which lacks a noun, and 'init' instead of 'initialize', but these are minor and do not cause confusion.

Tool Count5/5

With 14 tools, the server covers all essential operations for checklist management without unnecessary bloat. The count fits well within the typical 3-15 range for a focused domain.

Completeness4/5

The toolkit covers the full lifecycle of checklists and tasks (create, read, update, delete). Minor gaps exist, such as no tool to list all checklists or update task content, but core workflows are supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Work Context ProtocolOAuth
io.workcontextprotocol
Persistent work tracking for AI agents: tasks, status and history that follow you across machines
Project Management Knowledge & Memory
1
Penfield Memory AOAuth
io.github.penfieldlabs
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Knowledge & Memory RAG Systems Vector Databases
1726
nucleus B
io.github.eidetic-works
Sovereign Agent OS — Persistent Memory, Governance & Compliance for AI Agents.
Autonomous Agents Knowledge & Memory Security
2824
handoff-mcp-server A
io.github.josephibra
Durable agent-to-agent handoffs and shared scratchpad for multi-agent workflows.
Agent Orchestration Autonomous Agents
2

Related MCP Servers

MCP Notify Server
Autonomous Agents App Automation
Cactusinhand
A
license
B
quality
F
maintenance
A Model Context Protocol service that sends desktop notifications and alert sounds when AI agent tasks are completed, integrating with various LLM clients like Claude Desktop and Cursor.
Updated a year ago (2025-08-18 12:43 UTC)
1
54
MIT
Tycana
tycana
A
license
Not graded
quality
D
maintenance
AI-native productivity backend that gives your AI assistant persistent memory, pattern awareness, and computed intelligence about your work. 14 MCP tools for task management, daily planning, weekly review, and personal context.
Updated 6 months ago (2026-03-06 22:51 UTC)
MIT
Nexus-MCP
Autonomous Agents Developer Tools App Automation
jsagudelodev
A
license
Not graded
quality
C
maintenance
A comprehensive Model Context Protocol toolkit that transforms AI assistants into autonomous agents capable of executing real-world tasks across filesystems, web requests, Git workflows, databases, system commands, and AI integrations.
Updated 5 months ago (2026-04-25 14:13 UTC)
MIT
long-novel-agent-kit
Knowledge & Memory Autonomous Agents Command Line
mushroomfk
A
license
C
quality
C
maintenance
Provides local desktop agents with durable project memory and safety gates for writing long novels, enabling continuity management, chapter drafting, and state-aware handoffs.
Updated 2 months ago (2026-07-07 05:23 UTC)
31
MIT