Skip to main content
Glama

forecast_get

Retrieve forecast-view tasks from OmniFocus, grouped by overdue, due today, deferred today, and flagged. Plan your day or week by specifying a date and number of days.

Instructions

Get forecast-view tasks from OmniFocus grouped by category: overdue, dueToday, deferredToday, flagged. Use this for 'what's on my plate today' or multi-day planning queries. Do NOT use to list all tasks across all projects; prefer task_list instead. Supply date (ISO-8601 or shortcut like 'today', 'tomorrow') and days (1–7) for the ergonomic interface, or use from/to for exact ISO-8601 ranges. All include flags default to true; set to false to omit a category. When days > 1, response also includes byDate[] grouping task IDs per calendar day (dereference from dueToday[]). Returns { overdue[], dueToday[], deferredToday[], flagged[], byDate? } plus pagination { hasMore, cursor }; byDate entries are { date, taskIds[] }. Pages span the union of all four buckets (a task in multiple buckets counts once); default 50 tasks per page (max 200). Safe to call repeatedly; no side effects. Example: forecast_get({ date: "today" }) Example: forecast_get({ date: "today", days: 3, includeFlagged: false }) Example: forecast_get({ date: "today", limit: 25, cursor: "" })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd of date range (ISO-8601 or relative shortcut like 'today'). Use date/days for the ergonomic interface instead. Defaults to end of today.
dateNoAnchor date for the forecast (ISO-8601 or relative shortcut: today, tomorrow, yesterday, this-week, next-week). Mutually exclusive with from/to. Defaults to today.
daysNoNumber of days to cover (1–7). Default 1. When > 1, byDate[] is included in the response.
fromNoStart of date range (ISO-8601 or relative shortcut like 'today'). Use date/days for the ergonomic interface instead. Defaults to start of today.
limitNoMax unique tasks per page (1..200). Default 50. Pagination spans the union of overdue/dueToday/deferredToday/flagged: a task that appears in multiple buckets counts once. Use `cursor` to fetch subsequent pages.
cursorNoOpaque cursor from a previous forecast_get response. Must use the same filters (date/from/to/days/include* /fields) — changing filters mid-sequence returns a ValidationError.
fieldsNoRestrict each returned task (across overdue/dueToday/deferredToday/flagged/byDate) to this list of top-level fields (id is always returned). Omit for the full task shape. Empty array returns just id. Unknown names are dropped silently and surface in meta.warnings.WARN_UNKNOWN_FIELDS. Allowed: name, note, noteHtml, projectId, parentId, tagIds, deferDate, deferDateFloating, dueDate, dueDateFloating, estimatedMinutes, flagged, completed, completedAt, dropped, droppedAt, available, blocked, sequential, completedByChildren, repetition, notifications, createdAt, modifiedAt, _links.
includeFlaggedNoInclude all flagged incomplete tasks. Default true.
includeOverdueNoInclude tasks overdue before the start of the range. Default true.
maxOutputBytesNoCap the serialized byte size of the forecast payload (the overdue/dueToday/deferredToday/flagged/byDate buckets together). When the page would exceed this, the server keeps as many whole tasks as fit, sets meta.truncatedAtCap=true with meta.bytesReturned and meta.itemsReturned, and returns a pagination cursor that resumes at the first dropped task. Omit for no cap. Values above the server's hard ceiling (~1 MiB) are clamped. A single task larger than the cap is still returned whole so pagination always advances.
includeDeferredNoInclude tasks whose defer date falls within the range. Default true.
Behavior5/5

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

With no annotations, the description fully covers behavioral traits: no side effects, safe to call repeatedly, pagination behavior with cursor, response structure including byDate when days>1, and handling of maxOutputBytes truncation. No contradictions with annotations since none exist.

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 well-structured, starting with purpose, then usage, parameter details, response format, and examples. It is front-loaded and informative, though slightly lengthy; could be more concise while retaining all key information.

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

Completeness5/5

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

Given 11 parameters, no output schema, and moderate complexity, the description covers the response structure (categories, byDate, pagination with cursor and hasMore), parameter behaviors (fields filtering, maxOutputBytes), and edge cases (cursor validation, field dropping). It feels complete for the tool's context.

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?

Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining ergonomic vs exact date interfaces, default inclusion of all categories, and interplay between parameters (e.g., days>1 triggers byDate). This justifies a 4.

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 retrieves forecast-view tasks grouped by categories (overdue, dueToday, deferredToday, flagged) and explicitly distinguishes it from task_list for listing all tasks, providing specific use cases like 'what's on my plate today'.

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 explicitly states when to use (daily planning, multi-day queries) and when not (prefer task_list for listing all tasks). It also provides guidance on parameter choices (date/days vs from/to) and includes 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