Skip to main content
Glama
TylerIlunga

Procore MCP Server

Update Action Plan Item

update_action_plan_item
Idempotent

Update an existing action plan item in Procore. Modify only the fields you need, leaving others unchanged.

Instructions

Updates an existing action plan item in the specified Procore project. Send only the fields you intend to change; omitted fields keep their current values. Pass the record's fields as top-level arguments — they are nested under "plan_item" in the request payload for you. project_id defaults to the value set by procore_set_config when omitted, and id must identify an existing parent record — resolve it with the matching list tool first. Returns the modified action plan item on success. 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, id. Procore API: Project Management > Action Plans. Endpoint: PATCH /rest/v1.0/projects/{project_id}/action_plans/plan_items/{id}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesURL path parameter — unique identifier of the Action Plans resource
notesNoJSON request body field — notes for the Action Plan Item
titleNoJSON request body field — title of the Action Plan Item
due_atNoJSON request body field — due Date of the Action Plan Item
status_idNoJSON request body field — status ID of the Action Plan Item (1 - open, 2 - in_progress, 3 - delayed, 4 - closed)
project_idYesURL path parameter — unique identifier for the project.
descriptionNoJSON request body field — description of the Action Plan Item
holding_typeNoJSON request body field — action Plan Item holding type specifies whether the current item holds all the succeeding items in the section or the plan
Behavior5/5

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

The description goes well beyond the annotations by detailing partial-update behavior, project_id defaulting via procore_set_config, success return value, and error payloads with specific HTTP statuses and their causes. This complements the readOnlyHint=false and idempotentHint=true annotations without contradicting them.

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 a single, logically ordered paragraph: purpose, update semantics, payload mapping, required fields, resolution guidance, return, and error handling. It is information-dense but each sentence contributes, though it could be tightened by omitting the verbose error enumeration.

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?

For a write tool with no output schema and 8 parameters, the description covers the operation, required parameter resolution, defaults, return behavior, and common failure modes. Combined with a 100% schema coverage, the agent has everything needed to invoke 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 already covers all 8 parameters with individual descriptions, so the baseline is 3. The description adds value by clarifying that optional fields are truly partial-update fields, that arguments are flattened from a nested 'plan_item' payload, and that project_id can default from config, which enhances understanding of required params.

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 ('Updates') and resource ('action plan item') scoped to a Procore project, clearly distinguishing it from related create/delete/list siblings. It also states it modifies existing records, reinforcing the tool's role.

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?

The description explains partial-update semantics ('Send only the fields you intend to change') and instructs resolving the id with the matching list tool first, giving clear context for when to invoke it. It does not explicitly name sibling tools or state when not to use it, but the prerequisites and scope are sufficient guidance.

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