Skip to main content
Glama

p6_lookahead

Read-onlyIdempotent

List a project's look-ahead window for a data date or from_date, showing activities starting, finishing, spanning, in progress or completed, with critical flags, forecast dates and per-week breakdowns.

Instructions

Look-ahead of a project, one page: {total, offset, returned, next_offset, rows, window, weeks, data_date, counts, critical_definition, schedule_state, note}. The window starts at the data date (or from_date; a date alone starts at 00:00), lasts days= (default 14) or weeks= calendar days and is half-open [from, to). Listed: not started activities starting in it, open ones finishing in it, not started ones spanning it (start before, finish after), every in-progress activity (include_in_progress=False keeps those finishing in the window) and, with include_completed=True, completed ones whose actual dates overlap it. Open activities use their remaining dates (early when empty) of the last F9. LOE and WBS summary activities are left out. Each row has window: the categories it meets (in_progress, starting, finishing, spanning, completed), critical (open and critical under the project definition, as p6_critical_path), fcst_start (actual start, else remaining start), fcst_finish (actual finish when completed, else remaining finish) and start_week / finish_week: the week of the window holding that date (1 = the first 7 days from the window start, None outside the window; weeks lists each one's from and to). critical_only=True lists the critical ones only. counts gives the categories and critical over all pages. wbs_name_contains, code_type / code_value / include_child_codes and fields= as in p6_query_activities. Order: start, finish, Activity ID.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "p6_lookahead"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNo
limitNoRows per page (max 200).
weeksNo
fieldsNo
offsetNoRows to skip: pass next_offset from the previous page.
projectYesProject ID as shown in P6 (p6_list_projects).
code_typeNo
from_dateNo
code_valueNo
critical_onlyNo
include_completedNo
wbs_name_containsNo
include_child_codesNo
include_in_progressNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • addedInput schema / properties / critical_only
      Added value: +{
      +  "default": false,
      +  "title": "Critical Only",
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds substantial behavior: LOE and WBS summary activities are omitted, open activities use remaining dates with early-date fallback from the last F9, counts are computed over all pages while rows are paged, and results are ordered by start, finish, Activity ID. Missing only edge behavior such as what happens with an empty window or invalid dates.

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 lead sentence front-loads the return keys and the rest of the paragraph is dense but every clause carries behavior an agent would otherwise have to guess. Minor waste in listing the return keys twice (once as a brace list, then again in prose).

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?

With no output schema, the description must carry the return shape and it does: it names every top-level key (total, offset, returned, next_offset, rows, window, weeks, data_date, counts, critical_definition, schedule_state, note) and explains per-row fields like fcst_start/fcst_finish and start_week/finish_week. For a 14-parameter, paginated, read-only tool this is sufficient to call it correctly.

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 only 21% across 14 parameters, so the description must compensate and largely does: from_date time defaults to 00:00, days/weeks are mutually exclusive window lengths, critical_only and include_completed/include_in_progress filter categories, and code_type/code_value/include_child_codes/fields/wbs_name_contains are explicitly delegated to p6_query_activities. limit and offset semantics are left to the schema, which covers them adequately.

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 opens with a specific verb+resource ('Look-ahead of a project') and immediately enumerates the returned payload, so an agent knows exactly what this tool produces. It is clearly distinct from p6_query_activities and p6_critical_path, which it references only for parameter and definition conventions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It defines the selection window precisely (starts at data date or from_date, days= or weeks=, half-open interval) and spells out exactly which activity categories are listed or excluded. What it does not do is state explicitly when to choose this over p6_query_activities or p6_float_analysis; the routing is implied by the 'look-ahead' framing rather than stated.

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