Skip to main content
Glama

get_subtask

Retrieve detailed subtask information, including parent task relationships, progress status, and implementation specifics, for precise work planning and scope assessment. Use an absolute working directory path and unique subtask ID as inputs.

Instructions

Examine subtask details with comprehensive context including parent task relationships, progress status, and implementation specifics. Essential for detailed work planning, progress assessment, and understanding the complete scope of granular work items.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe unique identifier of the subtask to retrieve
workingDirectoryYesThe full absolute path to the working directory where data is stored. MUST be an absolute path, never relative. Windows: "C:\Users\username\project" or "D:\projects\my-app". Unix/Linux/macOS: "/home/username/project" or "/Users/username/project". Do NOT use: ".", "..", "~", "./folder", "../folder" or any relative paths. Ensure the path exists and is accessible before calling this tool. NOTE: When server is started with --claude flag, this parameter is ignored and a global user directory is used instead.

Implementation Reference

  • Core handler function implementing the get_subtask tool logic: input validation, subtask retrieval from storage, enrichment with parent task and project details, formatted response with status and timestamps.
        handler: async ({ id }: { id: string }) => {
          try {
            // Validate input
            if (!id || id.trim().length === 0) {
              return {
                content: [{
                  type: 'text' as const,
                  text: 'Error: Subtask ID is required.'
                }],
                isError: true
              };
            }
    
            const subtask = await storage.getSubtask(id.trim());
    
            if (!subtask) {
              return {
                content: [{
                  type: 'text' as const,
                  text: `Error: Subtask with ID "${id}" not found. Use list_subtasks to see all available subtasks.`
                }],
                isError: true
              };
            }
    
            // Get task and project information
            const task = await storage.getTask(subtask.taskId);
            const project = await storage.getProject(subtask.projectId);
    
            const taskName = task ? task.name : 'Unknown Task';
            const projectName = project ? project.name : 'Unknown Project';
            const status = subtask.completed ? '✅ Completed' : '⏳ Pending';
    
            return {
              content: [{
                type: 'text' as const,
                text: `**${subtask.name}** (ID: ${subtask.id})
    
    **Task:** ${taskName}
    **Project:** ${projectName}
    **Status:** ${status}
    **Details:** ${subtask.details}
    
    **Created:** ${new Date(subtask.createdAt).toLocaleString()}
    **Last Updated:** ${new Date(subtask.updatedAt).toLocaleString()}
    
    Use update_subtask to modify this subtask or mark it as completed.`
              }]
            };
          } catch (error) {
            return {
              content: [{
                type: 'text' as const,
                text: `Error retrieving subtask: ${error instanceof Error ? error.message : 'Unknown error'}`
              }],
              isError: true
            };
          }
        }
  • Input schema definition for the tool, requiring a string 'id' parameter.
    inputSchema: {
      id: z.string()
    },
  • src/server.ts:646-668 (registration)
    MCP server.tool registration for 'get_subtask', defining MCP input schema (workingDirectory + id), description, and wrapper handler that creates storage instance and invokes the tool's handler.
    server.tool(
      'get_subtask',
      'Examine subtask details with comprehensive context including parent task relationships, progress status, and implementation specifics. Essential for detailed work planning, progress assessment, and understanding the complete scope of granular work items.',
      {
        workingDirectory: z.string().describe(getWorkingDirectoryDescription(config)),
        id: z.string().describe('The unique identifier of the subtask to retrieve')
      },
      async ({ workingDirectory, id }: { workingDirectory: string; id: string }) => {
        try {
          const storage = await createStorage(workingDirectory, config);
          const tool = createGetSubtaskTool(storage);
          return await tool.handler({ id });
        } catch (error) {
          return {
            content: [{
              type: 'text' as const,
              text: `Error: ${error instanceof Error ? error.message : 'Unknown error'}`
            }],
            isError: true
          };
        }
      }
    );
  • Storage layer helper method to retrieve a subtask by ID from file-based data (legacy/deprecated but used by the tool).
    async getSubtask(id: string): Promise<Subtask | null> {
      if (!this.data.subtasks) return null;
      return this.data.subtasks.find(s => s.id === id) || null;
    }
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. It describes what the tool does (examine details) but lacks behavioral traits: it doesn't mention if this is a read-only operation, what permissions are needed, error handling, or response format. For a tool with no annotations, this is a significant gap in transparency about how it behaves beyond its basic function.

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 with two sentences that are front-loaded: the first sentence states the purpose, and the second provides usage context. There's minimal waste, though the second sentence could be slightly more direct. It efficiently conveys key information without redundancy.

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 the complexity (a read operation with 2 required parameters), no annotations, and no output schema, the description is incomplete. It explains what the tool does but lacks critical context: it doesn't describe the return values, error conditions, or behavioral details like whether it's idempotent or has side effects. For a tool without structured output or annotations, this leaves significant gaps for an AI agent.

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 ('id' and 'workingDirectory') thoroughly. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter relationships, usage examples, or additional constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.

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: 'Examine subtask details with comprehensive context including parent task relationships, progress status, and implementation specifics.' It uses specific verbs ('examine') and resources ('subtask details'), and mentions what information is retrieved. However, it doesn't explicitly differentiate from sibling tools like 'get_task' or 'get_project' beyond mentioning 'subtask' specificity.

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

Usage Guidelines3/5

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

The description provides implied usage guidelines: 'Essential for detailed work planning, progress assessment, and understanding the complete scope of granular work items.' This suggests when to use it (for detailed examination of subtasks), but doesn't explicitly state when not to use it or name alternatives like 'get_task' for broader task details. It offers some context but lacks clear exclusions or comparisons.

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

Related 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/Pimzino/agentic-tools-mcp'

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