Skip to main content
Glama
TylerIlunga

Procore MCP Server

List Company Project Status Snapshots

list_company_project_status_snapshots
Read-onlyIdempotent

Retrieve a paginated list of company-level project status snapshots from Procore Budget views, with filtering by project, status, program, and more, and sorted by creation date.

Instructions

Returns a paginated list of company-level Project Status snapshots with optional filtering and sorting. Use this to enumerate Budget records when you need a paginated overview, to find IDs, or to filter by query parameters. Returns a paginated JSON array of Budget records. Use page and per_page to control pagination; the response includes pagination metadata. Required parameters: company_id, budget_view_id. Procore API (v2.0): Construction Financials > Budget. Endpoint: GET /rest/v2.0/companies/{company_id}/budget_views/{budget_view_id}/project_status_snapshots

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
company_idYesURL path parameter — unique identifier for the company.
budget_view_idYesURL path parameter — iD of the budget view
filters__status_idNoQuery string parameter — filter snapshots by PSS custom status ID
filters__project_idNoQuery string parameter — filter snapshots by project ID
filters__program_idNoQuery string parameter — filter snapshots by program ID
filters__region_idNoQuery string parameter — filter snapshots by region ID
filters__stage_idNoQuery string parameter — filter snapshots by stage ID
filters__office_idNoQuery string parameter — filter snapshots by office ID
filters__department_idNoQuery string parameter — filter snapshots by department ID
filters__created_by_idNoQuery string parameter — filter snapshots by created_by_id
filters__created_atNoQuery string parameter — filter snapshots by created_at date range, inclusive
sortNoQuery string parameter — sort order for results. Prefix with '-' for descending order
pageNoQuery string parameter — page number for paginated results (default: 1)
per_pageNoQuery string parameter — number of items per page (default: 100, max: 100)
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral context: pagination with metadata, filtering, sorting, and required parameters. No contradictions and useful additional information beyond annotations.

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 well-structured and front-loaded with the core purpose. It contains multiple sentences but avoids unnecessary verbosity. Some repetition ('paginated', 'Budget records') could be trimmed, but overall it's 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 14 parameters and no output schema, the description provides a solid overview: purpose, filtering/sorting capabilities, pagination control, required parameters, and API endpoint. It covers the essential information for an agent to use the tool correctly, though response structure details are omitted.

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?

Input schema has 100% coverage with descriptions for all 14 parameters. The description only reiterates pagination and required parameters without adding new semantic meaning. Baseline is 3 due to high schema coverage, and no extra value is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns a paginated list of company-level Project Status snapshots with filtering and sorting. It specifies the resource and scope ('company-level'), differentiating it from project-level siblings implicitly. However, it does not explicitly contrast with the sibling tool 'list_project_status_snapshots', which could reduce clarity for an agent.

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 provides usage context (enumerate Budget records, find IDs, filter) but does not specify when not to use this tool or mention alternative tools like the project-level version. This leaves ambiguity about choosing between sibling tools.

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