Skip to main content
Glama

project_budget

Compare planned vs actual budgets per project line by line. Identify spend not captured by budget lines using optional filters.

Instructions

Report planned vs actual budget per project, line by line.

Reads the Budgets app (budget.line on Odoo 18+, else crossovered.budget.lines) and matches lines to active projects by a line-level project_id m2o when the instance has one, else through the project's analytic account. Amounts are absolute company-currency sums; server-computed practical/theoretical amounts are used as-is. Also compares each project's total analytic cost against the practical amounts booked on its budget lines, flagging spend the budget does not capture. When the filter matches exactly one project the report gains a per-line breakdown. No date filters: budget lines carry their own period.

Args: project: Optional project-name filter (name ilike). Exactly one match switches on the per-line breakdown. manager: Optional project-manager filter (user_id.name ilike). customer: Optional customer filter (partner_id.name ilike). top_n: Rows in the per-line breakdown (default 10). burn_pct_at_risk: Burn %% >= this -> at_risk (default 80). burn_pct_off_track: Burn %% >= this -> off_track (default 100). timezone_offset: UTC offset for "today" (default 7).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
top_nNo
managerNo
projectNo
customerNo
timezone_offsetNo
burn_pct_at_riskNo
burn_pct_off_trackNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description fully discloses behavior: it reads from Budgets app, uses specific matching logic, computes absolute amounts, compares with analytic costs, and flags uncovered spend. It clarifies why no date filters exist.

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 efficiently structured: first paragraph for overall behavior, second for internal details, then clear parameter list. Every sentence adds value without redundancy.

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 complexity (7 params, output schema exists), the description covers all necessary context: inputs, behavior, special cases, and what the output represents. No gaps identified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries all parameter explanations. The Args section explains each parameter with defaults and behavior (e.g., project filter triggers per-line breakdown, default values given).

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 reports planned vs actual budget per project, line by line. It distinguishes itself from sibling tools like project_dashboard or project_status_report by focusing on budget comparisons.

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 implies usage for budget analysis with filters, and explains the behavior when a single project is matched. However, it does not explicitly compare to siblings or mention when not to use.

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/minhhq-a1/odoo-pulse'

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