OmniFocus MCP Plus

Overview Schema Source Related Servers Discussions Admin

Edit item

edit_item

Destructive

Modify any OmniFocus task or project by renaming, rescheduling dates, updating tags, status, or moving it to another project, folder, or the inbox.

Instructions

Edit a task or project in OmniFocus. Supports: rename, set/clear dates (due, defer, planned), flag/unflag, set status (complete, drop, reopen), add/remove/replace tags, set estimated minutes, move to different project/parent task/inbox.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	The ID of the task or project to edit. An ID that matches nothing is an error — it never falls back to the name.
`name`	No	The name of the task or project to edit (used only when no ID is provided; errors on duplicate names)
`dryRun`	No	Resolve the complete edit and preview changes without writing.
`addTags`	No	Tags to add (works for tasks and projects). Tags that don't exist yet are created.
`newName`	No	New name for the item
`newNote`	No	New note for the item
`itemType`	Yes	Type of item to edit ('task' or 'project')
`addTagIds`	No	Exact tag IDs to add; may be combined with addTags paths.
`newStatus`	No	For tasks: new status (incomplete, completed, dropped). For projects use newProjectStatus.
`newDueDate`	No	Due date. Full ISO 8601 with timezone (e.g., 2026-03-05T09:00:00-06:00), or a bare YYYY-MM-DD which is interpreted as local midnight on that day. Set to empty string to clear.
`newFlagged`	No	Set flagged status (set to false for no flag, true for flag)
`removeTags`	No	Tags to remove (works for tasks and projects)
`moveToInbox`	No	For tasks: move task to inbox
`newFolderId`	No	For projects: new folder to move the project to, by ID. Use list_folders to find IDs. Preferred when names are ambiguous and a path is awkward.
`replaceTags`	No	Tags to replace all existing tags with (works for tasks and projects). Pass an empty array to clear every tag; omit the field to leave tags unchanged.
`newDeferDate`	No	Defer date. Full ISO 8601 with timezone (e.g., 2026-03-05T09:00:00-06:00), or a bare YYYY-MM-DD which is interpreted as local midnight on that day. Set to empty string to clear.
`newProjectId`	No	For tasks: move task to this project ID
`removeTagIds`	No	Exact tag IDs to remove.
`newFolderName`	No	For projects: new folder to move the project to, by name. Accepts slash-separated paths (e.g. 'Someday/Maybe/Travel') when a bare name is ambiguous. Literal-name lookup wins first, so folder names containing '/' still work.
`newSequential`	No	For projects: whether the project should be sequential
`replaceTagIds`	No	Exact tag IDs to replace all tags with; may be combined with replaceTags paths.
`newPlannedDate`	No	Planned date. Full ISO 8601 with timezone (e.g., 2026-03-05T09:00:00-06:00), or a bare YYYY-MM-DD which is interpreted as local midnight on that day. Set to empty string to clear. Requires an OmniFocus build with planned dates; unsupported builds return a warning instead of failing.
`newProjectName`	No	For tasks: move task to this project name (errors on duplicate names)
`newParentTaskId`	No	For tasks: move task under this parent task ID
`newProjectStatus`	No	For projects: new status. For tasks use newStatus.
`newParentTaskName`	No	For tasks: move task under this parent task name (errors on duplicate names)
`dropAllOccurrences`	No	Only meaningful with newStatus: 'dropped' or newProjectStatus: 'dropped'. Defaults to false, which drops just the current occurrence of a repeating item; set true to drop every future occurrence as well.
`newEstimatedMinutes`	No	New estimated minutes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`meta`	No
`tool`	Yes
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Sep 15, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already carry readOnlyHint=false and destructiveHint=true, so the description does not need to restate that this mutates data. However, it adds little behavioral context beyond what the parameter schema already shows — no mention of permanence, side effects, ambiguous-ID behavior, or the dryRun preview option. There is no annotation contradiction.

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?

The description is a single front-loaded sentence that clearly opens with the tool's purpose before listing supported operations. It is dense but not bloated; the list is reasonable for a tool of this breadth.

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 very rich input schema, output schema, and annotations cover most invocation details, so the description need not explain parameters or return values. Still, the missing usage guidance and lack of sibling differentiation leave the description somewhat incomplete as a stand-alone decision aid.

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 the input schema fully documents all 28 parameters. The description's 'Supports:' list mostly mirrors schema property names and categories, adding convenience but no deeper meaning beyond what the schema already provides.

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 tool edits tasks or projects in OmniFocus and enumerates concrete operations (rename, dates, tags, status, etc.). It does not explicitly differentiate itself from siblings like complete_task, move_task, or batch_edit_items, but the verb+resource and capability list make its scope understandable.

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?

There is no guidance about when to use this tool instead of sibling tools such as complete_task, uncomplete_task, move_task, batch_edit_items, or append_to_note. The description implies it is the general-purpose editor, but it never states exclusions or routing rules.

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

Deploy Server