Skip to main content
Glama
TylerIlunga

Procore MCP Server

List Budget View Detail Rows

list_budget_view_detail_rows
Read-onlyIdempotent

Retrieve paginated budget view detail rows for a project, filtering by cost code, biller, or category. Use to enumerate budget records or find IDs.

Instructions

Return a list of all Budget View Detail Rows for a project and budget view. Note: In addition to all the fields outlined in the response, there will be an additional key for each visible source and formula column created for the particular budget view. As well, when using a Forecasting View ID, additional keys will be visible that give calculated forecasts for each month, as defined by the Advanced Forecasting Tool. 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: budget_view_id, project_id. Procore API: Construction Financials > Budget. Endpoint: GET /rest/v1.0/budget_views/{budget_view_id}/detail_rows

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
budget_view_idYesURL path parameter — unique identifier of the budget view
project_idYesQuery string parameter — unique identifier for the project.
pageNoQuery string parameter — page number for paginated results (default: 1)
per_pageNoQuery string parameter — number of items per page (default: 100, max: 100)
biller__NoQuery string parameter — return item(s) within a specific biller. Format is biller[]=id=1,type=SubJob or biller[]=id=1,type=Project
cost_code_id__NoQuery string parameter — return item(s) within a specific Cost Code id or range of Cost Code IDs
cost_code_name__NoQuery string parameter — return item(s) within a specific Cost Code name or range of Cost Code names
root_cost_code_id__NoQuery string parameter — return item(s) within a specific Root Cost Code id or range of Root Cost Code IDs
root_cost_code_name__NoQuery string parameter — return item(s) within a specific Root Cost Code name or range of Root Cost Code names
category_id__NoQuery string parameter — return item(s) within a specific category id (line item type id) or range of category IDs
budget_line_item_id__NoQuery string parameter — return item(s) within a specific budget line item id or range of budget line item IDs
sortNoQuery string parameter — return item(s) with the specified sort. Default is biller_type,biller,root_cost_code,cost_code,category_id
budget_row_typeNoQuery string parameter — return budgeted, unbudgeted or all item(s) from all budget rows for a project. Default is budgeted. Note that when the unbudgeted or all values are supplied, the id field will be null for rows that...
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds context about the response structure (additional keys for visible source and formula columns, and forecasting calculations), pagination metadata, and required parameters. This adds value beyond the 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 three sentences plus brief additional lines. It is fairly concise and front-loaded with the core purpose. The inclusion of Procore API details (e.g., 'Procore API: Construction Financials > Budget. Endpoint: GET /rest/v1.0/budget_views/{budget_view_id}/detail_rows') is helpful context but could be considered slightly extraneous.

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 tool's complexity (13 parameters, pagination, filtering, dynamic response columns), the description covers the main use cases, response structure, and key behavior. It mentions pagination controls and additional keys for visible columns and forecasting. However, it could provide more details on filtering parameters or the exact response format, but the input schema and no output schema limits completeness requirement.

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?

The input schema covers all 13 parameters with descriptions (100% coverage). The description mentions required parameters and pagination controls but does not add significant meaning beyond what the schema already provides. Therefore, a score of 3 is appropriate as the description does not compensate for schema coverage.

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 returns a list of Budget View Detail Rows for a project and budget view. It specifies the verb 'list', the resource 'Budget View Detail Rows', and the context 'for a project and budget view'. It also distinguishes itself from other list tools by mentioning paginated overview, finding IDs, and filtering.

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 explicitly says when to use the tool: 'to enumerate Budget records when you need a paginated overview, to find IDs, or to filter by query parameters.' However, it does not mention when not to use this tool or suggest alternatives, which would be helpful given the many 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