Skip to main content
Glama
IDEAManagement

idea-base-mcp-server

Official
by IDEAManagement
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

create_task

Create a new task in a project with title, due date, priority, assignee, and subtask options; returns the task ID for tracking.

Instructions

Create a new task in a project. Returns the created task with its ID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesTitle of the task
due_dateNoDate the task is due, as YYYY-MM-DD.
priorityNoPriority level (0-5, higher is more important)
project_idYesThe ID of the project to add the task to
start_dateNoDate work is planned to start, as YYYY-MM-DD.
descriptionNoDetailed description of the task
parent_task_idNoMake this a SUBTASK of the given task. The parent must be in the same project, and a subtask cannot itself have subtasks (one level only). A parent with subtasks takes its status from them: any subtask in progress makes the parent in progress, and all subtasks done makes it ready to complete.
assignee_user_idNoUser ID to assign the task to. Must be a member of the same account. Omit to leave the task unassigned.
estimated_minutesNoEstimated time to complete in minutes
acceptance_criteriaNoCriteria for task completion

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.3.0
    • addedInput schema / properties / assignee_user_id
      Added value: +{
+  "description": "User ID to assign the task to. Must be a member of the same account. Omit to leave the task unassigned.",
+  "type": "string"
+}
    • addedInput schema / properties / due_date
      Added value: +{
+  "description": "Date the task is due, as YYYY-MM-DD.",
+  "type": "string"
+}
    • addedInput schema / properties / parent_task_id
      Added value: +{
+  "description": "Make this a SUBTASK of the given task. The parent must be in the same project, and a subtask cannot itself have subtasks (one level only). A parent with subtasks takes its status from them: any subtask in progress makes the parent in progress, and all subtasks done makes it ready to complete.",
+  "type": "number"
+}
    • addedInput schema / properties / start_date
      Added value: +{
+  "description": "Date work is planned to start, as YYYY-MM-DD.",
+  "type": "string"
+}
  2. First observedv1.2.0

TDQS

A3.8/5.0
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 states the core creation behavior and the return value, but does not disclose validation rules, permission requirements, default status, or other side effects. This is minimal but not misleading.

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 two short sentences with no filler, front-loading the core action and then stating the return value. Every word earns its place.

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

Completeness4/5

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

The schema fully documents all parameters, required fields are explicit, and the description provides the return value in the absence of an output schema. It could add operational context like default status or validation behavior, but the essential calling information is present.

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 all 10 parameters are already documented in the input schema. The description adds no extra parameter-level meaning, so the baseline score of 3 applies.

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 uses a specific verb and resource: 'Create a new task in a project,' and explicitly states the return value ('Returns the created task with its ID'). This clearly distinguishes it from siblings like create_project and update_task.

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 implies that this tool is for creating new tasks in a project, but it does not provide explicit when-to-use guidance or mention alternatives such as update_task for modifying existing tasks. The context is clear but the routing around siblings is left to inference.

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

Deploy Server

Other Tools