Skip to main content
Glama
TylerIlunga

Procore MCP Server

Update Change Event

update_change_event

Update an existing Change Event by supplying only the fields to change. Modifies the specified resource and returns the updated object.

Instructions

Update Change Event. Use this to update an existing Change Events (only the supplied fields are changed). Updates the specified Change Events and returns the modified object on success. Required parameters: id, project_id. Procore API (v1.1): Construction Financials > Change Events. Endpoint: PATCH /rest/v1.1/change_events/{id}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesURL path parameter — unique identifier of the Change Events resource
project_idYesQuery string parameter — unique identifier for the project.
attachmentsNoJSON request body field — not to be used if other attachment types are included
attachments_by_drawing_revisionNoJSON request body field — attachments_by_drawing_revision
attachments_by_file_versionNoJSON request body field — attachments_by_file_version
attachments_by_formNoJSON request body field — the attachments by form for this Change Events operation
attachments_by_imageNoJSON request body field — attachments_by_image
attachments_by_uuidNoJSON request body field — the attachments by uuid for this Change Events operation
change_itemsNoJSON request body field — change Event Line Items
change_reasonNoJSON request body field — the change reason for this Change Events operation
change_typeNoJSON request body field — the change type for this Change Events operation
custom_fieldsNoJSON request body field — the custom fields for this Change Events operation
descriptionNoJSON request body field — the description for this Change Events operation
event_originNoJSON request body field — the event origin for this Change Events operation
external_dataNoJSON request body field — the external data for this Change Events operation
numberNoJSON request body field — the number for this Change Events operation
prime_contract_for_estimatesNoJSON request body field — prime_contract_for_estimates
scopeNoJSON request body field — event Scope
sourceNoJSON request body field — the Change Event source refers to the resource that was responsible for creating this Change Event.
source_of_revenue_romNoJSON request body field — revenue ROM source for this Change Event
statusNoJSON request body field — the status for this Change Events operation
titleNoJSON request body field — the title for this Change Events operation
Behavior4/5

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

The description discloses that the tool updates and returns the modified object, and that only supplied fields are changed. Annotations indicate it is not read-only or destructive, and the description aligns with this. It adds context beyond annotations by specifying the partial update behavior and the endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 sentences) and front-loaded with the core purpose. Each sentence serves a clear function: identifying the tool, explaining partial update, stating required parameters, and providing API context. No unnecessary words.

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 the complexity (22 parameters, no output schema), the description adequately covers the key points: it's a partial update, returns the modified object, requires id and project_id, and specifies the endpoint. It could have mentioned the HTTP method (PATCH) explicitly, but the endpoint implies it. Overall sufficient for a complex tool.

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 description's mention of required parameters (id, project_id) adds little beyond the schema. However, it explains partial update semantics and provides the endpoint URL, which adds value. The description does not detail each parameter but leverages 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 the verb 'update' and the resource 'Change Events', with specific details like partial update (only supplied fields are changed) and required parameters. It distinguishes from siblings such as 'create_change_event' and 'clone_change_event' by specifying it updates existing records.

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 provides clear context for when to use this tool (update an existing Change Event), mentions partial update behavior, and lists required parameters. However, it does not explicitly state when not to use it or offer alternatives, such as for creating or cloning.

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