Skip to main content
Glama
TylerIlunga

Procore MCP Server

Create Commitment Contract Line Item

create_commitment_contract_line_item

Add a line item to an existing commitment contract in Procore. Requires company, project, contract IDs, and a WBS code.

Instructions

Creates a line item for a given commitment contract. Use this to create a new Commitments in Procore. Creates a new Commitments and returns the created object on success (HTTP 201). Required parameters: company_id, project_id, commitment_contract_id, wbs_code_id. Procore API (v2.0): Construction Financials > Commitments. Endpoint: POST /rest/v2.0/companies/{company_id}/projects/{project_id}/commitment_contracts/{commitment_contract_id}/line_items

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
company_idYesURL path parameter — unique identifier for the company.
project_idYesURL path parameter — unique identifier for the project.
commitment_contract_idYesURL path parameter — unique identifier for the Commitment Contract.
prime_line_item_idNoJSON request body field — iD of the prime contract line item associated with this line item
amountNoJSON request body field — amount - this field is nullable on unit quantity SOVs but NOT amount-based SOVs. For line item creates, if this field is omitted on unit quantity SOVs, the amount will be calculated as quantity * ...
descriptionNoJSON request body field — the description for this Commitments operation
quantityNoJSON request body field — quantity - only accepted on unit quantity SOVs
unit_costNoJSON request body field — unit cost - only accepted on unit quantity SOVs
uomNoJSON request body field — unit of measure - only accepted on unit quantity SOVs
wbs_code_idYesJSON request body field — unique identifier of the wbs code
tax_code_idNoJSON request body field — unique identifier of the tax code
Behavior4/5

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

Annotations already indicate non-readonly and non-destructive for a create operation. Description adds value by specifying the response 'returns the created object on success (HTTP 201)' and providing the endpoint path and API version, which aids in understanding the operation's behavior.

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 reasonably concise, starting with purpose followed by use indication, required parameters, and API details. Each sentence contributes information without redundancy. Could be slightly more structured but is efficient.

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 the no output schema and high schema coverage, the description covers the main purpose, required parameters, and endpoint. It does not explain the return object structure beyond 'the created object', but overall it is sufficient for a create tool with a detailed schema.

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%, and the schema descriptions are detailed (e.g., amount field's behavior on SOV types). The description lists required parameters but adds no new semantic meaning beyond what is in the schema. Baseline of 3 is appropriate as the schema carries the heavy lifting.

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?

Description clearly states 'Creates a line item for a given commitment contract' and specifies the action of creating a new Commitments in Procore. It distinguishes from the sibling tool 'create_commitment_contract' by focusing on line items. The list of required parameters further clarifies the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by stating 'Use this to create a new Commitments' but does not explicitly provide when-to-use vs alternatives or when-not-to-use. Among siblings like 'create_commitment_contract' and many other create tools, no exclusion guidance is given.

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