Skip to main content
Glama

Update project budget

well_update_project_budget

Set one budget cell of a project: the amount a budget version plans on one revenue or expense ledger account in one fiscal month, in the workspace base currency.

Use this when the person states a budget, a plan or a target for a project, e.g. "plan 12 000 of consulting revenue on Acme in March". Budget rows are kept apart from actual rows: well_get_project_margin shows a budget beside the booked figures of the same fiscal period and never sums one into the other.

REQUIRED: project_id (from well_list_projects), version_name, fiscal_year, fiscal_period (1 to 12), ledger_account_id (a live REVENUE or EXPENSE account of this workspace, from a one-row well_query_records lookup on ledger accounts), amount (a decimal string, zero or more, at most 4 decimals). OPTIONAL: currency — when set, it must be the workspace base currency.

The first cell of a new version_name creates that version: a monthly draft budget in the base currency over the fiscal year of that cell. A later cell outside that fiscal year is refused; name another version for another year. A second call for the same version, project, account and fiscal month replaces the amount and returns created: false. An unknown project or account, an account that is neither revenue nor expense, a currency other than the base currency, a fiscal month before the company's first fiscal period, and a version of that name that is not an open monthly budget are each refused, and nothing is written. Ask the person for a missing value; never guess an account or a version.

Returns { success: true, allocation_id, forecast_id, forecast_name, project_id, fiscal_year, fiscal_period, account_number, currency, amount, created } on success, or { success: false, error } on failure.

Input Schema

NameRequiredDescriptionDefault
amountYesThe planned amount as a decimal string, zero or more, with at most 4 decimals, e.g. 12500.00.
currencyNoThe ISO 4217 currency of amount. Optional; when set it must be the workspace base currency.
project_idYesThe live project the budget is for, from well_list_projects.
fiscal_yearYesThe fiscal year of the cell, 2000 to 2100, as journal entries are stamped, e.g. 2026.
version_nameYesThe budget version, by name, e.g. FY2026 budget. The first cell of a new name creates a monthly draft budget over that cell's fiscal year.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
fiscal_periodYesThe fiscal month of the cell, 1 for the first month of the fiscal year through 12.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
ledger_account_idYesA live REVENUE or EXPENSE ledger account of this workspace; its type makes the amount revenue or expense.

Output Schema

NameRequiredDescriptionDefault
codeNo
errorNo
amountNo
createdNo
successYes
currencyNo
project_idNo
fiscal_yearNo
forecast_idNo
reply_linesNo
allocation_idNo
fiscal_periodNo
forecast_nameNo
account_numberNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
near_candidatesNo
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
near_candidates_truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / code
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / near_candidates
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "company_id": {
      +        "type": "string"
      +      },
      +      "name": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "company_id",
      +      "name"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / near_candidates_truncated
      Added value: +{
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / reply_lines
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Added

TDQS

A4.4/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the write-but-non-destructive profile is already conveyed. The description adds substantial context the annotations cannot: first-cell-creates-version semantics, idempotent replacement returning created:false, and enumerated refusal conditions where nothing is written. This is genuinely useful but the destructiveHint=false paired with 'replaces the amount' is slightly under-explained regarding overwrite risk.

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?

Well front-loaded: purpose first, then usage, then required/optional parameters, then lifecycle and failure behavior, then returns. It is long but nearly every sentence carries distinct information; the REQUIRED/OPTIONAL enumeration partly repeats schema content but aids scanning.

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?

For an 11-parameter mutation tool with an output schema, the description covers the full lifecycle: version creation, same-cell overwrite semantics, refusal cases, and the return shape including created flag. Nothing an agent needs to call this safely and correctly is missing.

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

Parameters4/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, but the description adds real value: it prescribes sourcing for project_id (well_list_projects) and ledger_account_id (a one-row well_query_records lookup on revenue/expense accounts), reinforces amount format constraints, and constrains currency to the base currency. It does not explain workspace_id or conversation_id, which the schema already documents.

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?

States a precise verb and resource ('Set one budget cell of a project') and immediately scopes it to one ledger account in one fiscal month in the base currency. It is unmistakably distinct from sibling write tools like well_update_project_allocations or well_update_project, and even clarifies that budgets never mix into actuals shown by well_get_project_margin.

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?

Explicitly names the trigger ('when the person states a budget, a plan or a target') with a concrete example, and distinguishes the tool from the reporting sibling well_get_project_margin. It also gives a clear procedural rule: ask for missing values and never guess an account or a version.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources