list_omnifocus_projects

Retrieve all OmniFocus projects to review task organization, track progress, and enable AI agents to manage your work.

Instructions

List OmniFocus projects

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Implementation Reference

server.js:82-86 (registration)

Tool registration in a loop - registers 'list_omnifocus_projects' along with all other tools using server.tool()

for (const [name, desc] of TOOLS) {
  server.tool(name, desc, {}, async () => ({
    content: [{ type: "text", text: "This is an inspection stub. Install Pilot MCP on macOS: npx -y local-mcp@latest setup" }],
  }));
}

server.js:83-85 (handler)

Handler function for list_omnifocus_projects (and all other tools) - returns a stub message indicating this is an inspection stub

server.tool(name, desc, {}, async () => ({
  content: [{ type: "text", text: "This is an inspection stub. Install Pilot MCP on macOS: npx -y local-mcp@latest setup" }],
}));

server.js:40-40 (schema)
Tool entry in TOOLS array defining the name and description - parameters schema is empty object {} (no inputs required)
```
["list_omnifocus_projects", "List OmniFocus projects"],
```

Tool Definition Quality

C2.5/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to specify whether archived/dropped projects are included, if pagination occurs, what fields are returned, or any rate limits.

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?

Extremely concise at three words with no redundancy. While appropriately brief for a zero-parameter tool, the extreme brevity contributes to under-specification in other dimensions.

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

Completeness2/5

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

Given the lack of output schema and annotations, the description should explain return values or filtering behavior. It omits critical context needed to distinguish this from similar list operations in the OmniFocus family.

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

Parameters4/5

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

The input schema has zero parameters, establishing a baseline of 4. The description neither adds nor subtracts value regarding parameters since none exist to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List OmniFocus projects' is tautological—it merely restates the tool name (list_omnifocus_projects) without adding specificity. It fails to distinguish from siblings like list_omnifocus_tasks or list_omnifocus_tags, or clarify scope (e.g., active vs. dropped projects).

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?

No guidance provided on when to use this tool versus alternatives like search_omnifocus_tasks or list_omnifocus_tags. No mention of prerequisites, filtering capabilities, or limitations.

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

Install Server

Pilot MCP