set_budgetSet a monthly spending limit for an expense category, updating an existing budget when needed to control spending.
Set or update the monthly budget for a category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The expense category (must exist in categories.json). | |
| monthly_limit | Yes | Monthly spending limit in INR. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency. It says 'Set or update' but doesn't disclose that it overwrites an existing budget for the category, what happens if the category doesn't exist, or any side effects (e.g., audit logs, validation rules). The schema mentions category existence but not the tool's behavior, leaving a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is appropriately brief for a 2-parameter setter tool and presents the core action and scope immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but since it's a mutation tool with no annotations, the description doesn't explain the actual mutation path (create vs update), error handling when the category is missing, or what the tool returns. It's adequate but incomplete, missing what the agent needs to anticipate a failed or unexpected call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description covers both parameters clearly (category existence, monthly limit in INR) at 100% coverage. The description adds only 'monthly budget' rephrasing, but no new meaning or caveats beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set or update'), a resource ('monthly budget'), and its scope ('for a category'). It distinguishes itself from sibling tools that operate on expenses or retrieve budget status, though it doesn't name an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like get_budget_status or edit_expense. The description simply states the action without defining the conditions or pre-requisites, such as needing an existing category or how this differs from editing expense records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.