Skip to main content
Glama
TylerIlunga

Procore MCP Server

Update Specification Section Divisions

update_specification_section_divisions
Idempotent

Bulk creates, updates, or deletes specification section divisions for a Procore project. Send only fields to change; omitted fields keep current values.

Instructions

Bulk creates, updates, and deletes Specification Section Divisions for a Project. Send only the fields you intend to change; omitted fields keep their current values. company_id and project_id default to the values set by procore_set_config when omitted. Returns the modified specification section division 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, project_id. Procore API (v2.1): Project Management > Specifications. Endpoint: PATCH /rest/v2.1/companies/{company_id}/projects/{project_id}/specification_section_divisions

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
company_idYesURL path parameter — unique identifier for the company.
project_idYesURL path parameter — unique identifier for the project.
creation_paramsNoJSON request body field — the creation params for this Specifications operation
deletion_paramsNoJSON request body field — the deletion params for this Specifications operation
updation_paramsNoJSON request body field — the updation params for this Specifications operation
Behavior1/5

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

The description explicitly states the tool 'deletes' Specification Section Divisions, while the annotations set destructiveHint=false. This is a direct contradiction: deletion is a destructive action. No qualifier (e.g., soft delete) is provided to reconcile this.

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 dense but well-structured: purpose, usage, defaults, return, errors, required params, and API reference. No filler, though it could be trimmed; still, every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, and the description gives only a vague return statement ('Returns the modified specification section division'), which is ambiguous for a bulk operation. It also omits the shape of the array items and batch behavior, leaving significant gaps for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all five parameters. The description adds the partial-update behavior but doesn't explain the internal structure of creation_params, deletion_params, or updation_params, which remain opaque (items: {}).

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 begins with a specific verb-resource statement: 'Bulk creates, updates, and deletes Specification Section Divisions for a Project.' This clearly identifies the operation type (bulk mutation) and resource, and distinguishes it from sibling list/create tools.

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 actionable context: partial update semantics ('Send only the fields you intend to change; omitted fields keep their current values'), defaulting behavior for company_id/project_id, and required parameters. It doesn't explicitly name alternatives or exclusions, so not 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