Skip to main content
Glama

List budgets

list_budgets
Read-onlyIdempotent

List a project's budget IDs and names to verify if budgets are tracked and to obtain IDs for use with attachments or other budget-related operations.

Instructions

List a project's budgets — their ids and names, which is all API v3 exposes.

Use it to see whether a project tracks budgets at all and to get a budget id, which is what list_attachments(container_type='budget', ...) consumes.

Returns the standard list envelope with rows of {id, subject}. The collection is fetched in full, so has_more is false.

Pitfalls — read before answering a money question. API v3's budget representer carries no amounts: planned costs, spent costs, labor/material breakdowns and the assigned work packages are simply not there. Do not infer them and do not present a budget row as financial data; point the user at the budget in the UI, or use get_project_report_data / list_time_entries for the effort side. Budgets are also a module: a 404 (not installed, or not enabled in this project) and a 403 (this account lacks 'view budgets') both come back as a SUCCESSFUL call with an empty items and the reason in notes. Neither means the project has no budgets, so check notes before answering — only an empty list with no notes means there are none.

Cross-references: list_projects for the project id; list_time_entries for logged effort; list_attachments(container_type='budget', container_id=...) for budget files.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesNumeric project id or URL identifier, from list_projects. Budgets are always read per project; there is no instance-wide budget listing.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sumsNoPresent only when show_sums was requested.
itemsNoThe page of results.
notesNoDegradation markers: capped aggregations, unavailable modules, …
groupsNoPresent only when group_by was requested.
paginationYesTotal/page/page_size/has_more.
Behavior5/5

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

Beyond annotations, the description discloses critical behavior: the API returns no amounts, budgets are a module with silent failures (404/403 appear as successful empty lists), and the collection is fetched in full. This goes well beyond the readOnly/idempotent hints and prevents misleading financial inferences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized into purposeful paragraphs: what it does, how to use it, return format, pitfalls, and cross-references. No redundancy; every sentence contributes unique value.

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?

Given the tool's complexity (API limitations, module errors) and the presence of an output schema, the description fully covers return envelope, error semantics, and related tools. Nothing essential is missing.

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?

Schema coverage is 100%, so the baseline is 3. The description does not add much beyond the schema's project_id explanation; it references list_projects but the schema already says to use that. No additional parameter semantics are provided.

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 opens with 'List a project's budgets — their ids and names', which is a specific verb, resource, and scope. It clearly distinguishes this tool from siblings like list_projects or list_time_entries by focusing solely on budgets.

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?

The description explicitly states when to use the tool ('to see whether a project tracks budgets at all and to get a budget id') and names alternatives ('get_project_report_data' / 'list_time_entries' for effort side). It also explains how 404/403 errors are represented, so the agent knows when not to treat an empty result as definitive.

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/kar-thik/openproject-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server