Skip to main content
Glama

omnifocus_write

Destructive

Create, update, complete, or delete OmniFocus tasks and projects with a single call. Supports batch operations, folder nesting, and tag management.

Instructions

Create, update, complete, or delete OmniFocus tasks and projects.

OPERATIONS:

  • create: New task/project with data

  • create_folder: New folder (name required, optional parentFolder for nesting)

  • update: Modify existing (provide id + changes; "data" accepted as an alias for "changes"; target defaults to "task" if omitted)

  • complete: Mark done (provide id; target defaults to "task" if omitted)

  • delete: Remove permanently (provide id, or its alias target_id)

  • batch: Multiple operations in one call

  • bulk_delete: Delete multiple items by IDs

  • tag_manage: Manage tag hierarchy (create, rename, delete, merge, nest, unnest, reparent)

FOLDER CREATION:

  • operation: "create_folder"

  • data.name: Folder name (required)

  • data.parentFolder: Parent folder name, path ("Parent : Child"), or ID (optional, omit for top-level)

  • Supports nested path lookup with " : " syntax (parent must already exist)

BATCH OPERATIONS:

  • operations: Array of create, update, complete, and delete operations

  • Execution order: creates first, then updates, completes, deletes last

  • Put tempId and parentTempId inside data (not at operation level)

  • Updates/completes can reference tempIds from creates in the same batch

  • createSequentially: true (respects dependencies)

  • returnMapping: true (returns tempId → realId map)

  • stopOnError: true (halt on first failure)

  • Example with subtasks: { "mutation": { "operation": "batch", "operations": [ { "operation": "create", "target": "task", "data": { "name": "Parent", "tempId": "p1", "project": "My Project" } }, { "operation": "create", "target": "task", "data": { "name": "Subtask", "tempId": "s1", "parentTempId": "p1" } } ] } }

REPETITION RULES (in data.repetitionRule):

  • frequency: "daily"|"weekly"|"monthly"|"yearly" (required)

  • interval: number (default 1)

  • method: "fixed"|"due-after-completion"|"defer-after-completion" (default "fixed")

  • daysOfWeek: [{ day: "SU"|"MO"|"TU"|"WE"|"TH"|"FR"|"SA", position?: number }] (for weekly)

  • daysOfMonth: [1-31] (for monthly, -1 = last day)

REVIEW INTERVAL (project-only, in data.reviewInterval or changes.reviewInterval):

  • Number of days: 7 (weekly), 14 (biweekly), 30 (monthly)

  • Object form: { steps: 1, unit: "weeks" } or { steps: 2, unit: "months" }

  • Valid units: "days", "weeks", "months", "years" (singular also accepted)

  • Both forms are accepted; object form matches OmniFocus read output

TAG OPERATIONS:

  • tags: [...] - Replace all tags

  • addTags: [...] - Add to existing

  • removeTags: [...] - Remove from existing

  • Nested tags use " : " path syntax: "Parent : Child : Leaf" (creates hierarchy, assigns leaf)

TAG MANAGEMENT (tag_manage operation):

  • create: Create new tag (tagName required). Supports " : " path syntax for nested hierarchies.

  • rename: Rename tag (tagName + newName required)

  • delete: Delete tag (tagName required)

  • merge: Merge source into target (tagName + targetTag required)

  • nest: Move tag under parent (tagName + parentTag required)

  • unnest: Move tag to root level (tagName required)

  • reparent: Move tag to different parent (tagName + parentTag required)

DATE FORMATS:

  • Date only: "YYYY-MM-DD" (defaults: due=5pm, defer=8am, planned=8am)

  • Date+time: "YYYY-MM-DD HH:mm" (local time)

  • Clear date: null or clearDueDate/clearDeferDate/clearPlannedDate: true

MOVE TO INBOX: Set project: null

SAFETY:

  • Delete is permanent - confirm with user first

  • Batch supports up to 100 operations

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mutationYes
Behavior5/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds detailed behavioral context: 'Delete is permanent', batch execution order, date defaults (due=5pm, defer=8am), move-to-inbox via project: null, and support for nested paths. It does not contradict annotations.

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 lengthy but well-organized with section headers (OPERATIONS, FOLDER CREATION, BATCH, etc.) and front-loaded with a summary. Every section is informative and necessary given the tool's complexity. It could be slightly more concise (e.g., repeating examples), but overall it is efficient for the domain.

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

Completeness4/5

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

Given the tool's complexity (multiple operations, nested parameters) and lack of output schema, the description covers inputs thoroughly, including date formats, tag management, and batch behavior. It does not describe return values, which is acceptable for a mutation tool. The description is sufficiently complete for an AI agent to invoke correctly.

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

Parameters5/5

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

The input schema has 0% description coverage (only target_id and completionDate have descriptions). The description fully compensates by explaining the mutation object structure, each operation's required/optional fields, aliases (target_id for id), and examples (batch, tag_manage). It adds semantics not present in schema, like 'data accepted as alias for changes' and 'target defaults to task'.

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 tool's purpose: 'Create, update, complete, or delete OmniFocus tasks and projects.' It lists all operations and distinguishes itself from sibling tools (omnifocus_analyze, omnifocus_read) which are read-only. The verb 'manage' in the title also reinforces purpose.

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?

The description provides explicit guidance on when to use each operation, including batch usage, folder creation, and tag management. It includes safety warnings ('Delete is permanent - confirm with user first'), execution order in batches, and data formats. It clearly differentiates from alternatives by stating it is for mutations, while siblings are for reading/analysis.

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/kip-d/omnifocus-mcp'

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