Skip to main content
Glama

project_list

List OmniFocus projects using filters for status, folder, flagged, or review due date.

Instructions

List projects in OmniFocus with optional filters. Use for queries across projects. Do NOT use for a known single project (use project_get). Filters: folderId, status, flagged, reviewDueBefore. Returns projects[] with pagination; safe to call repeatedly; no side effects. Example: project_list({}) Example: project_list({ status: "active", folderId: "fld123" })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax projects per page (1..1000). Default 50. Use `cursor` to fetch subsequent pages.
cursorNoOpaque cursor from a previous project_list response. Must use the same filters — changing filters mid-sequence returns a ValidationError.
fieldsNoRestrict each returned project to this list of top-level fields (id is always returned). Omit for the full project shape. Empty array returns just id. Unknown names surface in meta.warnings.WARN_UNKNOWN_FIELDS.
statusNoRestrict to projects with this status. 'active' = available; 'on-hold' = paused; 'done' = completed; 'dropped' = abandoned. Omit for any status. Accepts: 'paused' → on-hold, 'completed' → done, 'cancelled' → dropped.
flaggedNotrue = flagged only; false = unflagged only; omit = both.
verboseNoWhen true, return the full unelided project shape. Default: false — fields equal to their documented default (status: 'active', completionCriterion: 'parallel', flagged: false, tagIds: [], note: null, etc.) are omitted. See docs/token-cost.md for the defaults table.
folderIdNoRestrict to projects inside this folder. Get the ID from folder_list. Omit for all folders.
includeLinksNoWhen true, each project carries a `_links` HATEOAS block (self, folder). Default false — the block is omitted to save payload size. Use the project's `id` and `folderId` fields directly instead.
maxOutputBytesNoCap the serialized byte size of the returned projects[] array. When the response would exceed this, the server returns as many whole projects as fit, sets meta.truncatedAtCap=true with meta.bytesReturned and meta.itemsReturned, and returns a pagination cursor that resumes at the first dropped project. Omit for no cap. Values above the server's hard ceiling (~1 MiB) are clamped. A single project larger than the cap is still returned whole so pagination always advances.
reviewDueBeforeNoRestrict to projects whose next review date is strictly before this moment. ISO-8601 with offset (e.g. '2026-05-01T00:00:00-07:00'). Projects without a review interval are excluded.
Behavior4/5

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

With no annotations, the description adds important behavioral context: 'Returns projects[] with pagination; safe to call repeatedly; no side effects.' This goes beyond the schema. However, it does not mention rate limits or authentication, which are typical concerns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short (three sentences plus two inline examples) and front-loaded with the purpose. Every sentence adds value, with no fluff. The examples are concise and illustrative.

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 10 parameters and no output schema, the description covers core functionality, safety, and pagination. It could be improved by noting that the cursor must respect filter consistency (already in schema but useful in description). Overall, it provides sufficient context for effective use.

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 coverage is 100%, so baseline is 3. The description lists some filters (folderId, status, flagged, reviewDueBefore) but does not add significant meaning beyond the schema's own detailed descriptions. The examples are helpful but not enough to raise the score.

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 verb (List) and resource (projects), and explicitly distinguishes this tool from the sibling 'project_get' by specifying when not to use it. 'List projects in OmniFocus with optional filters' is specific and actionable.

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?

Explicitly tells when to use ('Use for queries across projects') and when not to ('Do NOT use for a known single project'), naming the alternative (project_get). Also mentions filters and provides examples.

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

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