Skip to main content
Glama
TylerIlunga

Procore MCP Server

Update Requisition Compliance Document

update_requisition_compliance_document

Update a compliance document on a Procore Pay invoice to change its status, reviewer notes, attached files, or effective/expiration dates.

Instructions

Updates the requisition compliance document Procore Pay must be enabled to use this endpoint.. Use this to update an existing Payments (only the supplied fields are changed). Updates the specified Payments and returns the modified object on success. Required parameters: company_id, project_id, invoice_id, document_id. Procore API (v2.0): Construction Financials > Payments. Endpoint: PATCH /rest/v2.0/companies/{company_id}/projects/{project_id}/compliance/invoices/{invoice_id}/documents/{document_id}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
company_idYesURL path parameter — unique identifier for the Procore company
project_idYesURL path parameter — unique identifier for the Procore project
invoice_idYesURL path parameter — iD of the SC Invoice
document_idYesURL path parameter — iD of the compliance document
statusNoJSON request body field — status of the compliance document
reviewer_notesNoJSON request body field — notes from the reviewer
prostore_file_idsNoJSON request body field — array of Procore file IDs
effective_atNoJSON request body field — effective date of the compliance document
expires_atNoJSON request body field — expiration date of the compliance document
Behavior3/5

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

The description includes API details and notes that the tool returns the modified object on success. However, it confusingly mentions 'Updates the specified Payments' which contradicts the tool's focus on compliance documents. Annotations provide no direct contradiction, but the description's accuracy is compromised.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat cluttered with redundant references to 'Payments' and includes API endpoint info that could be separated. It is not maximally concise and could be better structured.

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?

The description covers required parameters, precondition, and return value. However, it lacks details on error conditions, authentication, or rate limits. Given the tool's complexity and absence of output schema, the description provides adequate but not complete context.

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% with clear parameter descriptions. The description adds no extra meaning beyond listing a few optional fields and required parameters. The schema already handles parameter semantics adequately.

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 clearly states the tool updates a requisition compliance document, with specific verb and resource. The tool name and description align, and it is distinct from siblings by focusing on this specific document type.

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 a precondition: 'Procore Pay must be enabled to use this endpoint.' It also lists required parameters and indicates that only supplied fields are changed. However, it does not explicitly state when to use this tool versus alternatives, though no direct sibling alternative exists.

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