Skip to main content
Glama

forecast_pack

Packs forecast tasks into a time budget, returning selected tasks in execution order prioritized by flag and due date. Use to decide what to do with limited time.

Instructions

Pack today's forecast tasks into a time budget. Use when the user asks 'I have N hours; what should I do?' or wants a focused subset of forecast tasks that fit a limited window. Do NOT use for the full forecast — prefer forecast_get for that. Do NOT use to schedule work across multiple days — pass scope='next7' as a hint, but the pack is still budget-bounded; for true multi-day planning use forecast_get with days>1 and let the agent compose. Pass budgetMinutes (1–1440) and optional filter { tagIds?, scope? }; scope is 'today' (default) or 'next7'. Returns { selected[], totalMinutes, skipped[] }. selected[] are the picks in execution order (flagged first, then dueDate ascending, then stable by ID). skipped[] surfaces tasks the agent should ask the user about: { reason: 'no-estimate' } means the task has no estimatedMinutes so couldn't be packed; { reason: 'exceeds-budget' } means it would have fit individually but was bumped by earlier higher-priority picks. Read-only; no side effects; safe to retry. Pack algorithm is greedy — predictable and explainable beats optimal-by-1-minute. Example: forecast_pack({ budgetMinutes: 120 }) Example: forecast_pack({ budgetMinutes: 240, filter: { tagIds: ["tag123"], scope: "today" } })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNoOptional filter narrowing the candidate set before packing.
budgetMinutesYesTime budget in minutes (1–1440 — i.e. up to 24 hours). Selected tasks' estimatedMinutes will sum to ≤ this value.
Behavior5/5

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

With no annotations, the description fully discloses behavior: read-only, no side effects, safe to retry. It details the greedy algorithm, ordering (flagged, dueDate, ID), and explains skipped[] reasons (no-estimate, exceeds-budget).

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 comprehensive but slightly verbose. It front-loads the purpose and usage, then covers behavior and examples. Each sentence is meaningful, but could be tightened slightly.

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 no output schema, the description explains the return structure (selected[], totalMinutes, skipped[]) and algorithm in detail. It covers all aspects needed for correct use: parameters, behavior, side effects, and examples. Very complete.

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 by explaining how parameters affect the algorithm, providing range limits, and including example calls. However, it doesn't add much beyond what the schema already provides for filter properties.

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's core function: 'Pack today's forecast tasks into a time budget.' It provides specific use cases (user asks 'I have N hours; what should I do?') and explicitly distinguishes from sibling tools like forecast_get and multi-day planning.

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 gives clear when-to-use guidance (budgeting tasks into a time window) and explicit when-not-to-use (full forecast, multi-day scheduling) with alternatives (forecast_get). It also explains how to use it with parameters and 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