Skip to main content
Glama

Create project task

create_project_task

Create a new project task. Requires project_tasks:write scope.

Input Schema

NameRequiredDescriptionDefault
titleYesTask title (required)
statusNoTask status
due_dateNoDue date (ISO 8601)
phase_idNoPhase ID
priorityNoPriority
project_idYesProject ID (required)
start_dateNoStart date (ISO 8601)
assigned_toNoAssigned user - an active member of the organization (see list_users)
descriptionNoDescription
estimated_costNoEstimated cost
parent_task_idNoParent task ID, for a subtask
estimated_hoursNoEstimated hours
completion_percentageNoPercent complete (0-100)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / assigned_to / description
      Previous value: -"Assigned user"New value: +"Assigned user - an active member of the organization (see list_users)"
    • addedInput schema / properties / completion_percentage
      Added value: +{
      +  "description": "Percent complete (0-100)",
      +  "maximum": 100,
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / parent_task_id
      Added value: +{
      +  "description": "Parent task ID, for a subtask",
      +  "format": "uuid",
      +  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$",
      +  "type": "string"
      +}
  2. Changed4 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / phase_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedInput schema / properties / project_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  3. Changed4 schema fields changed
    • changedInput schema / $schema
      Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / phase_id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • removedInput schema / properties / project_id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  4. Changed4 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / phase_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedInput schema / properties / project_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  5. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world operation, so the safety profile is covered. The description contributes real value by naming the required scope, but says nothing about side effects (e.g., whether creating a task affects project rollups or phase metrics) or what the call returns.

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?

Two short sentences, front-loaded with the action and followed by the authorization requirement; neither sentence is filler. It is arguably trimmed a bit too far for a 13-parameter mutation tool, but there is no padding or redundancy.

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?

With 100% schema coverage, most input semantics are handled elsewhere, but this is a 13-parameter write tool with no output schema and 11 optional fields whose interaction (e.g., parent_task_id subtask behavior, assigned_to validity) is left entirely to the schema. The description is adequate but leaves meaningful gaps for a mutation of this complexity.

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% across all 13 parameters, so the schema already explains title, status, priority, due_date, assigned_to and the rest. The description adds no parameter-level meaning beyond that, which is the expected baseline when the schema does the work.

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 states a specific verb and resource ('Create a new project task'), which cleanly separates it from sibling creates like create_project_phase, create_project_milestone, or create_project_task_dependency. It does not, however, explicitly point to any sibling or clarify scope boundaries against similarly named tools.

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 only guidance is an authorization prerequisite ('Requires project_tasks:write scope'), which is a constraint rather than a when-to-use instruction. There is no indication of when to prefer this over bulk_create, or when a task should instead be attached as a subtask via parent_task_id.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources