Skip to main content
Glama

things_add_items_to_project

Add structured todos and headings to an existing project in Things 3. Organize tasks under visual separators to group related items within your project workflow.

Instructions

Add todos and headings to an existing project. Items are added as a flat array where headings act as visual separators for the todos that follow them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesUnique system-generated ID of the project (alphanumeric like "pRj123aBc456dEf789gHi", 20-24 chars). NOT the project title! You MUST use things_get_projects to find the correct ID first. Common mistake: using project name like "My Vacation Planning" instead of its ID.
itemsYesAdd structured todos and headings to an existing project. Items are added as a flat array where headings act as visual separators. Todos that follow a heading will appear grouped under it. Example: [{type: 'heading', title: 'Phase 2'}, {type: 'todo', title: 'Task 1'}, {type: 'todo', title: 'Task 2'}].
operationNo

Implementation Reference

  • The implementation of addItemsToProject logic, which iterates over project items and uses executeThingsJSON to add them to a project.
    async addItemsToProject(params: AddItemsToProjectParams): Promise<string> {
      const results = { 
        todos: 0, 
        headings: 0, 
        errors: [] as string[] 
      };
      
      // Create each item as a new to-do assigned to the project
      for (const item of params.items) {
        if (item.type === 'heading') {
          results.headings++;
          // Headings cannot be added to existing projects via JSON API
          // Skip them with a warning (they can only be added during project creation)
          continue;
        }
        
        try {
          // Create to-do and assign it to the project
          const todoAttributes = this.buildFullTodo(item).attributes as Record<string, unknown>;
          todoAttributes['list-id'] = params.id; // Assign to the project
          
          await executeThingsJSON([{
            type: 'to-do',
            attributes: todoAttributes
          }]);
          
          results.todos++;
        } catch {
          results.errors.push(`"${item.title}"`);
        }
      }
      
      // Build detailed response message
      let message = '';
      
      if (results.todos > 0) {
        message = `✅ Added ${results.todos} todo(s) to project`;
      }
      
      if (results.headings > 0) {
        if (message) message += '\n';
        message += `⚠️ Skipped ${results.headings} heading(s) - headings cannot be added to existing projects`;
      }
      
      if (results.errors.length > 0) {
        if (message) message += '\n';
        message += `❌ Failed to add: ${results.errors.join(', ')}`;
      }
      
      if (!message) {
        message = '⚠️ No items were processed';
      }
      
      return message;
    }
  • Registration of the things_add_items_to_project tool definition.
      {
        name: 'things_add_items_to_project',
        description: 'Add todos and headings to an existing project. Items are added as a flat array where headings act as visual separators for the todos that follow them.',
        schema: AddItemsToProjectSchema as any
      }
    ];
  • Handler routing logic for things_add_items_to_project within the UpdateJSONToolHandler class.
    } else if (toolName === 'things_add_items_to_project') {
      const addItemsParams = params as z.infer<typeof AddItemsToProjectSchema>;
      return jsonBuilder.addItemsToProject(addItemsParams);
    }
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It successfully explains the visual grouping behavior ('headings act as visual separators for the todos that follow them'), but lacks disclosure about safety characteristics, error handling, or whether this operation is idempotent or destructive.

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 consists of two efficient sentences with zero waste. The first establishes the action and scope immediately, while the second provides essential structural context about how the array items relate to each other visually.

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?

Given that this is a mutation tool with no output schema and no annotations, the description adequately explains the input structure but leaves gaps around the return value, error conditions, and the purpose of the 'operation' parameter which lacks schema documentation.

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 67% (id and items are well-documented, operation is not). The description adds semantic context about the flat array structure and heading behavior, but doesn't compensate for the undocumented 'operation' parameter or add details beyond what the schema provides for 'id' and 'items'.

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 clearly states the specific action (Add) and resources (todos and headings) with context (existing project). It effectively distinguishes from sibling tools like things_add_project (creates projects) and things_add_todo (likely creates standalone todos) by specifying 'existing project' and 'items'.

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?

While the main description doesn't explicitly list alternatives, it clearly scopes the tool to 'existing' projects, distinguishing it from things_add_project. The schema description for the 'id' parameter provides explicit workflow guidance stating 'You MUST use things_get_projects to find the correct ID first,' which helps prevent common usage errors.

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