Skip to main content
Glama
Sign In
Contractor Foreman MCP Server

Contractor Foreman MCP Server

by cotletdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

List schedule tasks

list_schedule_tasks
Read-onlyIdempotent

Retrieve a project's schedule tasks in Gantt order, including dates, duration, dependencies, assignees, and percent complete. Use the project ID to inspect task status and plan updates.

Instructions

Gantt schedule tasks of a project: dates, duration, dependencies, assignees, percent complete.

Returns the tasks of the project schedule in Gantt order. kind is task, milestone or summary (a group whose dates follow its subtasks). end_date is the task's last day, inclusive. depends_on lists the tasks this one waits for, with the link type and lag in days. Use task_id with update_schedule_task. An empty list means the project has no schedule yet.

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_id": "<project_id>"
    },
    "name": "list_schedule_tasks"
  }
}

Input Schema

NameRequiredDescriptionDefault
project_idYesproject_id from list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description correctly spends its words on domain semantics: Gantt ordering, the kind taxonomy including summary groups whose dates follow subtasks, inclusive end_date, and the shape of depends_on with link type and lag. It does not mention permissions, pagination, or result size limits, which keeps it short of a 5.

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?

Purpose and return contents are front-loaded in the first sentence, with field-level clarifications following in compact form. Every sentence carries information, though the mix of result-shape notes and the update cross-reference in one running paragraph makes it slightly denser than ideal.

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?

There is no output schema, so the description must explain return values, and it does so well: ordering, kind values, inclusive end_date, and dependency structure. Only secondary operational details such as pagination or whether large schedules are truncated are absent.

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?

There is exactly one parameter and schema coverage is 100%, with the schema itself saying 'project_id from list_projects.' The description adds no further meaning about that parameter (the task_id it mentions is an output field, not an input), so the baseline of 3 applies.

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?

States a specific verb and resource ('Gantt schedule tasks of a project') plus the fields returned (dates, duration, dependencies, assignees, percent complete). It also implicitly distinguishes itself from the mutating sibling by naming update_schedule_task for the write path, so an agent can tell read from write without opening a schema.

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?

Gives concrete follow-up routing ('Use task_id with update_schedule_task') and an interpretation rule ('An empty list means the project has no schedule yet'). It never states an explicit exclusion or an alternative listing tool, but there is no obvious competing sibling for schedule reads, so the guidance is clear rather than exhaustive.

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

Deploy Server

Other Tools