ai-budget-planner
Server Details
Cloudflare Workers MCP server: ai-budget-planner
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- lazymac2x/ai-budget-planner-api
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.6/5 across 6 of 6 tools scored. Lowest: 3/5.
Each tool targets a distinct resource and action: budgets, departments, alerts, providers, and reports. No overlapping purposes.
All tool names follow consistent snake_case verb_noun pattern: create_budget, department_report, get_budget, etc.
Six tools cover the core functionality of budget planning without being too many or too few.
Covers creation, retrieval, alerts, providers, and reports. Missing update/delete for budgets, but core workflows are supported.
Available Tools
6 toolscreate_budgetBInspect
Create a monthly LLM budget allocation for a team or department
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable budget name | |
| api_key | No | API key for the request | |
| providers | No | LLM providers to track: openai, anthropic, google, mistral, cohere | |
| department | No | Department or team name | |
| monthly_limit_usd | Yes | Monthly spend cap in USD |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'create' but doesn't mention side effects, idempotency, required permissions, or error conditions. Insufficient transparency for a mutation tool.
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 short sentence, but it omits critical information. It is not excessively long, but could be better structured to include key details without verbosity.
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?
No output schema, 5 parameters, no annotations. The description fails to explain return values, error handling, or behavior under various inputs. Inadequate for the tool's complexity.
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?
Schema coverage is 100%, so parameters are already described. The tool description adds no extra meaning beyond the schema, so baseline score of 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 clearly states the action ('Create'), the resource ('monthly LLM budget allocation'), and the scope ('for a team or department'). It distinguishes from sibling tools like get_budget (read) and department_report (report).
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 on when to use this tool versus alternatives, no prerequisites or contextual hints provided. The description lacks any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
department_reportBInspect
Get month-to-date spend, utilisation, and alert status per department
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | API key for the request | |
| department | No | Filter to a single department (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'Get', implying a read operation, but fails to mention data freshness, authentication requirements, or any side effects. This is minimal disclosure.
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 sentence that is front-loaded with the action and resource. Every word is necessary, and there is no superfluous content.
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?
Given the tool's simplicity (two parameters, no output schema), the description adequately covers what the tool returns (spend, utilisation, alert status). However, it could hint at the output format (e.g., aggregated or per department list) for full completeness.
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?
Schema description coverage is 100%, so baseline is 3. The description adds no new meaning beyond the schema; it does not clarify 'api_key' usage or 'department' formatting.
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 uses the specific verb 'Get' and identifies the resource as 'month-to-date spend, utilisation, and alert status per department'. It clearly distinguishes from sibling tools like 'create_budget' (creation) and 'weekly_report' (weekly vs monthly focus).
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 alternatives. It does not mention when not to use it, nor does it contrast with siblings like 'weekly_report' or 'get_budget_alerts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_budgetAInspect
Get current utilisation, spend breakdown by provider, and alert status for a budget
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | API key for the request | |
| budget_id | Yes | Budget ID from create_budget (format: bgt_xxx) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly communicates a read-only operation ('Get'). However, it does not disclose additional behavioral traits like required permissions (beyond api_key which is in schema) or rate limits. It is adequate but not rich.
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, focused sentence that front-loads the key information (what is retrieved: utilisation, spend breakdown, alert status) without any unnecessary words.
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?
Although there is no output schema, the description lists three specific pieces of data returned, providing a good overview. It is nearly complete for a simple two-parameter tool, but it could mention the response format or pagination for completeness.
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?
Schema coverage is 100%, so the description does not need to add parameter details. The description does not add extra meaning beyond what is already documented in the input schema for api_key and budget_id.
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 explicitly states it retrieves utilisation, spend breakdown, and alert status for a budget, which clearly distinguishes it from sibling tools like get_budget_alerts (which likely only returns alerts) and create_budget.
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 alternatives such as get_budget_alerts or department_report. The description only implies usage when budget information is needed, but lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_budget_alertsAInspect
List all threshold alerts triggered for a budget (50%, 75%, 90%, 100%)
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | API key for the request | |
| budget_id | Yes | Budget ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description relies on its own text. It discloses that the tool lists all threshold alerts for a budget with specific percentages, implying read-only behavior. However, it does not mention side effects, authentication requirements, or any limitations.
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, front-loaded sentence that conveys the essential purpose with no unnecessary words.
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?
For a simple list tool with no output schema, the description adequately covers what alerts are returned (threshold-alerts with percentages). It could mention pagination or ordering, but it is complete enough for an agent to understand its basic function.
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 already describes both parameters (api_key and budget_id) with 100% coverage. The description adds no extra meaning beyond the schema, so it meets the baseline.
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 clearly specifies the verb (list) and resource (threshold alerts triggered for a budget), including the specific percentages (50%, 75%, 90%, 100%). It distinguishes itself from sibling tools like create_budget and department_report by focusing on budget alerts.
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?
The description does not provide when to use this tool versus alternatives. It only states what the tool does without context on when it's appropriate or when another tool might be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_providersAInspect
List supported LLM providers, their models, and blended cost estimates per 1M tokens
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool lists data, but does not disclose data sources, update frequency, or any limitations such as whether estimates are for input or output tokens.
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 sentence that is well-structured and front-loaded. Every word earns its place.
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?
Given no parameters and no output schema, the description is largely complete. However, it omits details like whether the cost estimates are per input/output tokens or if pricing tiers are included.
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?
There are no parameters, so schema coverage is 100% vacuously. The description does not need to add parameter info; a baseline of 4 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 clearly states the verb 'List' and the resource 'supported LLM providers, their models, and blended cost estimates per 1M tokens'. It is specific and distinguishes from sibling tools which focus on budgets and reports.
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 explicit guidance on when to use this tool versus alternatives. The usage is implied by the tool's purpose, but there is no mention of scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weekly_reportAInspect
Get a 7-day LLM spend digest broken down by department and provider
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | API key for the request | |
| provider | No | Filter by provider name (optional) | |
| department | No | Filter by department name (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool provides a read-only digest over 7 days, but does not cover authentication requirements (API key usage is unclear), rate limits, or error handling. With no annotations, the description carries full burden but leaves gaps.
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?
A single, clear sentence that is appropriately sized and front-loaded. Every word adds value with no redundancy.
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 has no output schema and three optional parameters. The description explains the output is a digest but does not specify the format or fields. Without annotations, additional context about error cases or pagination would improve completeness.
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?
Schema description coverage is 100%, and the description adds context by explaining the breakdown by department and provider, clarifying the optional filters. The API key parameter is mentioned generically in the schema, but the description does not add further semantics for it.
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 clearly states the tool returns a 7-day LLM spend digest broken down by department and provider. It uses a specific verb and identifies the resource, and it distinguishes itself from sibling tools like department_report and list_providers.
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 on when to use this tool versus alternatives. No mention of prerequisites, when not to use it, or how it compares to sibling tools like get_budget or department_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!