Taskhold

Create a project

taskhold_create_project

Create a project (a group of tasks, usually one per repo). Optional: any tool that takes project creates it on first use. Returns the existing project if one has this name (case-insensitive), without changing it: the reply says if your description or color wasn't applied (taskhold_update_project changes them). Says whether it was created, restored or already existed, plus its id. Fails on an invalid name or at the account's project ceiling (the error says what to do).

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": {
      "name": "<name>"
    },
    "name": "taskhold_create_project"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Project name, e.g. the repo folder ("api-server")
`color`	No	Hex color for the board, e.g. "#2f6fdb" (default: picked from the name)
`description`	No	One line about it

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly=false, destructive=false) by disclosing idempotent semantics: existing projects are returned unchanged on case-insensitive name match, the reply reports whether description/color was applied, and the outcome is labeled created/restored/already existed. It also discloses two failure modes (invalid name, account project ceiling) and that the error says what to do.

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?

Front-loaded with the purpose and then the behavioral contract; every sentence carries information. It is dense and slightly comma-heavy, but there is no filler to cut.

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

Completeness5/5

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

There is no output schema, and the description compensates by explaining what the reply contains (created/restored/existed status plus the id) and how failures surface. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents name, color and description with formats and defaults. The description adds meaning the schema doesn't: name matching is case-insensitive and description/color are not applied to a pre-existing project. Marginal but genuine added value.

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 and resource and immediately defines it ("a group of tasks, usually one per repo"), which distinguishes it from the task-level siblings like taskhold_create. An agent can tell exactly what this produces without opening the schema.

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?

Explicitly says the tool is optional because any tool that takes a project creates it on first use, and routes to taskhold_update_project when description or color need changing on an existing project. That is real when-to-use and when-not-to-use guidance plus a named alternative.

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

All Taskhold tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?