Lists Procore's API surface as a Category > Module tree with an endpoint count for each. Start here when you do not yet know which part of Procore holds the data you need; if you already know the resource by name ('RFI', 'budget'), procore_search_endpoints gets you there in one step instead of three. The category and module names returned are the exact values procore_discover_endpoints expects. Takes no arguments and returns a JSON object. Reads the catalog bundled with this server, so it makes no Procore request and needs no authentication — it cannot fail with 401/403 and costs no rate limit. Step 1 of the discover -> detail -> call workflow.

Lists the Procore endpoints inside one category or module, optionally narrowed by a summary substring or HTTP method. Use it after procore_discover_categories to enumerate a focused area; prefer procore_search_endpoints when you have a keyword but no category. Every argument is optional, but omitting all of them returns the entire ~3,100-endpoint catalog, so pass at least a category or a search term. Returns a JSON array of {operationId, summary, method, path}; feed an operationId to procore_get_endpoint_details. Filters that match nothing return an empty array, not an error. Reads the bundled catalog: no Procore request, no authentication, no rate-limit cost. Step 2 of the workflow.

Returns the complete parameter schema for one Procore endpoint: every path, query, and body field with its type and required flag, plus the response shape. Call this after discovery and before procore_api_call — api_call needs exact parameter names, and guessing them is the most common cause of a rejected request. Takes the operationId string that procore_discover_endpoints and procore_search_endpoints return; an unrecognized operation_id comes back as a not-found message rather than an error. Reads the bundled catalog: no Procore request, no authentication, no rate-limit cost. Step 3 of the workflow.

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.

Searches every Procore endpoint's summary, tag, and path for a term and returns the matches ranked by relevance. This is the fastest way in when you already know roughly what you want ('punch list', 'submittal', 'budget line item'); reach for procore_discover_categories instead when you want to browse the API surface rather than search it. Returns a JSON array of {operationId, summary, method, path}; feed an operationId to procore_get_endpoint_details to get its parameters. A term with no matches returns an empty array, so retry with a broader or singular form before concluding the endpoint does not exist. Reads the bundled catalog: no Procore request, no authentication, no rate-limit cost.

Reports this server's current state: whether Procore OAuth tokens are present and still valid, the default company_id, and the active project_id that procore_api_call substitutes when you omit those parameters. Check this first when a call fails with 401 or 403, or to confirm which project subsequent calls will target before running a write. Never returns token values or the client secret — only whether credentials are present. Takes no arguments and returns a JSON object. Reads local process state, so it makes no Procore request. Pair with procore_set_config to change any of it.

Sets the default company_id or project_id that later procore_api_call requests use when the path needs one and you omit it. Use it to switch project context mid-session instead of restarting the server, then call procore_get_config to confirm what took effect. Only 'company_id' and 'project_id' are accepted; both are coerced to integers, and a non-numeric value is reported back as a message rather than stored. The change lives in memory for this server process only — it is never written to disk and is lost on restart. Setting the same value twice is a no-op, and nothing in Procore is modified: this only changes which ids this server fills in for you. Returns a confirmation plus the full updated configuration.