v1.4 — Response Shaping

The OmniFocus MCP server your agent can actually depend on.

Production-grade infrastructure for AI agents. 46ms reads. 2,086 tests. Your tasks deserve a bridge that won't break under pressure.

Paste into Claude Desktop config Copy
{
  "mcpServers": {
    "omnifocus-operator": {
      "command": "uvx",
      "args": ["omnifocus-operator"]
    }
  }
}
or
Ask your agent Copy
Set up the OmniFocus Operator MCP server for me — uvx omnifocus-operator
2,086
Tests
97%
Coverage
46ms
Full Read
11
Tools
3
Layers

You've tried the other OmniFocus MCP servers.

The first one took 3 seconds to return your tasks. The second crashed silently when OmniFocus wasn't running. The third worked fine — until your agent tried to edit a task and got back nothing. No error. No feedback. Just silence and a broken conversation.

These projects are thin AppleScript wrappers. Flat scripts with no test coverage, no error handling, no awareness that an AI agent is on the other end. They work for demos. They break when you depend on them.

OmniFocus is where your work lives. The bridge to it deserves the same care.

Three steps. No configuration.

01

Configure

Paste the config JSON into Claude Desktop. uvx downloads, isolates, and runs the server automatically — no install step.

02

Grant access

OmniFocus will ask you to allow automation access on first launch. One click, never again.

03

Ask Claude

"Show me my OmniFocus tasks." That's it. Full read/write access to your OmniFocus database.

Speed that disappears.

Your agent shouldn't wait. At 46ms for a full database snapshot, it won't. We read OmniFocus's local SQLite database directly — no AppleScript, no OmniJS round-trips.

OmniFocus Operator 46ms
Bridge-only servers 1–3s
OperationLatency
Full task read38–40ms
Full snapshot (all tables)45–49ms
Filtered queries5.8–6.0ms
Task + tag joins5.1–6.0ms

Benchmarked on a real database: 2,800+ tasks, 368 projects, 65 tags.

Agent-first intelligence.

Most MCP servers return data. OmniFocus Operator returns data and teaches your agent to be better. Every response carries context that makes the next interaction smarter.

Warnings that teach

When an agent tries to add a tag that's already present, it learns to check first.

Tag 'Errands' (tag-abc) is already on this task
🛡

Status-aware guardrails

Edits to completed tasks go through — but the agent learns to pause before modifying finished work.

This task is completed — your changes were applied,
but please confirm with the user that they intended
to edit a completed task.

No-op detection

When an edit would change nothing, the agent learns patch semantics in context.

No changes detected — the task already has these
values. If you don't want to change a field, omit it
from the request.

Error-serving degraded mode

If startup fails, the server stays alive. Every tool call returns the error — visible to the agent, actionable by the user.

OmniFocus Operator failed to start:

[specific error message]

Restart the server after fixing.

Two-axis status model

A task can be both overdue AND blocked. No information loss from a single-winner enum.

Urgency — Is this pressing?
overdue due_soon none
Availability — Can this be worked on?
available blocked completed dropped

Say it. Watch it happen.

Four position modes give your agent pixel-perfect control over task order. No other OmniFocus MCP server can do this.

Work Project
Prompt
“Organize my project — Q1 Wrap-up first with the retro and budget, Q2 Planning next with goals before the kickoff, feature spec at the end”
→ 7 edit_tasks calls

What just happened?

One sentence. Four position modes. Seven API calls.

beginning
Q1 Wrap-up → first in project
"beginning": "proj_work"
ending
Retro, room, budget → under Q1 Wrap-up
"ending": "task_q1"
after
Q2 Planning → right after Q1 Wrap-up
"after": "task_q1"
before
Goals → right before kickoff slides
"before": "task_kickoff"

The server stays alive. Always.

MCP servers that crash silently leave your agent stranded. This one doesn't crash.

Degraded-mode serving

If startup fails, every tool call returns the error. No silent crashes. No mysterious timeouts. The agent sees what went wrong.

Automatic fallback

SQLite cache unavailable? The server falls back to the OmniJS bridge. Slower, but functional. Your agent never gets a dead connection.

Factory safety guard

If test code tries to access the live OmniFocus database, the factory raises a RuntimeError. Not a warning — a hard stop.

Eleven tools. Full control.

All read tools are idempotent. Write tools support tags, dates, flags, notes, estimated duration, task movement, repetition rules, and hierarchy properties (parallel/sequential, completes-with-children). List tools support filtering by parent subtree.

get_all
Read
Full OmniFocus database as structured data
get_task
Read
Look up a single task by ID
get_project
Read
Look up a single project by ID
get_tag
Read
Look up a single tag by ID
add_tasks
Write
Create tasks in OmniFocus
edit_tasks
Write
Edit tasks with patch semantics
list_tasks
Read
Filter by date, flags, tags, project — with pagination
list_projects
Read
Filter by status, folder, review schedule, flags
list_tags
Read
List tags with parent hierarchy
list_folders
Read
List folders with parent hierarchy
list_perspectives
Read
List custom perspectives
Create a task add_tasks
{
  "items": [{
    "name": "Review Q3 roadmap",
    "parent": "pJKx9xL5beb",
    "tags": ["Work", "Planning"],
    "dueDate": "2026-03-15T17:00:00Z",
    "flagged": true,
    "estimatedMinutes": 30
  }]
}
Edit with patch semantics edit_tasks
{
  "items": [{
    "id": "oRx3bL_UYq7",
    "addTags": ["Urgent"],
    "dueDate": null,       // ← clears the date
    "moveTo": {
      "ending": "pJKx9xL5beb"
    }
  }]
}
InputMeaning
Field omittedNo change
nullClear the value
A valueUpdate

Three layers. Clean boundaries.

You don't need to understand the architecture to use it. But it's why the server is fast, reliable, and maintainable.

MCP Tools
OperatorService
Repository Protocol
HybridRepository
SQLite + Bridge
BridgeRepository
Fallback
InMemoryRepository
Tests

How we compare.

Other great projects exist. Here are the facts.

Feature OmniFocus Operator themotionmachine jqlts1 deverman
Language Python 3.12+ TypeScript TypeScript Swift
Tools 11 10 17 13
Automated Tests 2,086 0 12 ~4 suites
Code Coverage 97%
Read Latency ~46ms 1–3s 1–3s ~1s
Architecture 3-layer Flat Flat Multi-layer
Graceful Degradation
Agent-First UX

You can trust it.

2,558 tests across Python and JavaScript. Strict mypy with Pydantic plugin. Ruff linting across 9 rule categories. The build fails below 80% coverage.

2,558
Total tests
97%
Coverage
80%
CI minimum
50+
Validation scripts
InMemoryBridge
Unit tests, business logic
Fast
SimulatorBridge
IPC integration testing
Medium
RealBridge
Manual UAT only
Human-verified

Active development. Clear direction.

v1.0
Foundation — core read tools, three-layer architecture, test suite
v1.1
Performance — SQLite caching, 30–60x speedup
v1.2
Writes & Lookups — add/edit tasks, get-by-ID tools
v1.3
Read Tools — SQL filtering, list/count, 5 new tools
v1.4
Response Shaping & Batch Processing
v1.4.1
Task Properties & Subtree — presence flags, auto-complete, parallel/sequential, parent filter
v1.5
Project Writes — add/edit projects, review marking
v1.6
UI & Perspectives — perspective switching, deep links
v1.7
Production Hardening — retry, crash recovery, serial execution

Ready to try it?

macOS, OmniFocus 4, Python 3.12+. That's all you need.

Claude Desktop config Copy
{
  "mcpServers": {
    "omnifocus-operator": {
      "command": "uvx",
      "args": ["omnifocus-operator"]
    }
  }
}