Skip to main content
Glama
deenesjakoruzh
coderexpert123

Task Orchestration

by coderexpert123
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

Оркестратор задач

Сервер протокола контекста модели (MCP) для оркестрации и управления задачами. Этот инструмент помогает разбивать цели на управляемые задачи и отслеживать их выполнение.

Как использовать

В идеале LLM должна понимать, когда следует использовать этот MCP-инструмент. Но в качестве примера промпта может подойти что-то вроде этого:

"Создай для меня новую цель разработки. Цель: 'Реализовать аутентификацию пользователей' для репозитория 'my-web-app'."

СООБЩИТЕ МНЕ о любых проблемах, с которыми вы столкнетесь, создав новый тикет во вкладке 'Discussions' вверху.

Related MCP server: Claudia

Функции

  • Создание целей и управление ими

  • Разбиение целей на иерархические задачи

  • Отслеживание статуса выполнения задач

  • Поддержка подзадач и управление зависимостями между родительской задачей и подзадачами

  • Постоянное хранилище с использованием LokiDB

Дорожная карта

  • Оркестрация сложных взаимозависимостей задач/целей

  • Удаление целей

  • Статусы завершения

  • Интерфейс для визуализации прогресса

Справочник API

Соглашение об именовании ID задач

ID задач используют точечную нотацию (например, "1", "1.1", "1.1.1"), где каждый сегмент представляет уровень в иерархии.

  • Для каждой новой цели ID задач верхнего уровня начинаются с "1" и увеличиваются последовательно (например, "1", "2", "3").

  • Подзадачи имеют ID, сформированные путем добавления нового сегмента к ID родителя (например, "1.1" — это подзадача "1").

  • Комбинация goalId и taskId гарантированно уникальна.

Инструменты

Сервер предоставляет следующие инструменты (на основе build/index.js):

  1. create_goal

    • Создать новую цель

    • Параметры:

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

    • Пример ввода:

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

    • Возвращает: { goalId: number }

  2. add_tasks

    • Добавить несколько задач к цели. Задачи могут быть предоставлены в иерархической структуре. Для задач, которые являются дочерними по отношению к существующим задачам, используйте поле parentId. Операция является транзакционной: либо все задачи в пакете успешно добавляются, либо вся операция завершается неудачей.

    • Параметры:

      {
  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.
  }>;
}

    • Пример ввода:

      {
  "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"
    }
  ]
}

    • Возвращает: HierarchicalTaskResponse[]. Объекты HierarchicalTaskResponse упрощены и не включают createdAt, updatedAt или parentId.

  3. remove_tasks

    • Мягкое удаление нескольких задач из цели. Задачи помечаются как удаленные, но остаются в системе. По умолчанию родительская задача с подзадачами не может быть мягко удалена без явного удаления ее дочерних элементов. Мягко удаленные задачи по умолчанию исключаются из результатов get_tasks, если includeDeletedTasks не установлено в true.

    • Параметры:

      {
  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.
}

    • Пример ввода (без удаления дочерних элементов):

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

    • Пример ввода (с удалением дочерних элементов):

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

    • Возвращает: { removedTasks: TaskResponse[], completedParents: TaskResponse[] }. Объекты TaskResponse упрощены и не включают createdAt, updatedAt или parentId.

  4. get_tasks

    • Получить задачи для цели. ID задач используют точечную нотацию (например, "1", "1.1", "1.1.1"). Когда указан includeSubtasks, ответы будут возвращать иерархические объекты задач. В противном случае будут возвращены упрощенные объекты задач без createdAt, updatedAt или parentId.

    • Параметры:

      {
  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.
}

    • Пример ввода:

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

    • Возвращает: TaskResponse[]. Объекты TaskResponse упрощены и не включают createdAt, updatedAt или parentId.

  5. complete_task_status

    • Пометить задачи как выполненные. По умолчанию родительская задача не может быть помечена как выполненная, если у нее есть невыполненные дочерние задачи.

    • Параметры:

      {
  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.
}

    • Пример ввода (без завершения дочерних элементов):

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

    • Пример ввода (с завершением дочерних элементов):

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

    • Возвращает: TaskResponse[]. Объекты TaskResponse упрощены и не включают createdAt, updatedAt или parentId.

Примеры использования

Создание цели и задач

// 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"

Управление статусом задач

// 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"
});

Удаление задач

// 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
});

Разработка

Предварительные требования

  • Node.js 18+

  • pnpm

Настройка

  1. Установите зависимости:

    pnpm install

  2. Соберите проект:

    pnpm build

  3. Запустите тесты:

    pnpm test

Структура проекта

  • src/ - Исходный код

    • index.ts - Основная реализация сервера

    • storage.ts - Уровень постоянного хранения данных

    • types.ts - Определения типов TypeScript

    • prompts.ts - Шаблоны промптов для ИИ

    • __tests__/ - Файлы тестов

Лицензия

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updates
    • First observedadd_tasks
    • First observedcomplete_task_status
    • First observedcreate_goal
    • First observedget_tasks
    • First observedremove_tasks
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