Skip to main content
Glama

Add a subtask

add_subtask

Add a subtask (checklist item) under a task when the user asks to break a task into steps or list items under it (a link in the title opens as a link in the app). Works on the user's own tasks and on tasks of a shared sphere where the user is responsible; not on tasks the user only ticks (shared.my_role member or viewer). Add one subtask per call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>",
      "title": "<title>"
    },
    "name": "add_subtask"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYes
task_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, so the safety profile is covered. The description adds real context beyond that: an ownership/permission model (own tasks, shared sphere where the user is responsible, not member/viewer roles) and the one-subtask-per-call cardinality, which reinforces the non-idempotent hint. No mention of what is returned or of any limit on subtask count.

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?

Three sentences, front-loaded with the core action and trigger, then constraints, then the per-call rule. The parenthetical about links is slightly awkward mid-sentence but every clause carries information.

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?

For a two-param mutation tool with annotations and no output schema, the description covers trigger, permissions, and call cardinality. The remaining gap is behavioral on error (what happens if the task is not accessible) and any response content, which an agent would still have to discover.

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 0%, so the description must compensate for two undocumented parameters. It explains the meaning of 'task_id' implicitly ('under a task') and adds semantics for title (a link in the title opens as a link in the app), but gives no guidance on task_id format, the 200-char limit, or that title must be non-empty. Partial compensation only.

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?

States a specific verb+resource ('Add a subtask (checklist item) under a task') and immediately disambiguates the resource from add_task and update_subtask by defining a subtask as a checklist item nested under a task. An agent can tell which sibling to pick without opening a schema.

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

Usage Guidelines4/5

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

Gives an explicit trigger ('when the user asks to break a task into steps or list items under it') plus exclusions ('not on tasks the user only ticks'). It never names the alternative tool (update_subtask / add_task) by name, which keeps it just short of a 5.

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.