Skip to main content
Glama
TylerIlunga

Procore MCP Server

Create Custom Field Definitions

create_custom_field_definitions

Create a custom field definition in Procore by providing company ID, label, and data type. Returns the new definition's ID for use in creating custom field LOV entries.

Instructions

Creates a Custom Field Definition. The ID returned is then used as a path parameter (custom_field_definition_id) on the Create Custom LOV Entries endpoint. Pass the record's fields as top-level arguments — they are nested under "custom_field_definition" in the request payload for you. company_id defaults to the value set by procore_set_config when omitted. Creates the custom field definition and returns it with its new id (HTTP 201); calling it again creates another record. 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, label, data_type. Procore API (v2.0): Company Admin > Custom - Configurable Tools. Endpoint: POST /rest/v2.0/companies/{company_id}/custom_field_definitions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoQuery string parameter — controls which fields are returned for each Custom Field Definition. 'with_configurable_field_sets' additionally includes the configurable_field_sets array listing the field sets that use the defin...
labelYesJSON request body field — the label for this Custom - Configurable Tools operation
activeNoJSON request body field — whether the custom field is active or not.
variantNoJSON request body field — the variant of the Custom Field. The supported variants is dependent on the data_type.
data_typeYesJSON request body field — type of Custom field
company_idYesURL path parameter — unique identifier for the company.
descriptionNoJSON request body field — the description for this Custom - Configurable Tools operation
default_valueNoJSON request body field — the default value for the Custom Field. Only accepted for read_only rich_text fields.
custom_field_lov_entriesNoJSON request body field — list-of-value entries (selectable options) for the Custom Field. Only applicable to lov_entry and lov_entries data types.
Behavior5/5

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

Explicitly notes 'calling it again creates another record,' reinforcing non-idempotence beyond the idempotentHint=false annotation. Adds practical behavior: company_id defaults to the value from procore_set_config, top-level arguments are nested under custom_field_definition, and common HTTP error statuses. Does not contradict any annotations.

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?

Description is information-dense but each sentence adds value: purpose, LOV linkage, payload handling, defaults, idempotence, error codes, and endpoint. No filler or repetition of schema details. Slightly long but well-structured for a complex creation tool.

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 9 parameters and no output schema, the description covers the essential usage contract: creation, return id, HTTP 201, default company_id, and error statuses. It omits explicit differentiation from create_custom_field and the full return body shape, but the schema covers field semantics, making this reasonably 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 already covers all 9 parameters with descriptions, providing a high baseline. The description adds value by explaining company_id defaults, the top-level argument nesting under custom_field_definition, and the relationship to LOV entries. This extra guidance justifies a 4.

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?

Clearly states 'Creates a Custom Field Definition' with a specific verb and resource. Differentiates from sibling create_custom_field by naming the definition object and linking to the LOV entries endpoint. Includes endpoint and admin context, leaving no ambiguity about what the tool does.

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?

Mentions that the returned ID is used for the Create Custom LOV Entries endpoint, implying this is a prerequisite for that workflow. States default company_id behavior and common error conditions. Does not explicitly exclude alternatives or state when not to use, so it stops short of a 5.

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