Skip to main content
Glama
TylerIlunga

Procore MCP Server

Sync Company Vendors

sync_company_vendors
Idempotent

Batch create or update company vendors in Procore with one sync call. Omit fields to keep current values, and update up to 1000 vendors per request.

Instructions

Creates or updates a batch of Company Vendors. See Using Sync Actions for additional information. #### Country and State codes The country_code and state_code parameter values must conform to the ISO-3166 Alpha-2 specification. See Working with Country Codes for additional information. #### Documentation The purpose of this API is to allow one or more vendors to be created or updated. The caller provides an array of hashes, each hash containing the attributes for a single vendor. The attribute names in each hash match those used by the Create and Update Company Vendors APIs. Attributes for a maximum of 1000 vendors may be passed with each call. The API will always return an HTTP status of 200. Send only the fields you intend to change; omitted fields keep their current values. Returns the modified company vendor 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, updates. Procore API: Core > Directory. Endpoint: PATCH /rest/v1.0/vendors/sync

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
updatesYesJSON request body field — the updates for this Directory operation
company_idYesJSON request body field — unique identifier for the Procore company
run_configurable_validationsNoQuery string parameter — if true, validations are run for the corresponding Configurable Field Set.
Behavior5/5

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

Annotations already indicate non-read-only, idempotent, and non-destructive behavior. The description adds crucial detail: 'The API will always return an HTTP status of 200' with failures as error payloads, partial-update semantics ('Send only the fields you intend to change'), the 1000-vendor limit, and ISO-3166 code constraints. These are not in annotations, so the description significantly enriches transparency.

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 long but well-structured with headers and front-loaded purpose. It includes documentation links, endpoint info, and detailed behavior. Every section is relevant, though 'The purpose of this API is...' repeats the opening sentence, so it could be slightly trimmed.

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?

With no output schema, the description covers return behavior: 'Returns the modified company vendor on success' and failure modes with status codes (401, 403, 404). It explains request format, constraints, and points to additional docs. This is highly complete for a complex sync API.

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%, but the descriptions are terse. The description clarifies the `updates` parameter structure: 'an array of hashes, each hash containing the attributes for a single vendor' and that attribute names match the Create/Update APIs. It also adds the ISO-3166 constraint on country/state codes and identifies required parameters company_id and updates, adding meaning beyond 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 a specific verb and resource: 'Creates or updates a batch of Company Vendors.' It further clarifies the purpose: 'allow one or more vendors to be created or updated,' distinguishing it from individual create/update tools like create_company_vendor and update_company_vendor. The endpoint and API scope (Core > Directory) reinforce specificity.

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?

It states the use case for batch operations (one or more vendors) and mentions the 1000-vendor maximum, giving clear context. However, it does not explicitly name alternatives like create_company_vendor or update_company_vendor for single-record cases, so exclusion guidance is missing.

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