OpenMonetis MCP

Criar orçamento

create_budget

Create or update a category budget for a specific month; confirmation is required before execution. Use it to set or adjust monthly spending limits for financial planning.

Instructions

Cria (ou atualiza) o orçamento de uma categoria em um mês. Exige confirm: true para executar.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "categoryId": "<categoryId>",
      "period": "<period>",
      "amount": "<amount>"
    },
    "name": "create_budget"
  }
}

Input Schema

Name	Required	Description	Default
`amount`	Yes
`period`	Yes
`confirm`	No
`categoryId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Nov 13, 2026

TDQS

B3.1/5.0

Behavior3/5

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

The annotations already declare this as a non-read-only, non-destructive, non-open-world mutation, and the description adds two facts they do not carry: the operation is an upsert, and a confirmation flag gates execution. That confirm gate is genuinely important because `confirm` is optional in the schema, so without the description an agent could call it and silently no-op. Remaining gaps: no mention of required permissions, no statement of what happens to a pre-existing amount, and no error behavior. Note a soft tension with idempotentHint=false, since an upsert keyed on category+period is arguably idempotent — not a hard contradiction.

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?

Two tight sentences with the core action front-loaded and the execution precondition second; no filler. It is lean to the point of under-specification, but that cost is better attributed to completeness than to structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a mutation tool with four parameters at 0% schema description coverage and no output schema, so the description is the only source of semantic detail — and it addresses one parameter. An agent still cannot tell what `amount` means numerically, how to source a category ID, or what the call returns or overwrites.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning and it covers only one of four: it names `confirm` and its required value. It says nothing about `categoryId` (a UUID lookup, and where to obtain one), nothing about the `YYYY-MM` period format, and nothing about `amount` (currency, units, whether 0 is meaningful — the schema permits 0 and it is unclear whether that deletes or stores zero).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource plus its scope: creating or updating the budget of one category in one month. The upsert nature is surfaced in parentheses, which is more than a restatement of the name. It does not distinguish itself from any sibling, though no budget-related alternative appears in the catalog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives one concrete precondition — `confirm: true` is required to execute — which tells the agent how to actually trigger the write. It offers no guidance on when to prefer this over other tools, no note on what happens if a budget already exists for that period (silent overwrite vs. error), and no exclusions.

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

Deploy Server