Skip to main content
Glama

getTaskSubtasks

Retrieve all subtasks for a specific Teamwork task, including pagination options and completed task filtering.

Instructions

Get all subtasks for a specific task in Teamwork

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskIdYesThe ID of the task to get subtasks from
pageNoPage number for pagination
pageSizeNoNumber of items per page
includeCompletedTasksNoInclude completed tasks in the results

Implementation Reference

  • The handler function that implements the core logic of the 'getTaskSubtasks' tool. It extracts input parameters, builds query params, calls the Teamwork API to fetch subtasks for the given taskId, and returns the response or handles errors.
    export async function handleGetTaskSubtasks(input: any) {
      try {
        const { taskId, page, pageSize, includeCompletedTasks, ...otherParams } = input;
        
        logger.info(`Getting subtasks for task ID: ${taskId}`);
        
        // Build query parameters
        const queryParams: Record<string, any> = {
          page,
          pageSize,
          includeCompletedTasks,
          ...otherParams
        };
        
        // Filter out undefined values
        Object.keys(queryParams).forEach(key => 
          queryParams[key] === undefined && delete queryParams[key]
        );
        
        // Make API call
        const apiClient = getApiClientForVersion();
        const response = await apiClient.get(
          `/tasks/${taskId}/subtasks.json`, 
          { params: queryParams }
        );
        
        return {
          content: [{
            type: "text",
            text: JSON.stringify(response.data, null, 2)
          }]
        };
      } catch (error: any) {
        return createErrorResponse(error, 'Retrieving task subtasks');
      }
    } 
  • The tool definition including name, description, input schema (with required taskId and optional pagination params), and annotations for the 'getTaskSubtasks' tool.
    export const getTaskSubtasksDefinition = {
      name: "getTaskSubtasks",
      description: "Get all subtasks for a specific task in Teamwork",
      inputSchema: {
        type: "object",
        properties: {
          taskId: {
            type: "integer",
            description: "The ID of the task to get subtasks from"
          },
          page: {
            type: "integer",
            description: "Page number for pagination"
          },
          pageSize: {
            type: "integer",
            description: "Number of items per page"
          },
          includeCompletedTasks: {
            type: "boolean",
            description: "Include completed tasks in the results"
          }
        },
        required: ["taskId"]
      },
      annotations: {
        title: "Get Task Subtasks",
        readOnlyHint: false,
        destructiveHint: false,
        openWorldHint: false
      }
    };
  • Registration of the 'getTaskSubtasks' tool in the central toolPairs array, pairing its definition and handler for use in toolDefinitions and toolHandlersMap.
    { definition: getTasksMetricsLate, handler: handleGetTasksMetricsLate },
    { definition: getTaskSubtasks, handler: handleGetTaskSubtasks },
  • Re-export of the handleGetTaskSubtasks handler from the index file for convenient access.
    export { handleGetTaskSubtasks } from './tasks/getTaskSubtasks.js';
  • Import of the getTaskSubtasks definition and handler into the central index file.
    import { getTaskSubtasksDefinition as getTaskSubtasks, handleGetTaskSubtasks } from './tasks/getTaskSubtasks.js';
Behavior3/5

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

Annotations already indicate readOnlyHint=false, openWorldHint=false, and destructiveHint=false, covering safety and scope. The description adds no behavioral context beyond the basic action, such as pagination behavior, rate limits, or authentication needs, but doesn't contradict annotations.

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 a single, efficient sentence with zero waste, front-loading the core purpose ('Get all subtasks') and specifying the context ('for a specific task in Teamwork'). It's appropriately sized for its function.

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) and rich annotations, the description is minimally adequate. It states the purpose but lacks details on usage context, behavioral traits, or output format, leaving gaps that could hinder agent effectiveness.

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 parameters are fully documented in the schema. The description adds no additional meaning beyond implying retrieval of subtasks, which aligns with the schema but doesn't enhance parameter understanding beyond the baseline.

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 ('Get all subtasks') and target resource ('for a specific task in Teamwork'), distinguishing it from sibling tools like getTaskById, getTasks, or getTaskComments. It precisely identifies the scope of retrieval without ambiguity.

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 prerequisites (e.g., needing a valid taskId), exclusions, or comparisons to similar tools like getTasksByProjectId or getTaskListsByProjectId, leaving the agent to infer usage context.

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/Vizioz/Teamwork-MCP'

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