Skip to main content
Glama

things_update_project

Modify an existing project in Things 3 by updating its title, schedule, structure, completion status, or other properties using JSON data.

Instructions

Update an existing project in Things using JSON API for full feature support

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYes
notesNo
whenNoSchedule the todo: today/tomorrow/evening (relative), anytime/someday (Things categories), YYYY-MM-DD (specific date), or YYYY-MM-DD@HH:MM (specific time)
deadlineNo
tagsNo
area_idNoID of the area to place the project in
areaNoName of the area to place the project in
itemsNoCreate a structured project with sections (headings) and todos in a flat array. Each item must have a 'type' field: 'heading' for section dividers, 'todo' for tasks. Items are siblings - todos after a heading are visually grouped under it. Example: [{type: 'heading', title: 'Day 1'}, {type: 'todo', title: 'Morning walk'}, {type: 'todo', title: 'Breakfast'}, {type: 'heading', title: 'Day 2'}, {type: 'todo', title: 'Museum visit'}]. Order matters - todos appear under the most recent heading.
completedNo
canceledNo
idYesUnique system-generated ID of the project to update (alphanumeric, 20-24 chars). NOT the project title! Use things_get_projects or things_search to find the correct ID first. Example: "xYz789aBc123dEf456gHi"
operationNo

Implementation Reference

  • The actual logic that executes the 'things_update_project' tool by constructing a JSON payload and calling the Things URL scheme.
    async updateProject(params: UpdateProjectJSONParams): Promise<string> {
      const updateData = {
        type: 'project',
        operation: 'update',
        id: params.id,
        attributes: this.convertProjectParams(params)
      };
      
      await executeThingsJSON([updateData]);
      return `✅ Project updated successfully: "${params.title || 'Updated project'}"`;
    }
  • The registration of the 'things_update_project' tool in the tool handler.
      name: 'things_update_project',
      description: 'Update an existing project in Things using JSON API for full feature support',
      schema: UpdateProjectJSONSchema as any
    },
Behavior2/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 mentions 'JSON API for full feature support' indicating this is the comprehensive method, but fails to disclose mutation semantics (partial vs full replacement), safety characteristics, or side effects of the update operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is efficient with no wasted words, but it is undersized for a 12-parameter mutation tool with complex nested structures (the 'items' array). While the sentence earns its place, the overall structure lacks necessary elaboration for this complexity level.

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

Completeness2/5

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

Given high complexity (12 parameters, mutation operation, sophisticated 'items' structure), zero annotations, and no output schema, a single-sentence description is grossly insufficient. Critical gaps remain around error handling, partial update behavior, and return values.

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

Parameters2/5

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

Schema coverage is only 42%, leaving 7 parameters undocumented in the schema (including ambiguous fields like 'operation', 'completed', 'canceled'). The description adds zero parameter-specific context or syntax guidance, failing to compensate for the schema gaps.

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 clearly states the verb (Update), resource (existing project), and domain (Things). The phrase 'existing project' effectively distinguishes this from sibling tool 'things_add_project', though it could explicitly mention the creation alternative for maximum clarity.

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?

While 'existing project' implies a prerequisite, there is no explicit guidance on when to use this versus 'things_add_items_to_project' (which also adds items to projects) or 'things_add_project'. The description lacks 'when-not-to-use' exclusions or prerequisite instructions beyond what's in the schema.

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/hildersantos/things-mcp'

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