Skip to main content
Glama
TylerIlunga

Procore MCP Server

Create Field Rule (Project Scope)

create_field_rule_project_scope

Create a project-scoped field defaults rule to override the company's field configuration for that project. Define the field's value and editability, with unique scope among active rules.

Instructions

Creates a project-scoped FIELD_DEFAULTS rule. The rule fully overrides the company configuration for its field at this project (value + editability). The asset type must be visible at the project, and the (asset type, fieldset, trigger field) scope must be unique among the project's active rules. company_id and project_id default to the values set by procore_set_config when omitted. Creates the field rule 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, project_id, trigger_field, definition. Procore API (v2.0): Core > Assets. Endpoint: POST /rest/v2.0/companies/{company_id}/projects/{project_id}/assets/settings/field_rules/create

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rule_nameNoJSON request body field — display name for the rule. Optional: when omitted or blank, the backend auto-generates a scope-indicative name of the form '{rule_type}::{company_id}::{asset_type_id|NA}::{fieldset_id|NA}::{trigger...
rule_typeNoJSON request body field — rule type. Defaults to NAMING for backward compatibility.
company_idYesURL path parameter — unique identifier for the company.
definitionYesJSON request body field — structured rule definition. Shape depends on ruleType: FieldRuleDefinitionDTO for NAMING, FieldDefaultsDefinitionDTO for FIELD_DEFAULTS.
project_idYesURL path parameter — unique identifier for the project.
descriptionNoJSON request body field — optional description
fieldset_idNoJSON request body field — fieldset id (required for FIELD_DEFAULTS). '-1' for Procore default fields; external configurable fieldset id for custom fields. Null for NAMING.
asset_type_idNoJSON request body field — asset type id (required for FIELD_DEFAULTS; null for NAMING).
trigger_fieldYesJSON request body field — trigger field. For NAMING: asset_code. For FIELD_DEFAULTS: the field this rule configures (e.g., custom_field_1234, trade_id).
Accept-LanguageNoJSON request body field — locale for localized response messages (for example: en, fr-FR, pseudo)
Behavior5/5

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

Annotations already declare write/non-idempotent/non-destructive, but the description adds crucial behavioral details: non-idempotency ('calling it again creates another record'), preconditions (asset type visible, unique scope), defaulting behavior for company_id/project_id, and expected error codes. These enrich beyond annotation flags.

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 well-structured: it opens with the core purpose, then constraints, defaults, response behavior, error handling, and endpoint info. No filler sentences; every sentence adds operational detail. Appropriate length for a complex create tool.

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?

Despite no output schema, the description covers success response (HTTP 201 with new id), failure modes (401/403/404), required parameters, and prerequisites (asset type visibility, unique scope). This gives the agent everything needed to invoke correctly and anticipate outcomes.

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 the schema carries the parameter descriptions. The description adds value by listing the four required parameters explicitly, explaining that company_id/project_id default to procore_set_config when omitted, and clarifying that trigger_field/definition are central to the rule's behavior. This exceeds the baseline for high schema coverage.

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+resource+scope: 'Creates a project-scoped FIELD_DEFAULTS rule.' It clearly distinguishes from company-scoped siblings by emphasizing project scope and explains the rule's behavior (overrides company configuration). This makes the tool's purpose 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?

It states the tool is for project-scoped rules and notes the rule fully overrides company config, implying when project-level granularity is needed. It doesn't explicitly compare to sibling create_field_rule or bulk_create_field_rules_project_scope, but the scope and uniqueness constraints provide clear context. A small deduction for not naming alternatives explicitly.

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