Skip to main content
Glama

edit_item

Edit a single OmniFocus task or project to update names, notes, dates, tags, status, project location, or repetition settings; use batch editing for multiple items.

Instructions

Edit a SINGLE task or project in OmniFocus. For editing 2+ items, use batch_edit_items instead (12x faster).

Input Schema

NameRequiredDescriptionDefault
idNoThe ID of the task or project to edit
nameNoThe name of the task or project to edit (as fallback if ID not provided)
addTagsNoTags to add (works on both tasks and projects)
newNameNoNew name for the item
newNoteNoNew note for the item
itemTypeYesType of item to edit ('task' or 'project')
newStatusNoNew status for tasks (incomplete, completed, dropped)
newDueDateNoNew due date in ISO format (YYYY-MM-DD or full ISO date); set to empty string to clear
newFlaggedNoSet flagged status (set to false for no flag, true for flag)
removeTagsNoTags to remove (works on both tasks and projects)
moveToInboxNoSet to true to move task to inbox
newFolderIdNoNew folder to move the project to (by folder ID)
replaceTagsNoReplace all existing tags (works on both tasks and projects)
markReviewedNoMark project as reviewed (advances next review date by interval). Only applies to projects.
newDeferDateNoNew defer date in ISO format (YYYY-MM-DD or full ISO date); set to empty string to clear
newProjectIdNoMove task to a different project (by project ID)
newFolderNameNoNew folder to move the project to, by name or "Parent > Child" path. If it matches more than one folder, the call fails before changing anything and lists each candidate's path and ID; pass newFolderId to choose one. A name or path that matches no folder creates a new top-level folder named with that exact text, so check spelling and the spaces around " > " (#147).
newSequentialNoWhether the project should be sequential
dropCompletelyNoWhen dropping a repeating task, set to true to drop completely (stop all future occurrences). Default false drops only the current occurrence.
newPlannedDateNoNew planned date (when you intend to work on this) in ISO format; set to empty string to clear
newProjectNameNoMove task to a different project (by project name)
newParentTaskIdNoMove task to be a subtask of another task (by task ID)
newProjectStatusNoNew status for projects
newNextReviewDateNoSet next review date directly (ISO format YYYY-MM-DD). Only applies to projects.
newParentTaskNameNoMove task to be a subtask of another task (by task name)
newRepetitionRuleNoNew repetition rule for the task. Set to null to remove repetition, or provide object to set. Examples: null (remove), {frequency: 'daily'}, {frequency: 'weekly', daysOfWeek: [1,3,5]}
newReviewIntervalNoSet new review interval in days (must be a positive integer). Only applies to projects.
newEstimatedMinutesNoNew estimated minutes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden; it discloses the performance trait (12x faster in batch) which is genuine added context. However, for a 28-parameter mutation tool it says nothing about failure behavior, partial application, idempotency, or what happens when the id/name matches nothing. Key mutation semantics live only in the schema, not the description.

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?

Two short sentences, zero waste, with the scope constraint front-loaded ahead of the alternative. Nothing could be removed without losing routing information.

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?

The exhaustive schema compensates for most gaps, and there is no output schema to explain. Still, the description never mentions that itemType is required or that the target is identified by id or name, nor what the call returns or how it fails — gaps an agent must discover from the schema.

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 every parameter including itemType, id-vs-name fallback, and the newFolderName collision behavior is already documented in the schema. The description adds no parameter guidance beyond scope, so the baseline 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?

States a specific verb (Edit) and resource (a SINGLE task or project in OmniFocus), and explicitly bounds the scope with 'SINGLE'. It names the sibling tool it is not (batch_edit_items), so an agent can distinguish the two without opening either 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?

Provides an explicit routing rule: use this for one item, use batch_edit_items for 2+. The '12x faster' rationale makes the tradeoff concrete rather than arbitrary. No further inference is needed to pick between the two editing tools.

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