Things 3 is the clearest example of an asymmetric MCP integration. Writing is easy and reliable, because Things exposes a well-designed URL scheme that accepts a fully specified to-do. Reading is awkward, because there is no cloud API at all and a server has to script the local app to find out what is in your lists.
What that asymmetry means in practice
Capture works beautifully. "Add a project for the client onboarding with these six steps, due Friday" becomes a correctly structured Things project in one call. Anything that requires knowing your current state — "what's overdue", "what's in Today" — depends entirely on whether your server implements local reads, and only on a Mac.
Fire-and-forget writes
The URL scheme hands the request to the app and does not report back much. If a date was malformed, you may get a to-do without a date and no error anywhere. After setting this up, glance at the first few items the assistant creates rather than trusting them blindly.
Who should bother
People who use Things as their trusted system and want frictionless capture from wherever they are already typing. If what you want is an assistant that reviews and reorganises your existing list, Things is a poor fit and no server will change that.
Where LemTask stands today
LemTask does not ship an MCP server yet, and we are not going to pretend otherwise on a page developers will read. What LemTask has working right now is outbound and inbound webhooks, Zapier, Make and Apple Shortcuts, which covers "when a task is created, do X" and "create a task from anything that can send an HTTP request". An MCP connection is on the roadmap; when it ships and we have tested it end to end with Claude, this page will say so with the config block, and not a day earlier.