Skip to main content
Glama
deenesjakoruzh
coderexpert123

Task Orchestration

by coderexpert123
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

Task Orchestrator

A Model Context Protocol (MCP) server for task orchestration and management. This tool helps break down goals into manageable tasks and track their progress.

How to use

Ideally, the LLM should be able to understand when this MCP tool should be used. But as a sample prompt, something like this can possibly work

"Create a new development goal for me. The goal is to 'Implement user authentication' and it's for the 'my-web-app' repository."

LEMME KNOW of any issues you face by creating a new issue in the 'Discussions' tab at the top.

Related MCP server: Claudia

Features

  • Create and manage goals

  • Break down goals into hierarchical tasks

  • Track task completion status

  • Support for subtasks and dependency management between parent task and subtasks

  • Persistent storage using LokiDB

Roadmap

  • Complex task/goal inter-dependency orchestration

  • Goal deletion

  • Completion dispositions

  • UI for visualization of progress

API Reference

Task ID Naming Convention

Task IDs use a dot-notation (e.g., "1", "1.1", "1.1.1") where each segment represents a level in the hierarchy.

  • For each new goal, top-level task IDs start with "1" and increment sequentially (e.g., "1", "2", "3").

  • Subtasks have IDs formed by appending a new segment to their parent's ID (e.g., "1.1" is a subtask of "1").

  • The combination of goalId and taskId is guaranteed to be unique.

Tools

The server provides the following tools (based on build/index.js):

  1. create_goal

    • Create a new goal

    • Parameters:

      {
  description: string;  // The goal description
  repoName: string;     // The repository name associated with this goal
}

    • Sample Input:

      {
  "description": "Implement user authentication",
  "repoName": "example/auth-service"
}

    • Returns: { goalId: number }

  2. add_tasks

    • Add multiple tasks to a goal. Tasks can be provided in a hierarchical structure. For tasks that are children of existing tasks, use the parentId field. The operation is transactional: either all tasks in the batch succeed, or the entire operation fails.

    • Parameters:

      {
  goalId: number; // ID of the goal to add tasks to (number)
  tasks: Array<{
    title: string; // Title of the task (string)
    description: string; // Detailed description of the task (string)
    parentId?: string | null; // Optional parent task ID for tasks that are children of *existing* tasks. Do not use for new subtasks defined hierarchically within this batch.
    subtasks?: Array<any>; // An array of nested subtask objects to be created under this task.
  }>;
}

    • Sample Input:

      {
  "goalId": 1,
  "tasks": [
    {
      "title": "Design database schema",
      "description": "Define tables for users, roles, and permissions",
      "subtasks": [
        {
          "title": "Create ERD",
          "description": "Draw entity-relationship diagram"
        }
      ]
    },
    {
      "title": "Implement user registration",
      "description": "Create API endpoint for new user signup",
      "parentId": "1"
    }
  ]
}

    • Returns: HierarchicalTaskResponse[]. HierarchicalTaskResponse objects are simplified and do not include createdAt, updatedAt, or parentId.

  3. remove_tasks

    • Soft-delete multiple tasks from a goal. Tasks are marked as deleted but remain in the system. By default, a parent task with subtasks cannot be soft-deleted without explicitly deleting its children. Soft-deleted tasks are excluded by default from get_tasks results unless includeDeletedTasks is set to true.

    • Parameters:

      {
  goalId: number; // ID of the goal to remove tasks from
  taskIds: string[]; // IDs of the tasks to remove (array of strings). Task IDs use dot-notation (e.g., "1", "1.1").
  deleteChildren?: boolean; // Whether to delete child tasks along with the parent (boolean). Defaults to false. If false, attempting to delete a parent task with existing subtasks will throw an error.
}

    • Sample Input (without deleting children):

      {
  "goalId": 1,
  "taskIds": ["2", "3"]
}

    • Sample Input (with deleting children):

      {
  "goalId": 1,
  "taskIds": ["1"],
  "deleteChildren": true
}

    • Returns: { removedTasks: TaskResponse[], completedParents: TaskResponse[] }. TaskResponse objects are simplified and do not include createdAt, updatedAt, or parentId.

  4. get_tasks

    • Get tasks for a goal. Task IDs use a dot-notation (e.g., "1", "1.1", "1.1.1"). When includeSubtasks is specified, responses will return hierarchical task objects. Otherwise, simplified task objects without createdAt, updatedAt, or parentId will be returned.

    • Parameters:

      {
  goalId: number; // ID of the goal to get tasks for (number)
  taskIds?: string[]; // Optional: IDs of tasks to fetch (array of strings). If null or empty, all tasks for the goal will be fetched.
  includeSubtasks?: "none" | "first-level" | "recursive"; // Level of subtasks to include: "none" (only top-level tasks), "first-level" (top-level tasks and their direct children), or "recursive" (all nested subtasks). Defaults to "none".
  includeDeletedTasks?: boolean; // Whether to include soft-deleted tasks in the results (boolean). Defaults to false.
}

    • Sample Input:

      {
  "goalId": 1,
  "includeSubtasks": "recursive",
  "includeDeletedTasks": true
}

    • Returns: TaskResponse[]. TaskResponse objects are simplified and do not include createdAt, updatedAt, or parentId.

  5. complete_task_status

    • Mark tasks as complete. By default, a parent task cannot be marked complete if it has incomplete child tasks.

    • Parameters:

      {
  goalId: number; // ID of the goal containing the tasks
  taskIds: string[]; // IDs of the tasks to update (array of strings). Task IDs use dot-notation (e.g., "1", "1.1").
  completeChildren?: boolean; // Whether to complete all child tasks recursively (boolean). Defaults to false. If false, a task can only be completed if all its subtasks are already complete.
}

    • Sample Input (without completing children):

      {
  "goalId": 1,
  "taskIds": ["1", "2"]
}

    • Sample Input (with completing children):

      {
  "goalId": 1,
  "taskIds": ["1"],
  "completeChildren": true
}

    • Returns: TaskResponse[]. TaskResponse objects are simplified and do not include createdAt, updatedAt, or parentId.

Usage Examples

Creating a Goal and Tasks

// Create a new goal. Its top-level tasks will start with ID "1".
const goal = await callTool('create_goal', {
  description: 'Implement user authentication',
  repoName: 'user/repo'
});

// Add a top-level task
const task1 = await callTool('add_tasks', {
  goalId: goal.goalId,
  tasks: [
    {
      title: 'Set up authentication middleware',
      description: 'Implement JWT-based authentication'
    }
  ]
});
// task1.addedTasks[0].id will be "1"

// Add a subtask to the previously created task "1"
const task2 = await callTool('add_tasks', {
  goalId: goal.goalId,
  tasks: [
    {
      title: 'Create login endpoint',
      description: 'Implement POST /auth/login',
      parentId: "1"  // ParentId must refer to an *already existing* task ID
    }
  ]
});
// task2.addedTasks[0].id will be "1.1"

Managing Task Status

// Mark a parent task as complete, which will also complete its children
await callTool('complete_task_status', {
  goalId: 1,
  taskIds: ["1"],
  completeChildren: true
});

// Get all tasks including subtasks recursively
const allTasks = await callTool('get_tasks', {
  goalId: 1,
  includeSubtasks: "recursive"
});

Removing Tasks

// Attempt to remove a parent task without deleting children (will fail if it has subtasks)
try {
  await callTool('remove_tasks', {
    goalId: 1,
    taskIds: ["1"]
  });
} catch (error) {
  console.error(error.message); // Expected to throw an error if subtasks exist
}

// Remove a parent task and its children
await callTool('remove_tasks', {
  goalId: 1,
  taskIds: ["1"],
  deleteChildren: true
});

Development

Prerequisites

  • Node.js 18+

  • pnpm

Setup

  1. Install dependencies:

    pnpm install

  2. Build the project:

    pnpm build

  3. Run tests:

    pnpm test

Project Structure

  • src/ - Source code

    • index.ts - Main server implementation

    • storage.ts - Data persistence layer

    • types.ts - TypeScript type definitions

    • prompts.ts - AI prompt templates

    • __tests__/ - Test files

License

MIT

Available Tools

5 tools
add_tasksA

Add multiple tasks to a goal. Tasks can be provided in a hierarchical structure. For tasks that are children of existing tasks, use the parentId field. The operation is transactional: either all tasks in the batch succeed, or the entire operation fails.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalIdYesID of the goal to add tasks to (number)
tasksYesAn array of task objects to be added. Each task can define nested subtasks.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the transactional nature (all-or-nothing success/failure) and the hierarchical structure handling (including parentId usage for existing tasks). It does not cover aspects like authentication needs, rate limits, or error handling, but provides substantial operational context beyond basic purpose.

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 appropriately sized and front-loaded, with three sentences that each earn their place: the first states the core purpose, the second explains hierarchical and parentId usage, and the third discloses transactional behavior. There is no wasted text, and it efficiently conveys 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?

Given the complexity of a batch write operation with hierarchical data and no annotations or output schema, the description is largely complete. It covers purpose, usage context, and key behavioral traits like transactionality. However, it lacks details on response format, error cases, or prerequisites (e.g., goal existence), which would be helpful for full contextual understanding.

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%, so the schema already documents both parameters ('goalId' and 'tasks') and their nested properties thoroughly. The description adds some semantic context by explaining the hierarchical structure and 'parentId' usage, but does not provide significant additional meaning beyond what the schema specifies, such as format examples or constraints not in 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 clearly states the specific action ('Add multiple tasks to a goal') and resource ('tasks'), distinguishing it from siblings like 'create_goal' (different resource), 'get_tasks' (read vs write), 'complete_task_status' (update vs create), and 'remove_tasks' (delete vs add). It also specifies the hierarchical capability, which further differentiates it.

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 provides clear context on when to use this tool: for adding multiple tasks in a batch, including hierarchical structures. It explicitly mentions using 'parentId' for children of existing tasks, which helps differentiate from creating new subtasks within the batch. However, it does not explicitly state when NOT to use it or name alternatives among siblings, such as using 'create_goal' for goals instead of tasks.

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

complete_task_statusC

Update the completion status of tasks. Task IDs use a dot-notation (e.g., "1", "1.1", "1.1.1"). Responses will return simplified task objects without createdAt, updatedAt, or parentId.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalIdYesID of the goal containing the tasks (number)
taskIdsYesIDs of the tasks to update (array of strings). Example: ["1.1", "1.2"].
completeChildrenNoWhether to complete all child tasks recursively (boolean). Defaults to false. If false, a task can only be completed if all its subtasks are already complete.

TDQS

C2.9/5.0
Behavior2/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 of behavioral disclosure. It mentions that responses return simplified task objects without certain fields, which adds some context about output behavior. However, it fails to disclose critical traits like whether this is a mutation (implied by 'Update'), permission requirements, error handling, or side effects on child tasks beyond the parameter description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by important details about ID format and response format. Both sentences earn their place by providing necessary context. It avoids redundancy and is appropriately sized for a tool with three parameters.

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

Completeness2/5

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

Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about behavioral traits (e.g., authentication needs, side effects), error conditions, and typical usage patterns. While it covers ID format and response simplification, it doesn't compensate for the absence of structured data about the tool's operation.

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%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning the dot-notation format for task IDs, which is useful but not essential since the schema provides an example. No additional semantic context is given for parameters like 'goalId' or 'completeChildren' beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Update' and resource 'completion status of tasks', making the purpose immediately understandable. It distinguishes from siblings like 'add_tasks' or 'remove_tasks' by focusing on status modification rather than creation or deletion. However, it doesn't explicitly contrast with 'get_tasks' for read vs. write operations.

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 is provided on when to use this tool versus alternatives like 'add_tasks' or 'remove_tasks'. The description mentions task ID format and response format but offers no context about prerequisites, error conditions, or typical scenarios for invoking this tool. Usage is implied only through the action of updating status.

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

create_goalC

Create a new goal

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionYesThe software development goal description (string)
repoNameNoPlease give the name of the project that you are currently working on (string)

TDQS

C2/5.0
Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Create a new goal' implies a write/mutation operation but doesn't disclose any behavioral traits: no information about permissions required, whether creation is idempotent, what happens on failure, what the response contains, or any side effects. For a mutation tool with zero annotation coverage, this is critically inadequate.

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 maximally concise at just three words. While it's severely under-specified in terms of content, it's not verbose or poorly structured. Every word earns its place, and there's no wasted text. The extreme brevity represents efficient communication, even if the content is inadequate.

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

Completeness1/5

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

Given this is a mutation tool (creating new goals) with no annotations, no output schema, and sibling tools that suggest this is part of a task/goal management system, the description is completely inadequate. It doesn't explain what a 'goal' represents in this system, how it relates to tasks, what happens after creation, or what the agent should expect as a result. The description fails to provide the contextual understanding needed for effective tool 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?

The schema description coverage is 100%, with both parameters well-documented in the schema itself. The description adds no parameter information beyond what the schema already provides. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new goal' is essentially a tautology that restates the tool name without providing meaningful context. It doesn't specify what type of goal (software development goal as indicated in the schema), what system it creates it in, or how it differs from sibling tools like 'add_tasks' or 'complete_task_status'. The description lacks the specificity needed to distinguish this tool's purpose.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance about when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or how this tool relates to sibling tools like 'add_tasks' (which might add tasks to existing goals) or 'get_tasks' (which retrieves tasks). The agent receives no help in determining when this specific creation tool is appropriate.

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

get_tasksB

Get tasks for a goal. Task IDs use a dot-notation (e.g., "1", "1.1", "1.1.1"). When includeSubtasks is specified, responses will return hierarchical task objects. Otherwise, simplified task objects without createdAt, updatedAt, or parentId will be returned.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalIdYesID of the goal to get tasks for (number)
taskIdsNoOptional: IDs of tasks to fetch (array of strings). If null or empty, all tasks for the goal will be fetched.
includeSubtasksNoLevel of subtasks to include: "none" (only top-level tasks), "first-level" (top-level tasks and their direct children), or "recursive" (all nested subtasks). Defaults to "none".none
includeDeletedTasksNoWhether to include soft-deleted tasks in the results (boolean). Defaults to false.

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond the input schema: it explains the dot-notation for task IDs and describes how 'includeSubtasks' affects response structure (hierarchical vs. simplified objects). However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a mutation-free but data-retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with the core purpose stated first. Both sentences add value: the first explains task ID format, and the second details response variations based on 'includeSubtasks.' There's no wasted text, though it could be slightly more structured (e.g., bullet points for clarity).

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?

Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers key behavioral aspects like response formatting but omits details on permissions, error cases, or output structure. Without an output schema, more guidance on return values would be beneficial, but it's adequate for basic usage.

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%, so the input schema fully documents all parameters. The description adds marginal value by clarifying the dot-notation format for task IDs and the effect of 'includeSubtasks' on response objects, but it doesn't provide additional syntax or meaning beyond what the schema already covers. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get tasks for a goal.' It specifies the verb ('Get') and resource ('tasks for a goal'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'add_tasks' or 'remove_tasks' beyond the basic verb distinction, which prevents a perfect score.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., 'add_tasks' for adding tasks or 'complete_task_status' for updating status) or clarify scenarios where this tool is preferred. Usage is implied only by the action 'Get,' with no explicit context or exclusions provided.

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

remove_tasksA

Soft-delete multiple tasks from a goal. Tasks are marked as deleted but remain in the system. Task IDs use a dot-notation (e.g., "1", "1.1", "1.1.1"). Responses will return simplified task objects without createdAt, updatedAt, or parentId. Soft-deleted tasks are excluded by default from get_tasks results unless includeDeletedTasks is set to true.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalIdYesID of the goal to remove tasks from (number)
taskIdsYesIDs of the tasks to remove (array of strings). Example: ["1", "1.1"].
deleteChildrenNoWhether to delete child tasks along with the parent (boolean). Defaults to false. If false, attempting to delete a parent task with existing subtasks will throw an error.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does so effectively. It discloses key behavioral traits: the soft-delete mechanism (tasks remain in system), the dot-notation for task IDs, the simplified response format (excluding specific fields), and how soft-deleted tasks are handled in 'get_tasks' (excluded by default unless a parameter is set). It does not cover aspects like error handling or permissions, but provides substantial context beyond basic functionality.

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 appropriately sized and front-loaded, starting with the core action and key details (soft-delete, task ID format, response format). Every sentence adds value, with no redundant or unnecessary information, making it efficient 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 tool's complexity (mutation with soft-delete behavior), no annotations, and no output schema, the description is largely complete. It explains the operation, task ID format, response format, and interaction with 'get_tasks'. However, it lacks details on error scenarios (e.g., what happens if 'goalId' is invalid) and does not describe the output structure beyond mentioning simplified objects, which could be improved since there's no output schema.

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%, so the schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema, such as mentioning 'task IDs use a dot-notation' which aligns with the schema's example, but does not provide additional meaning or usage details for parameters like 'goalId' or 'deleteChildren'. Baseline 3 is appropriate as the schema does the heavy lifting.

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 specific action ('soft-delete multiple tasks from a goal'), distinguishes it from permanent deletion by explaining tasks are 'marked as deleted but remain in the system', and differentiates from siblings like 'get_tasks' by focusing on removal rather than retrieval or creation.

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 provides clear context on when to use this tool (for soft-deleting tasks) and implicitly suggests alternatives by mentioning 'get_tasks' with 'includeDeletedTasks' for viewing deleted tasks. However, it does not explicitly state when NOT to use it or compare it directly to other sibling tools like 'add_tasks' or 'complete_task_status'.

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

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

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: add_tasks for batch creation, complete_task_status for updating status, create_goal for goal creation, get_tasks for retrieval, and remove_tasks for soft deletion. There is no overlap in functionality, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., add_tasks, complete_task_status, create_goal, get_tasks, remove_tasks). The naming is uniform and predictable, with no deviations in style or convention.

Tool Count5/5

With 5 tools, the server is well-scoped for task orchestration, covering core operations like creation, retrieval, update, and deletion. Each tool serves a necessary function without redundancy, fitting typical server sizes of 3-15 tools.

Completeness4/5

The tool set provides strong coverage for task management, including CRUD-like operations (create, get, update status, soft delete) and goal creation. A minor gap exists in updating goal details or hard-deleting tasks, but agents can work around this with the available tools.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/coderexpert123/task-orchestrator'

If you have feedback or need assistance with the MCP directory API, please join our Discord server