Skip to main content
Glama
deenesjakoruzh
coderexpert123

Task Orchestration

by coderexpert123
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

작업 오케스트레이터

작업 오케스트레이션 및 관리를 위한 MCP(Model Context Protocol) 서버입니다. 이 도구는 목표를 관리 가능한 작업으로 세분화하고 진행 상황을 추적하는 데 도움을 줍니다.

사용 방법

이상적으로는 LLM이 이 MCP 도구를 언제 사용해야 하는지 이해할 수 있어야 합니다. 하지만 샘플 프롬프트로 다음과 같은 형식을 사용할 수 있습니다.

"새로운 개발 목표를 만들어 줘. 목표는 '사용자 인증 구현'이고 'my-web-app' 저장소를 위한 거야."

문제가 발생하면 상단 'Discussions' 탭에서 새 이슈를 생성하여 알려주세요.

Related MCP server: Claudia

주요 기능

  • 목표 생성 및 관리

  • 목표를 계층적 작업으로 세분화

  • 작업 완료 상태 추적

  • 하위 작업 지원 및 상위 작업과 하위 작업 간의 종속성 관리

  • LokiDB를 사용한 영구 저장소

로드맵

  • 복잡한 작업/목표 간 상호 종속성 오케스트레이션

  • 목표 삭제

  • 완료 처리

  • 진행 상황 시각화를 위한 UI

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

    • 목표에서 여러 작업을 소프트 삭제합니다. 작업은 삭제된 것으로 표시되지만 시스템에 남아 있습니다. 기본적으로 하위 작업이 있는 상위 작업은 하위 작업을 명시적으로 삭제하지 않으면 소프트 삭제할 수 없습니다. 소프트 삭제된 작업은 includeDeletedTasks가 true로 설정되지 않는 한 기본적으로 get_tasks 결과에서 제외됩니다.

    • 매개변수:

      {
  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 - AI 프롬프트 템플릿

    • __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.

  1. 5 tool updates
    • First observedadd_tasks
    • First observedcomplete_task_status
    • First observedcreate_goal
    • First observedget_tasks
    • First observedremove_tasks
Deploy Server
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

B3.4/5.0

Scored across 5 tools

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
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Google Tasks MCP Server

    omshejul
    A
    license
    Not graded
    quality
    D
    maintenance
    A comprehensive MCP server that enables LLMs to manage Google Tasks and task lists through workflow-oriented tools for creation, updating, searching, and organizing tasks.
    MIT

  • TaskFlow MCP

    AdarshVijay101
    F
    license
    A
    quality
    C
    maintenance
    A production-ready MCP server for task management, enabling LLMs to create, list, and manage tasks via tools and resources, with support for local stdio and cloud Streamable HTTP deployment.
    5
    -

Appeared in Searches