Skip to main content
Glama
TylerIlunga

Procore MCP Server

Create Lookahead Task

create_lookahead_task

Create a new lookahead task in a Procore project schedule by providing project, lookahead, parent, and task name. Returns the created task with its new ID.

Instructions

Create new Lookahead Task for the project schedule. Pass the record's fields as top-level arguments — they are nested under "lookahead_task" in the request payload for you. project_id defaults to the value set by procore_set_config when omitted. Creates the lookahead task and returns it with its new id (HTTP 201); calling it again creates another record. Failures come back as an error payload carrying the HTTP status — commonly 401 when the token has expired, 403 without tool permission, and 404 when an id does not resolve. Required parameters: project_id, lookahead_id, parent_id, name. Procore API: Project Management > Schedule (Legacy). Endpoint: POST /rest/v1.0/projects/{project_id}/schedule/lookahead_tasks

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesJSON request body field — the name of the Task
commentNoJSON request body field — additional comments
end_dateNoJSON request body field — task end date, in project time zone
segmentsNoJSON request body field — the segments for this Schedule (Legacy) operation
parent_idYesJSON request body field — iD of the parent Lookahead Task
project_idYesURL path parameter — unique identifier for the project.
start_dateNoJSON request body field — task start date, in project time zone
vendor_idsNoJSON request body field — iD of Company(s) to assign to this Lookahead Task
assignee_idsNoJSON request body field — iD of Contact(s) to assign to this Lookahead Task
lookahead_idYesJSON request body field — iD of the associated Lookahead
resource_idsNoJSON request body field — iD of Resource(s) to assign to this Lookahead Task
Behavior5/5

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

The description goes well beyond annotations by disclosing that calling it again creates another record (non-idempotent), that success returns the new id with HTTP 201, and that failures return an error payload with specific HTTP statuses (401, 403, 404). It also explains the project_id default. Annotations (readOnlyHint=false, idempotentHint=false) align with the described mutating, non-idempotent behavior.

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 dense but well-organized, with each sentence serving a purpose: purpose, argument passing, default behavior, return/error behavior, required params, and API reference. It is slightly long but contains no fluff and is appropriately structured.

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 there is no output schema, the description compensates by specifying the return (new id, HTTP 201) and the error payload structure. It also covers default project_id, required parameters, endpoint, and API category. It does not fully explain the semantics of every optional parameter, but the schema handles that, and the description is sufficiently complete for a create operation.

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 the schema already describes all 11 parameters. The description adds valuable context: fields should be passed as top-level arguments despite being nested under 'lookahead_task' in the payload, project_id defaults from procore_set_config, and it lists the required parameters. This adds meaning beyond the schema.

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 'Create new Lookahead Task for the project schedule' with a specific verb and resource. It distinguishes from sibling tools like create_lookahead (which creates a lookahead) and update_lookahead_task/delete_lookahead_task, and provides the exact endpoint.

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

Usage Guidelines3/5

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

The description gives clear context about when to use the tool (creating a lookahead task) and a useful default for project_id from procore_set_config. However, it does not explicitly mention alternatives or when not to use it, such as contrasting with update_lookahead_task or create_lookahead. Usage is implied rather than explicitly contrasted.

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/TylerIlunga/procore-mcp-server'

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