Skip to main content
Glama
TylerIlunga

Procore MCP Server

Update Company Person

update_company_person
Idempotent

Update a company person's details in Procore by sending only the fields to change. Returns the modified company person record.

Instructions

Update the specified Company Person. 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 "person" in the request payload for you. company_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 company person 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: company_id, id, last_name. Procore API: Core > Directory. Endpoint: PATCH /rest/v1.0/companies/{company_id}/people/{id}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesURL path parameter — unique identifier of the Directory resource
viewNoQuery string parameter — specifies which view of the resource to return (which attributes should be present in the response). If a valid view is not provided, it will default to normal.
activeNoJSON request body field — the active status of the Company Person
job_titleNoJSON request body field — the Job Title of the Company Person
last_nameYesJSON request body field — the Last Name of the Company Person
origin_idNoJSON request body field — the Origin ID of the Company User
company_idYesURL path parameter — unique identifier for the Procore company
first_nameNoJSON request body field — the First Name of the Company Person
employee_idNoJSON request body field — the Employee ID of the Company Person
is_employeeNoJSON request body field — the Employee status of the Company Person
work_classification_idNoJSON request body field — the unique identifier for the work classification of the Company Person.
Behavior5/5

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

The description adds rich behavioral context beyond the annotations: omitted fields keep current values, company_id defaults from procore_set_config, error payloads with common HTTP statuses, and return value. It does not contradict the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) and instead reinforces them with concrete implementation details.

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 dense but every sentence serves a purpose: purpose, partial-update behavior, payload transformation, defaults, prerequisite, return value, error handling, required parameters, and API reference. It is front-loaded with the verb and resource, making it easy to scan.

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 an update tool with 11 parameters and no output schema, the description covers all essential aspects: what it does, how to invoke correctly, error scenarios, and return value. It even specifies the common HTTP error codes, which is highly useful for an agent. The 100% schema coverage handles parameter details, so the description is appropriately complete.

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 baseline is 3. The description adds valuable semantic details: fields are nested under 'person' in the payload, company_id defaults when omitted, and id must reference an existing parent record. These details clarify usage beyond the raw schema property descriptions.

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 starts with a clear verb+resource: 'Update the specified Company Person.' It distinguishes this from sibling tools like create_company_person and update_company_user by specifying the exact resource and operation. The scope is unambiguous, especially with the explicit endpoint and API reference.

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: partial-update semantics ('send only the fields you intend to change'), defaulting of company_id, and a prerequisite to resolve id with the matching list tool. It does not explicitly contrast with alternative update tools, but the resource name and instructions make the appropriate use case clear.

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