Skip to main content
Glama
TylerIlunga

Procore MCP Server

Execute Any Procore API Call

procore_api_call
Destructive

Execute any Procore REST API call directly. Resolve the endpoint details, provide the method, path, and parameters, then run GET, POST, PUT, PATCH, or DELETE operations, with real data changes—verify IDs before writing.

Instructions

Executes any Procore REST API call. This is the only tool here that reaches Procore and the only one that can change data — resolve the exact method, path, and parameters with procore_get_endpoint_details first. WRITES ARE REAL: DELETE permanently removes the record, POST creates one, and PATCH/PUT overwrite fields, so confirm the target id before calling and prefer a GET to verify it exists. Handles OAuth from the saved tokens, substitutes {placeholders} from path_params, and rewrites double underscores in query keys into brackets (filters__status becomes filters[status]). company_id and project_id fall back to whatever procore_set_config holds when the path needs them and you omit them. Returns the parsed JSON response together with pagination and rate-limit metadata. Failures come back as an error payload carrying the HTTP status — commonly 401 when the token has expired, 403 without tool permission, 404 when an id does not resolve, 422 when the body fails validation, and 429 when the rate limit is exhausted. Step 4 of the workflow; this reaches every Procore endpoint, including any not exposed as a dedicated tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoJSON request body for POST/PUT/PATCH. Use the exact field names and nesting from procore_get_endpoint_details; ignored on GET and DELETE.
pageNo1-indexed page number for paginated endpoints (default 1)
pathYesAPI path with placeholders left intact, e.g. '/rest/v1.0/projects/{project_id}/rfis'. Supply the values via path_params rather than interpolating them here.
methodYesHTTP method for the endpoint, exactly as reported by the discovery tools
per_pageNoItems per page, 1-100 (default 100)
company_idNoOverrides the Procore-Company-Id header for this call only; defaults to the configured company
path_paramsNoValues substituted into the path's {placeholders}, e.g. { project_id: '12345' }. Required whenever the path contains a placeholder that procore_set_config does not already supply.
query_paramsNoQuery-string parameters. Use double underscores for Procore's bracket syntax: filters__status becomes filters[status].

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changedv2.0.0
    • changedInput schema / properties / body / description
      Previous value: -"JSON request body for POST/PUT/PATCH calls"New value: +"JSON request body for POST/PUT/PATCH. Use the exact field names and nesting from procore_get_endpoint_details; ignored on GET and DELETE."
    • changedInput schema / properties / company_id / description
      Previous value: -"Override the default Procore-Company-Id header"New value: +"Overrides the Procore-Company-Id header for this call only; defaults to the configured company"
    • changedInput schema / properties / method / description
      Previous value: -"HTTP method"New value: +"HTTP method for the endpoint, exactly as reported by the discovery tools"
    • changedInput schema / properties / page / description
      Previous value: -"Page number for paginated endpoints"New value: +"1-indexed page number for paginated endpoints (default 1)"
    • changedInput schema / properties / path / description
      Previous value: -"API path with placeholders, e.g. /rest/v1.0/projects/{project_id}/rfis"New value: +"API path with placeholders left intact, e.g. '/rest/v1.0/projects/{project_id}/rfis'. Supply the values via path_params rather than interpolating them here."
    • changedInput schema / properties / path_params / description
      Previous value: -"Substitutions for path placeholders, e.g. { project_id: '12345' }"New value: +"Values substituted into the path's {placeholders}, e.g. { project_id: '12345' }. Required whenever the path contains a placeholder that procore_set_config does not already supply."
    • changedInput schema / properties / per_page / description
      Previous value: -"Items per page (max 100)"New value: +"Items per page, 1-100 (default 100)"
    • changedInput schema / properties / query_params / description
      Previous value: -"Query parameters. Use double underscores for nested brackets: filters__status becomes filters[status]"New value: +"Query-string parameters. Use double underscores for Procore's bracket syntax: filters__status becomes filters[status]."
  2. Changed4 schema fields changedv1.1.0
    • changedInput schema / properties / body / description
      Previous value: -"Request body for POST/PUT/PATCH requests"New value: +"JSON request body for POST/PUT/PATCH calls"
    • changedInput schema / properties / path_params / description
      Previous value: -"Path parameter substitutions, e.g. { project_id: '12345' }"New value: +"Substitutions for path placeholders, e.g. { project_id: '12345' }"
    • changedInput schema / properties / per_page / description
      Previous value: -"Items per page, max 100"New value: +"Items per page (max 100)"
    • changedInput schema / properties / query_params / description
      Previous value: -"Query parameters. Use __ for nested brackets, e.g. filters__status becomes filters[status]"New value: +"Query parameters. Use double underscores for nested brackets: filters__status becomes filters[status]"
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description adds far richer detail: exactly what each method does ('DELETE permanently removes the record, POST creates one, PATCH/PUT overwrite fields'), OAuth handling, placeholder substitution, and a full error taxonomy (401/403/404/422/429). No contradiction with annotations; description goes well beyond the structured fields.

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?

Front-loaded with the core purpose and mutation warning, then efficiently covers conventions, return format, and error codes. Every sentence carries information; for a generic executor of this complexity the length is justified, though it edges toward dense and could be slightly tightened.

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?

With no output schema and 8 parameters, the description carries full burden and delivers: return format ('parsed JSON response together with pagination and rate-limit metadata'), failure payload semantics with HTTP status explanations, destructive consequences, and fallback behavior. Highly complete for a complex generic tool.

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 baseline is 3, but the description adds genuine extra semantics: explains the double-underscore-to-bracket rewrite (filters__status becomes filters[status]), how {placeholders} get substituted from path_params, and the company_id/project_id fallback to procore_set_config. These conventions are not in the schema and materially help correct invocation.

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?

States the specific verb+resource: 'Executes any Procore REST API call' with a clear scope ('the only tool here that reaches Procore'). Strongly distinguishes from siblings by noting it is the only data-mutating tool and that it reaches endpoints 'not exposed as a dedicated tool.'

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

Usage Guidelines5/5

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

Explicitly directs the agent to 'resolve the exact method, path, and parameters with procore_get_endpoint_details first' and gives concrete when-to-use guidance: prefers a GET to verify the target id exists before destructive calls. Names the workflow position ('Step 4') and alternative tool, making selection unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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