Skip to main content
Glama
TylerIlunga

Procore MCP Server

List Budget View Summary Rows

list_budget_view_summary_rows
Read-onlyIdempotent

Retrieve paginated budget view summary rows for a project, with filtering by biller, cost code, or category. Use to get an overview of budget records and find IDs.

Instructions

Return a list of all Budget View Summary Rows for a project and budget view. The type of row returned is dependent on the value used in the group_by query param. 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. 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}/summary_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
group_byNoQuery string parameter — groups the data. Value can be a comma separated string. Default is biller,root_cost_code
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 subtotals may change depending on t...
Behavior4/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses that row type depends on group_by param, mentions pagination with page/per_page, required parameters, and the presence of additional keys for visible source/formula columns. No contradictions with 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 two well-structured paragraphs, front-loading the main purpose and key details. Every sentence adds value, though some repetition (e.g., mentioning pagination twice) could be tightened.

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 complexity (13 parameters, no output schema), the description covers pagination, required params, group_by behavior, and extra keys. It does not fully describe the return structure, but the mention of 'paginated JSON array of Budget records' provides sufficient 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?

Input schema has 100% description coverage for all 13 parameters. The description adds only general context (group_by affects row type) but no per-parameter details beyond what the schema provides. Baseline 3 is appropriate as the description adds modest value.

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 it returns a list of Budget View Summary Rows for a project and budget view, with specific use cases like enumeration, finding IDs, and filtering. It effectively distinguishes from sibling tools like list_budget_view_detail_rows by focusing on summary rows.

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 explicit use cases (paginated overview, finding IDs, filtering), but does not mention when not to use this tool or compare with alternatives like detail rows. This is a minor gap for a tool with many siblings.

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