Skip to main content
Glama

task_create

Create subtasks under tickets to break down work into manageable steps, track implementation details, and organize project hierarchies.

Instructions

PROJECT MANAGEMENT (TPM): Create a task (sub-item) under a ticket.

USE THIS TOOL WHEN:

  • Breaking down a ticket into smaller tasks

  • User asks to add implementation steps

  • Creating a work breakdown structure

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ticket_idYesParent ticket ID
titleYesTask title
detailsNoTask details/implementation notes
statusNoTask status (default: pending)
priorityNoPriority (default: medium)
complexityNoComplexity estimate (default: medium)

Implementation Reference

  • MCP tool handler for 'task_create': parses input arguments, validates with TaskCreate model, delegates to database layer, returns success confirmation.
    if name == "task_create":
        task = db.create_task(
            TaskCreate(
                ticket_id=args["ticket_id"],
                title=args["title"],
                details=args.get("details"),
                status=TaskStatus(args.get("status", "pending")),
                priority=Priority(args.get("priority", "medium")),
                complexity=Complexity(args.get("complexity", "medium")),
            )
        )
        # Return minimal confirmation to avoid context bleed
        return f"Created task: {task.id} - {task.title} [{task.status.value}]"
  • Registers the 'task_create' tool with the MCP server, defining its name, description, and JSON schema for input validation.
            Tool(
                name="task_create",
                description="""PROJECT MANAGEMENT (TPM): Create a task (sub-item) under a ticket.
    
    USE THIS TOOL WHEN:
    - Breaking down a ticket into smaller tasks
    - User asks to add implementation steps
    - Creating a work breakdown structure""",
                inputSchema={
                    "type": "object",
                    "properties": {
                        "ticket_id": {"type": "string", "description": "Parent ticket ID"},
                        "title": {"type": "string", "description": "Task title"},
                        "details": {
                            "type": "string",
                            "description": "Task details/implementation notes",
                        },
                        "status": {
                            "type": "string",
                            "enum": ["pending", "in-progress", "done", "blocked"],
                            "description": "Task status (default: pending)",
                        },
                        "priority": {
                            "type": "string",
                            "enum": ["critical", "high", "medium", "low"],
                            "description": "Priority (default: medium)",
                        },
                        "complexity": {
                            "type": "string",
                            "enum": ["simple", "medium", "complex"],
                            "description": "Complexity estimate (default: medium)",
                        },
                    },
                    "required": ["ticket_id", "title"],
                },
            ),
  • Pydantic model defining the structure and validation for task creation input data used in the handler.
    class TaskCreate(BaseModel):
        ticket_id: str
        title: str
        details: str | None = None
        status: TaskStatus = TaskStatus.PENDING
        priority: Priority = Priority.MEDIUM
        complexity: Complexity = Complexity.MEDIUM
        acceptance_criteria: list[str] | None = None
        metadata: dict[str, Any] | None = None
  • Core database helper: generates unique task ID based on ticket, inserts task record into SQLite 'tasks' table, handles JSON serialization for metadata fields, returns Task model instance.
    def create_task(self, data: TaskCreate) -> Task:
        # Get ticket to extract prefix
        ticket = self.get_ticket(data.ticket_id)
        if not ticket:
            raise ValueError(f"Ticket {data.ticket_id} not found")
    
        # Count existing tasks for this ticket to generate task number
        count = self.conn.execute(
            "SELECT COUNT(*) FROM tasks WHERE ticket_id = ?", (data.ticket_id,)
        ).fetchone()[0]
    
        # Generate task ID like TASK-TICKET-001-1
        ticket_num = ticket.id.replace("TICKET-", "").replace("FEAT-", "").replace("ISSUE-", "")
        id = f"TASK-{ticket_num}-{count + 1}"
        now = self._now()
    
        self.conn.execute(
            """INSERT INTO tasks (id, ticket_id, title, details, status, priority, complexity,
               created_at, acceptance_criteria, metadata)
               VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)""",
            (
                id,
                data.ticket_id,
                data.title,
                data.details,
                data.status.value,
                data.priority.value,
                data.complexity.value,
                now,
                _to_json(data.acceptance_criteria),
                _to_json(data.metadata),
            ),
        )
        self.conn.commit()
        return Task(
            id=id,
            ticket_id=data.ticket_id,
            title=data.title,
            details=data.details,
            status=data.status,
            priority=data.priority,
            complexity=data.complexity,
            created_at=datetime.fromisoformat(now),
            acceptance_criteria=data.acceptance_criteria,
            metadata=data.metadata,
        )
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. While it mentions this is a creation tool, it doesn't describe what happens upon creation (e.g., whether a task ID is returned, if there are permission requirements, rate limits, or how it interacts with the parent ticket). For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.

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 efficiently structured with a clear purpose statement followed by bullet-point usage guidelines. Every sentence earns its place by providing specific guidance without unnecessary elaboration. It's appropriately sized and front-loaded with the most important information.

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 creation tool with no annotations and no output schema, the description provides good purpose and usage guidance but lacks behavioral details about what happens after creation. The schema covers parameters well, but the description doesn't compensate for the missing output information or permission/rate limit context that would be helpful for a mutation tool.

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 6 parameters thoroughly with descriptions and enum values. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where 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 action ('Create a task'), the resource ('sub-item under a ticket'), and the domain context ('PROJECT MANAGEMENT (TPM)'). It distinguishes this tool from sibling tools like 'ticket_create' or 'project_create' by specifying it creates tasks under tickets rather than standalone items.

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

Usage Guidelines5/5

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

The description includes an explicit 'USE THIS TOOL WHEN' section with three specific scenarios: breaking down tickets into smaller tasks, adding implementation steps, and creating work breakdown structures. This provides clear guidance on when to use this tool versus alternatives like 'ticket_update' or 'note_add'.

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/urjitbhatia/tpm-mcp'

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