MCP server implementing the Budget Authority Protocol. Spending limits for AI agents. Two ways to connect:
Option A: Local (npx)
{
"mcpServers": {
"budget": {
"command": "npx",
"args": ["@goodmeta/agent-verifier-mcp"],
"env": { "VERIFIER_API_KEY": "gm_..." }
}
}
}Option B: Remote (no install)
{
"mcpServers": {
"budget": {
"type": "streamable-http",
"url": "https://verifier.goodmeta.co/mcp",
"headers": { "Authorization": "Bearer gm_..." }
}
}
}Then ask your agent:
"Search Exa for agent payments research. Budget: $1."
The agent calls create_budget, check_budget before each payment, and settle after. If the budget runs out, the next payment is denied.
Tool | What it does |
| Set a spending limit ($10, 24 hours) |
| Check if a purchase is allowed (places a hold) |
| Confirm hold after payment, or release if payment failed |
| Return a pre-commit hold to the budget (cancel before it settles) |
| Reverse a settled payment, fully or partially |
| Query remaining budget and history |
| Look up a single hold's state (held, settled, released, refunded) |
Related MCP server: Almega MCP
Agent wants to buy something ($0.50)
│
├── check_budget(budget_id, 50, "vendor")
│ → "Approved. Hold ID: hold_abc. Remaining: $9.50"
│
├── [agent makes the payment via x402/card/MPP/any rail]
│
└── settle(hold_id, success=true)
→ "Hold confirmed."Budget enforcement is rail-agnostic. Works with x402, credit cards, MPP, bank transfers — the verifier tracks the budget, the payment method doesn't matter.
Get a free API key:
curl -X POST https://verifier.goodmeta.co/setup/merchants \
-H "Content-Type: application/json" \
-d '{"names":["My Agent"]}'Add the key to your MCP config. Done.
Any MCP-compatible client (Cursor, Windsurf, Codex, OpenClaw)
agent-verifier npm package for programmatic use
demo-agent for a full working example with real x402 payments
Five protocols let AI agents spend money (AP2, ACP, x402, MPP, UCP). None of them track what the agent spent across services. An agent calling Exa + Firecrawl + Nansen can overspend because each service approves independently. This MCP server is the missing budget layer.
Check if a purchase is within budget. Call BEFORE making a payment. Returns a hold_id to settle after.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | Yes | Who you are paying (e.g. "exa.ai") | |
| budget_id | Yes | Budget ID from create_budget | |
| amount_cents | Yes | Amount in cents (e.g. 700 for $7.00) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool checks budget and returns a hold_id, but does not disclose what happens on failure (e.g., error if over budget) or any side effects beyond the hold. Reasonably transparent but not exhaustive.
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 two concise sentences with zero filler. It efficiently conveys the core purpose and workflow.
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 output schema, the description mentions the return value (hold_id). It could improve by noting potential error responses, but overall it provides sufficient context for a simple check tool. Sibling tools are related but not explained in detail.
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 the schema already documents all three parameters. The description adds no additional semantics beyond what is in 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 uses specific verb 'check' and resource 'budget', and clearly distinguishes its purpose from sibling tools like 'settle' and 'release' by stating it is a pre-payment verification that returns a hold_id.
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 explicitly states when to call ('BEFORE making a payment') and what to do with the result ('Returns a hold_id to settle after'). It does not explicitly mention when not to use it or alternatives, but the context of sibling tools implies a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a spending budget for this agent. Set a limit before making purchases.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | Currency code (default: usd) | usd |
| valid_hours | No | How many hours the budget is valid (default: 24) | |
| amount_dollars | Yes | Budget limit in dollars (e.g. 10.00 for $10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states a creation action but lacks details on whether existing budgets are overridden, if multiple budgets can coexist, required permissions, or response behavior. This is insufficient for an AI agent.
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?
Two sentences, no filler, front-loaded with purpose. Every word is necessary and clear.
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?
With no output schema and no annotations, the description should cover creation behavior, idempotency, and response. It only states what the tool does, not how it works or what to expect, leaving significant gaps for a 3-parameter tool.
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%; all parameters have descriptions. The description adds 'set a limit' which aligns with amount_dollars but adds no new meaning beyond the schema. Baseline 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 tool creates a spending budget for the agent and sets a limit before making purchases. It differentiates from sibling tools like check_budget and get_budget which are for querying, and refund/release which are for other actions.
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 implies usage before purchases ('Set a limit before making purchases'), but does not explicitly provide when-to-use vs alternatives or any exclusion criteria. Sibling tools suggest other budget-related actions but no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check remaining budget and spending history.
| Name | Required | Description | Default |
|---|---|---|---|
| budget_id | Yes | Budget ID from create_budget |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only behavior but does not explicitly state non-destructiveness, authorization requirements, or side effects. Minimal behavioral 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?
Single sentence, front-loaded with key information. No wasted words. Appropriate for a simple tool.
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 simplicity (1 param, no output schema), the description is adequate but lacks clarification on return format of spending history and fails to distinguish from sibling 'check_budget'.
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% with budget_id description 'Budget ID from create_budget'. Description adds no extra meaning beyond the schema. 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?
Description clearly states verb 'check' and resource 'budget', specifying the information retrieved (remaining budget and spending history). However, it does not differentiate from the sibling tool 'check_budget', which appears to have a similar purpose.
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 like 'check_budget' or other siblings. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the state of a single reservation/hold by its ID (held, settled, released, refunded, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| hold_id | Yes | Hold ID from check_budget |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation (look up), but does not explicitly state it is non-destructive or idempotent. Listing possible states adds some transparency but could be more detailed about side effects or error conditions.
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 sentence that is front-loaded with the purpose and includes a list of example states. Every part earns its place; 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?
Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose and return hints. However, it could better contextualize usage among the seven sibling tools (e.g., distinguishing from get_budget or check_budget). Overall adequate but not exhaustive.
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?
Only one parameter (hold_id) exists, and the schema provides a basic description. The description adds context by stating the tool queries by ID and linking to check_budget, which gives meaning beyond the schema. With 100% schema coverage, baseline is 3, and the description adds extra value.
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 looks up the state of a single reservation/hold by its ID, listing possible states (held, settled, released, refunded). This is a specific verb+resource and distinguishes it from sibling tools like refund or release which modify state.
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 implies usage when you need to check the current state of a reservation, but does not explicitly state when not to use it or provide alternatives among the listed siblings. It lacks guidance on comparing to similar lookup functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refund a settled (already-committed) payment, fully or partially. Reverses the spend and restores budget. For pre-commit cancellations use release instead.
| Name | Required | Description | Default |
|---|---|---|---|
| hold_id | Yes | Hold ID of the settled payment to refund | |
| amount_cents | Yes | Amount to refund in cents | |
| idempotency_key | No | Stable key that makes retries safe. If omitted one is generated, but a retry without the same key will refund again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the effect (reverses spend and restores budget) but does not detail idempotency or error cases. Still, it provides essential behavioral context.
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?
Two concise sentences with no fluff, front-loaded with the key action and scope.
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 3 parameters and no output schema, the description explains the purpose and alternative. It could mention the return value or partial refund behavior, but it is largely sufficient.
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 baseline is 3. The description repeats schema descriptions without adding new meaning. It does not clarify format or constraints beyond the schema.
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 refunds a settled payment, fully or partially, distinguishing it from similar tools like release. It uses specific verbs and resources.
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 explicitly states when to use (for refunding settled payments) and when not to (for pre-commit cancellations, use release instead), providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Release a pre-commit hold, returning the unspent reservation to the budget. Use when a planned payment is cancelled BEFORE it settles. For already-settled payments use refund instead.
| Name | Required | Description | Default |
|---|---|---|---|
| hold_id | Yes | Hold ID from check_budget |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a mutating operation (releasing a hold) and describes the effect (returning unspent reservation). However, it does not disclose potential side effects like authorization requirements or idempotency, but the simplicity of the tool (single parameter) makes this minor.
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?
Two sentences, front-loaded with the primary action, followed by usage guidance and alternative. No extraneous words; every sentence adds value.
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?
With one parameter, no output schema, and a simple action, the description sufficiently covers what the tool does, when to use it, and how it differs from siblings. No additional context is needed.
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?
Input schema has 100% coverage with description for hold_id ('Hold ID from check_budget'). The description adds no further information about the parameter beyond the schema, so 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 clearly states it releases a pre-commit hold and returns unspent reservation to the budget, distinguishing it from the sibling tool 'refund' by specifying the condition (cancelled before settlement vs. after settlement).
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?
Explicitly tells when to use the tool ('when a planned payment is cancelled BEFORE it settles') and when to use the alternative ('for already-settled payments use refund'), providing clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm or cancel a payment hold. Call AFTER payment succeeds (success=true) or fails (success=false).
| Name | Required | Description | Default |
|---|---|---|---|
| hold_id | Yes | Hold ID from check_budget | |
| success | Yes | true if payment succeeded, false to release the hold |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states it confirms or cancels a hold but does not disclose side effects (e.g., whether the hold is released, idempotency, or if further actions are needed). This is insufficient.
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 conveys the core purpose and usage condition without any extraneous words. It is highly concise and front-loaded.
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 with two parameters, but the description omits return value information (no output schema) and does not mention prerequisites like having a valid hold from check_budget. It covers the basic action but lacks completeness for an agent to use without potential gaps.
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 the schema already explains both parameters. The description reinforces the success parameter's usage ('Call AFTER...') but does not add new meaning beyond the schema.
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 it confirms or cancels a payment hold based on the success parameter. It distinguishes the tool's action but does not explicitly differentiate from the sibling 'release' tool, which might have similar functionality.
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 explicitly says to call after payment succeeds or fails, providing clear context. However, it does not mention when not to use it or alternatives such as 'release'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0check_budgetcreate_budgetget_budgetquery_reservationrefundreleasesettleMost tools have distinct purposes, but 'release' and 'refund' could be confused without careful reading of descriptions. However, the descriptions clearly differentiate pre-commit vs. settled.
All tool names follow a consistent verb_noun pattern using snake_case, e.g., check_budget, create_budget, query_reservation.
7 tools cover the essential budget and payment lifecycle without being bloated. Each tool serves a clear role.
The tool set covers create, check, hold, settle, release, refund, and query operations. Missing update or delete budget, but those are less critical for the core workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agent a spending limit: approval controls and single-use virtual cards.
Budget & cost control for AI agents — per-agent spend caps + rate limits before each call.
AI agent spending controls. Set limits, blocklists, and caps. Approve transactions from your phone.
Payment infrastructure for AI agents: spending rules, approval flows, single-use virtual cards.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/goodmeta/agent-verifier-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
