Skip to main content
Glama
108yen

task-orchestrator-mcp

by 108yen

listTasks

Retrieve tasks from a hierarchical structure, showing root tasks by default or filtering to display direct children of a specified parent task.

Instructions

List tasks from hierarchical structure, optionally filtered by parentId. Returns root tasks if no parentId specified, or direct children of specified parent task.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
parentIdNoFilter tasks by parent ID to get direct children (optional, returns root tasks if not specified)

Implementation Reference

  • Core implementation of listTasks: reads all tasks from storage and returns either root tasks (if no parentId) or direct children of the specified parent task.
    export function listTasks(params?: { parentId?: string }): Task[] {
      const tasks = readTasks()
    
      if (!params?.parentId) {
        // Return root level tasks
        return tasks
      }
    
      // Find the parent task and return its direct children
      const parentTask = findTaskById(tasks, params.parentId)
      if (!parentTask) {
        // Return empty array for non-existent parent (graceful handling)
        return []
      }
    
      return parentTask.tasks
    }
  • src/tools.ts:161-209 (registration)
    Registers the 'listTasks' tool with the MCP server, defining its input schema (optional parentId) and a thin wrapper handler that calls the core listTasks function and formats the response.
    // Register listTasks tool
    server.registerTool(
      "listTasks",
      {
        description:
          "List tasks from hierarchical structure, optionally filtered by parentId. Returns root tasks if no parentId specified, or direct children of specified parent task.",
        inputSchema: {
          parentId: z
            .string()
            .describe(
              "Filter tasks by parent ID to get direct children (optional, returns root tasks if not specified)",
            )
            .optional(),
        },
      },
      (args) => {
        try {
          const tasks = listTasks(args)
          return {
            content: [
              {
                text: JSON.stringify({ tasks }, null, 2),
                type: "text",
              },
            ],
          }
        } catch (error) {
          return {
            content: [
              {
                text: JSON.stringify(
                  {
                    error: {
                      code: "TASK_LIST_ERROR",
                      message:
                        error instanceof Error ? error.message : "Unknown error",
                    },
                  },
                  null,
                  2,
                ),
                type: "text",
              },
            ],
            isError: true,
          }
        }
      },
    )
  • Zod input schema for listTasks tool: optional parentId string to filter children.
      parentId: z
        .string()
        .describe(
          "Filter tasks by parent ID to get direct children (optional, returns root tasks if not specified)",
        )
        .optional(),
    },
  • Helper function used by listTasks to find parent task by ID in the nested task hierarchy.
    export function findTaskById(tasks: Task[], id: string): Task | undefined {
      for (const task of tasks) {
        if (task.id === id) {
          return task
        }
        const found = findTaskById(task.tasks, id)
        if (found) {
          return found
        }
      }
      return undefined
    }
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 describes the hierarchical nature of the data structure and the filtering behavior, which is valuable. However, it doesn't mention pagination, rate limits, authentication requirements, or what format the returned tasks will have (though there's no output schema). The description adds meaningful context but leaves gaps in behavioral understanding.

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 perfectly concise - two sentences that efficiently convey purpose, parameter behavior, and default behavior. Every word earns its place with zero redundancy or unnecessary elaboration. The structure is front-loaded with the core purpose followed by parameter specifics.

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

Completeness3/5

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

For a simple read operation with one optional parameter and 100% schema coverage, the description provides adequate context about the hierarchical nature and filtering behavior. However, with no annotations and no output schema, it doesn't address important behavioral aspects like pagination, rate limits, or return format. The description is complete enough for basic usage but lacks depth for production scenarios.

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 fully documents the single optional parameter. The description adds marginal value by reinforcing the parent-child relationship context and clarifying that omitting parentId returns root tasks, but doesn't provide additional semantic meaning beyond what's in the schema description field.

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

Purpose5/5

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

The description clearly states the verb ('List') and resource ('tasks from hierarchical structure'), and distinguishes this tool from siblings by specifying it's for listing rather than creating, updating, or deleting tasks. The mention of hierarchical structure and parent-child relationships provides specific context beyond a generic list operation.

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

Usage Guidelines4/5

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

The description provides clear context about when to use this tool (to list tasks, optionally filtered by parentId) and what happens with/without the parameter. However, it doesn't explicitly mention when to use alternatives like 'getTask' for single task retrieval or 'search' operations if available, though the sibling tool names suggest this is the primary listing tool.

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

Install Server

Other Tools

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/108yen/task-orchestrator-mcp'

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