Hundo

propose_budget_upsert

Propose creating a new budget or updating an existing one. For create: provide name, allocated, currency. For update: provide envelopeId, allocated; the name and currency are kept from the existing budget. A budget resets weekly or monthly (period, default monthly) and tracks spending one of two ways: trackingMode 'category' counts the linked categories, and ONE budget can cover MANY: pass every category in categoryIds (e.g. rent + groceries + transport + utilities for a single 'Needs' budget); trackingMode 'manual' links no categories and the user tracks it by hand. On update, categoryIds replaces the current list, so pass the whole list. Look category ids up first and never invent them. Returns a proposal id; to record it, call the confirm_proposal tool with the returned proposalId after the user approves (there is no UI button or proposal card to click in this context).

MCP note: this tool only CREATES a pending proposal; nothing is recorded until confirm_proposal is called.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Required when creating a new budget.
`period`	No	How often the allocation resets. Defaults to 'monthly' on create; left unchanged on update unless you pass it.
`currency`	Yes
`allocated`	Yes	Allocation in MAJOR units (the displayed amount, e.g. 500.00 for $500.00, 5000000 for Rp 5,000,000). The server scales to storage units; never pre-multiply by 100.
`categoryId`	No	Shorthand for a categoryIds list of one. It is NOT an 'add this one' field: on update it replaces the budget's whole category list, exactly as categoryIds does, so a budget that already covers several would be left with just this one. To add a category to an existing budget, read its current list and pass all of them in categoryIds.
`envelopeId`	No	Id of an existing budget to update; omit to create a new budget.
`categoryIds`	No	Every category this budget tracks, e.g. rent + groceries + transport + utilities for one 'Needs' budget. On update this REPLACES the budget's current categories, so pass the full list you want, not just the new ones. Look ids up first; never invent them.
`trackingMode`	No	'category' counts spending from the linked categories automatically; 'manual' counts nothing and the user records progress by hand. Omit on create and it follows whether you passed categories.
`editsProposalId`	No	Id of an existing pending proposal to update in place. Pass this when the user asks to modify a proposal you previously made (e.g. 'make it $50 instead'). Look up current ids with listPendingProposals if you're unsure. Omit when proposing something new.
`includeInvestments`	No	Count asset purchases (buys) toward this budget's spending alongside expenses. Defaults to false on create; left unchanged on update unless you pass it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 16, 2026

addedInput schema / properties / categoryId / description

Added value: +"Shorthand for a categoryIds list of one. It is NOT an 'add this one' field: on update it replaces the budget's whole category list, exactly as categoryIds does, so a budget that already covers several would be left with just this one. To add a category to an existing budget, read its current list and pass all of them in categoryIds."

addedInput schema / properties / categoryIds

Added value: +{
+  "description": "Every category this budget tracks, e.g. rent + groceries + transport + utilities for one 'Needs' budget. On update this REPLACES the budget's current categories, so pass the full list you want, not just the new ones. Look ids up first; never invent them.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / includeInvestments

Added value: +{
+  "description": "Count asset purchases (buys) toward this budget's spending alongside expenses. Defaults to false on create; left unchanged on update unless you pass it.",
+  "type": "boolean"
+}

addedInput schema / properties / period

Added value: +{
+  "description": "How often the allocation resets. Defaults to 'monthly' on create; left unchanged on update unless you pass it.",
+  "enum": [
+    "weekly",
+    "monthly"
+  ],
+  "type": "string"
+}

addedInput schema / properties / trackingMode

Added value: +{
+  "description": "'category' counts spending from the linked categories automatically; 'manual' counts nothing and the user records progress by hand. Omit on create and it follows whether you passed categories.",
+  "enum": [
+    "category",
+    "manual"
+  ],
+  "type": "string"
+}

First observedSep 10, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that the tool only creates a pending proposal until confirm_proposal is called, that categoryIds replaces the whole category list on update, that name/currency are preserved on update, and that a proposal id is returned. These are exactly the non-obvious behavioral details an agent needs.

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 dense and information-rich, and it is front-loaded with the core create/update distinction. Almost every sentence earns its place, though the closing MCP note partly repeats the earlier confirm_proposal guidance, adding minor 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?

For a complex 10-parameter tool with no output schema and all-false annotations, the description covers the full lifecycle: how to propose, what each mode means, how replacement semantics work, how to reuse proposals, and how to finalize via confirm_proposal. An agent has enough context to call this tool correctly.

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?

Even though schema coverage is high, the description adds essential semantics: which parameters apply on create vs update, that categoryId is a shorthand replacement rather than an additive field, that allocated is in major units and must not be pre-multiplied, and that trackingMode 'category' counts linked categories while 'manual' tracks by hand. This goes well beyond the field-level schema text.

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 states a specific action and resource: proposing creation or update of a budget. It clearly distinguishes the create and update flows with the fields each requires, and it is unambiguous next to siblings like confirm_proposal or propose_delete_budget.

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?

It gives explicit conditions for create vs update, explains when to pass envelopeId, categoryIds, and editsProposalId, and directs the agent to listPendingProposals when unsure. It also clearly states that confirm_proposal must be called afterward and that there is no UI button in this context, leaving no ambiguity about when to use this tool vs its downstream sibling.

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

All Hundo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?