Skip to main content
Glama
TylerIlunga

Procore MCP Server

List Change Events

list_change_events
Read-onlyIdempotent

List change events for a project to obtain a paginated overview, find IDs, or filter by dates, status, budget, and other criteria.

Instructions

List Change Events. Use this to enumerate Change Events when you need a paginated overview, to find IDs, or to filter by query parameters. Returns a paginated JSON array of Change Events. Use page and per_page to control pagination; the response includes pagination metadata. Required parameters: project_id. Procore API (v1.1): Construction Financials > Change Events. Endpoint: GET /rest/v1.1/change_events

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesQuery string parameter — unique identifier for the project.
pageNoQuery string parameter — page number for paginated results (default: 1)
per_pageNoQuery string parameter — number of items per page (default: 100, max: 100)
filters__created_atNoQuery string parameter — return item(s) created within the specified ISO 8601 datetime range. Formats: `YYYY-MM-DD`...`YYYY-MM-DD` - Date `YYYY-MM-DDTHH:MM:SSZ`...`YYYY-MM-DDTHH:MM:SSZ` - DateTime with UTC Offset `YYYY-MM-...
filters__updated_atNoQuery string parameter — return item(s) last updated within the specified ISO 8601 datetime range. Formats: `YYYY-MM-DD`...`YYYY-MM-DD` - Date `YYYY-MM-DDTHH:MM:SSZ`...`YYYY-MM-DDTHH:MM:SSZ` - DateTime with UTC Offset `YYY...
filters__include_deletedNoQuery string parameter — use 'only' to return only deleted resources. Use 'with' to return deleted and undeleted resources.
budget_changeNoJSON request body field — return Change Events with or without Change Items with the specified Budget Change
budget_days_in_stageNoJSON request body field — return Change Events with Change Items having the specified budget days in stage
budget_stage_statusNoJSON request body field — return Change Events with Change Items having Budget Stage with the specified status
budget_stageNoJSON request body field — return Change Events with Change Items having Budget Stage with the specified stage
budget_codeNoJSON request body field — return Change Events with or without Change Items with the specified Budget Code
change_event_line_itemNoJSON request body field — change_event_line_item
change_reasonNoJSON request body field — return Change Events with the specified Change Reason, or Change Events that do not have the specified Change Reason, based on the operator used
change_typeNoJSON request body field — return Change Events with the specified Change Type, or Change Events that do not have the specified Change Type, based on the operator used.
commitment_statusNoJSON request body field — return Change Events with Change Items having Commitment Contract or Commitment Change Order with the specified status
commitmentNoJSON request body field — return Change Events with or without Change Items associated with a Commitment or Commitment Change Orders
custom_field_idNoJSON request body field — return Change Events with custom fields that match the specified custom field values
created_atNoJSON request body field — change Events created within the specified ISO 8601 datetime range. Formats: - `N_months` - Within N month, - `N_days` - Within N days, - `YYYY-MM-DD`...`YYYY-MM-DD` - Date, - `YYYY-MM-DDTHH:MM:SSZ...
cost_in_status_sinceNoJSON request body field — change Events with Change Items having cost entered status within the specified ISO 8601 datetime range. Formats: - `N_months` - Within N month, - `N_days` - Within N days, - `YYYY-MM-DD`...`YYYY-M...
revenue_in_status_sinceNoJSON request body field — change Events with Change Items having revenue entered status within the specified ISO 8601 datetime range. Formats: - `N_months` - Within N month, - `N_days` - Within N days, - `YYYY-MM-DD`...`YYY...
budget_in_status_sinceNoJSON request body field — change Events with Change Items having budget entered status within the specified ISO 8601 datetime range. Formats: - `N_months` - Within N month, - `N_days` - Within N days, - `YYYY-MM-DD`...`YYYY...
created_byNoJSON request body field — return Change Events created by the specified User
commitment_titleNoJSON request body field — return Change Events with Change Items having Commitment or Commitment Change Orders with the specified title
contractNoJSON request body field — return Change Events with Change Items having Commitment or Commitment Change Orders with the specified Contract
cost_days_in_stageNoJSON request body field — return Change Events with Change Items having the specified cost days in stage
cost_rom_amountNoJSON request body field — return Change Events with Change Items having the specified cost rom amount
latest_cost_amount_project_currencyNoJSON request body field — return Change Events with Change Items having the specified latest cost amount in project currency
latest_revenue_amount_project_currencyNoJSON request body field — return Change Events with Change Items having the specified latest revenue amount in project currency
latest_budget_impact_project_currencyNoJSON request body field — return Change Events with Change Items having the specified latest budget impact in project currency
revenue_unit_cost_project_currencyNoJSON request body field — return Change Events with Change Items having the specified revenue unit cost in project currency
Behavior4/5

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the response is a paginated JSON array with pagination metadata, which is beyond what annotations convey. No contradiction.

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 three sentences, front-loaded with purpose and usage. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 30 parameters, nested objects, and no output schema, the description is minimal. It covers pagination and required parameters but does not explain filter parameters or response structure in detail. Adequate but not comprehensive.

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?

Schema coverage is 100%, so baseline is 3. The description mentions page/per_page for pagination and project_id as required, but schema descriptions already cover those. No additional meaning added for other parameters.

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 tool lists Change Events with paginated overview, ID finding, and filtering. The verb 'list' and resource 'Change Events' are explicit. Sibling tools (e.g., create_change_event, list_change_event_production_quantities) are distinct resources, so no confusion.

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 specifies when to use the tool: for paginated overview, finding IDs, or filtering. It does not explicit state when not to use or mention alternatives, but the context is clear enough for an agent.

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