Skip to main content
Glama
doitintl

DoiT MCP Server

Official
by doitintl

create_budget

Destructive

Set up a cloud budget with spending limits, alert thresholds, and scope filters to monitor and control costs.

Instructions

Use this when the user wants to create a new cloud budget with spending limits and alert thresholds. Requires budget name, currency, type, and start period. Ask the user to confirm the budget parameters before executing. Do NOT use this for viewing existing budgets (use list_budgets or get_budget) or creating alerts (use create_alert).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesBudget name (required, non-empty).
amountNoBudget period amount. Required if usePrevSpend is false.
currencyYesCurrency code (required). Accepted values: USD, ILS, EUR, AUD, CAD, GBP, DKK, NOK, SEK, BRL, SGD, MXN, CHF, MYR, TWD, EGP, ZAR, JPY, IDR, AED, THB, COP.
typeYesBudget type (required). Accepted values: fixed, recurring.
timeIntervalNoRecurring budget interval. Required for recurring budgets. Accepted values: day, week, month, quarter, year.
startPeriodYesBudget start date as a UNIX timestamp in milliseconds (required).
endPeriodNoFixed budget end date as a UNIX timestamp in milliseconds. Required if type is fixed, must not be set for recurring.
descriptionNoBudget description.
usePrevSpendNoUse the last period's spend as the target amount for recurring budgets. Defaults to false.
growthPerPeriodNoPeriodical growth percentage in recurring budgets. Must be >= 0. Defaults to 0.
metricNoBudget metric. Accepted values: cost, amortized_cost. Defaults to cost.
publicNoPublic sharing access level. Accepted values: owner, editor, viewer.
scopesNoFilters that define the scope of the budget. Exactly one of scope or scopes must be provided.
scopeNoList of allocations that define the budget scope (deprecated). Exactly one of scope or scopes must be provided.
collaboratorsNoList of permitted users to view/edit the budget. If provided, must include at least one collaborator with role 'owner'.
alertsNoList of up to three alert thresholds defined as a percentage of the amount.
recipientsNoList of email addresses to notify when reaching an alert threshold.
recipientsSlackChannelsNoList of Slack channels to notify when reaching an alert threshold.
seasonalAmountsNoList of seasonal amounts for recurring budgets with different amounts per period.
Behavior3/5

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

Annotations already indicate destructive and non-read-only behavior. The description confirms creation but does not add details beyond that. It includes a confirmation step but omits information about permissions, side effects, or that the tool can create alerts within the budget. The open world hint suggests additional unspecified behaviors.

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 extremely concise at three sentences, front-loading the purpose, then required parameters, then usage guidelines and exclusions. Every sentence serves a clear purpose with no unnecessary words.

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

Completeness3/5

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

Given the tool's complexity (19 parameters, including nested objects), the description is somewhat minimal. It doesn't explain that alerts can be created within the budget, nor does it describe the return value. However, it does distinguish from create_alert and provides basic context. The absence of an output schema is partially mitigated by the annotations.

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

Parameters3/5

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

Schema description coverage is 100%, so the description does not need to add much parameter information. The description briefly mentions required parameters but does not elaborate on optional ones like alerts or collaborators. This is adequate given the schema already explains each parameter in detail.

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 creates a new cloud budget with spending limits and alert thresholds. It specifies required parameters and explicitly distinguishes from sibling tools like list_budgets, get_budget, and create_alert, ensuring the agent knows when to use this tool.

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?

The description provides explicit usage guidance: use when the user wants to create a budget, and it lists what not to use (viewing or alert creation) with alternative tools. It also instructs the agent to ask the user to confirm parameters before executing, which is a clear usage guideline.

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/doitintl/doit-mcp-server'

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