Skip to main content
Glama
TylerIlunga

Procore MCP Server

Update A Person

update_a_person

Update an existing person's details in Procore by providing company ID and person ID. Modify contact, employment, and personal information, then receive the updated person record.

Instructions

Updates a Person for a given company and person ID. company_id defaults to the value set by procore_set_config when omitted, and person_id must identify an existing parent record — resolve it with the matching list tool first. Applies the change and returns the updated person. 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: company_id, person_id. Procore API: Resource Management > Resource Planning. Endpoint: POST /rest/v1.0/workforce-planning/v2/companies/{company_id}/people/{person_id}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dobNoJSON request body field — date of birth of the Person. Accepts ISO Date String, UTC Date String, or MS Numeric Epoch Time.
emailNoJSON request body field — the email that the Person will log in with. **Required if updating `is_user` to `true`**. Must be unique across the company.
phoneNoJSON request body field — the Person's phone number, including country and area code. Must be **unique** among all registered People.
statusNoJSON request body field — the status of the Person. `active` means the person is visible in all pages, while `inactive` hides the person unless filtered. Inactive People do not count against billing plans.
countryNoJSON request body field — the country where the Person is located.
is_maleNoJSON request body field — specifies if the Person identifies as male.
zipcodeNoJSON request body field — the postal/zip code of the Person.
languageNoJSON request body field — language preference. Currently only `english` is supported.
address_1NoJSON request body field — first part of the Person's address.
address_2NoJSON request body field — second part of the Person's address (e.g., Apartment, Suite, Unit).
city_townNoJSON request body field — the city or town where the Person is located.
group_idsNoJSON request body field — array of UUIDs representing the Groups this Person belongs to. **Cannot be empty** for an assignable resource or a non-admin Person.
last_nameNoJSON request body field — last Name of the Person.
person_idYesURL path parameter — unique identifier for the person
company_idYesURL path parameter — unique identifier for the company. This parameter accepts both formats: - **Recommended**: Procore company ID (integer) - Use this for new integrations - Legacy: LaborChart UUID format (uuid string...
first_nameNoJSON request body field — first Name of the Person.
hired_dateNoJSON request body field — date the Person was hired. Accepts ISO Date String, UTC Date String, or MS Numeric Epoch Time.
hourly_wageNoJSON request body field — hourly wage rate for the Person. Used for automatic spend tracking.
job_title_idNoJSON request body field — uUID reference to a Job Title in the LaborChart System.
is_assignableNoJSON request body field — determines if the Person can be assigned to tasks.
state_provinceNoJSON request body field — the state or province where the Person is located.
can_receive_smsNoJSON request body field — determines if the Person can receive SMS notifications.
employee_numberNoJSON request body field — internal employee identifier.
can_receive_emailNoJSON request body field — determines if the Person can receive email notifications.
can_receive_mobileNoJSON request body field — determines if the Person can receive mobile push notifications if they have the app installed.
permission_level_idNoJSON request body field — uUID of the Permission Level assigned to the Person. **Required when setting `is_user: true`**.
emergency_contact_nameNoJSON request body field — name of the Person's emergency contact.
emergency_contact_emailNoJSON request body field — email address of the emergency contact.
notification_profile_idNoJSON request body field — uUID of the Notification Profile for the user.
emergency_contact_numberNoJSON request body field — phone number of the emergency contact.
emergency_contact_relationNoJSON request body field — the relationship between the Person and their emergency contact.
Behavior4/5

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

Beyond the annotations (which already indicate this is a mutating, non-destructive operation), the description discloses that the tool 'returns the updated person' and details failure modes with HTTP statuses: '401 when the token has expired, 403 without tool permission, and 404 when an id does not resolve.' It does not cover partial-update semantics or reversibility, but the added error context is valuable.

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 compact paragraph covering action, defaults, prerequisite, return, error handling, required parameters, and endpoint. It is not overly verbose for the amount of information conveyed, and each sentence adds distinct value. A slight structural improvement would be separating the endpoint line, but it is still appropriately concise.

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 tool has 31 parameters, a complete schema, and no output schema, the description covers the key contextual aspects: return value, error cases, prerequisites, parameter defaults, and the specific API endpoint. It does not explicitly state whether omitted body fields are left unchanged (partial update vs full replace), which is a minor completeness gap for an update 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% (every parameter has a description), so the baseline is 3. The description adds extra meaning for the required parameters: company_id 'defaults to the value set by procore_set_config when omitted' and person_id 'must identify an existing parent record — resolve it with the matching list tool first.' This is meaningful context not present in 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 opens with 'Updates a Person for a given company and person ID,' which is a specific verb-resource pair with clear scoping. It distinguishes from sibling tools like create_a_person, delete_a_person, and list_people by using the verb 'Updates' and identifying the two required identifiers, making the tool's function unambiguous.

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 a clear prerequisite: 'person_id must identify an existing parent record — resolve it with the matching list tool first.' It also explains the company_id default behavior via procore_set_config when omitted. However, it does not name alternative tools or explicitly state when not to use this tool, so it stops short of full exclusionary 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