This server provides a single local tool, evaluate_spend_policy, to deterministically check whether a proposed agent spend action is permitted under a caller-supplied policy. It returns one of three eligibility verdicts: ELIGIBLE, DENY, or STEP_UP with stable reason codes. The policy checks include matching expected principal, agent, authority, asset, payload hash, and idempotency key; verifying the rail and recipient are in allowed lists; enforcing per-action and daily limits using caller-supplied already-spent amount; optional step-up threshold and purpose requirement; and action expiration. All monetary values are integer micro-unit strings. The tool is read-only, idempotent, makes no network requests, has no side effects, and does not authorize, sign, send, settle, or execute any payment — it only provides a local policy evidence verdict.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DingDawg Agent Spend Policy MCP Can I spend $50 on cloud compute? Check against our policy."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small, local MCP server that deterministically evaluates whether a proposed agent spend action matches a supplied policy.
It returns one of ELIGIBLE, DENY, or STEP_UP, with a stable reason code.
ELIGIBLE is local policy evidence only. It is not payment authorization.
This package does not hold funds, private keys, payment credentials, customer data, or settlement authority. It does not sign, send, settle, custody, or record payments. It makes no network requests.
A production payment adapter needs separate, independently verified controls for authenticated policy/action provenance, canonical payload hashing, durable atomic budget reservation and replay protection, customer-controlled signing, rail validation, and settlement reconciliation.
Related MCP server: dingdawg-agent-wallet
npx -y @dingdawg/agent-spend-policy-mcpConfigure it as a local stdio MCP server:
{
"mcpServers": {
"dingdawg-agent-spend-policy": {
"command": "npx",
"args": ["-y", "@dingdawg/agent-spend-policy-mcp"]
}
}
}evaluate_spend_policy accepts an evaluation time, a policy, a proposed action,
and the already-spent amount. All money is passed as integer micro-unit strings,
never JavaScript floating-point numbers.
The caller supplies the clock and already-spent value; therefore this tool is safe for dry runs and local evidence, not a replacement for a trusted payment or accounting system.
The versioned machine-readable contract is
capabilities.json. It describes the only tool this
package exposes, its required inputs, its three possible outcomes, and its
non-negotiable safety boundary.
Transport: local stdio MCP
Tool: evaluate_spend_policy
Required inputs: evaluationTime, policy, action, and
alreadySpentMicros
Outputs: ELIGIBLE, DENY, or STEP_UP, each with a stable reason code
Side effects: none
Credentials, payment execution, custody, signing, settlement, and network access: not supported
The manifest is package-source evidence for this release, not a promise of a
hosted agent-discovery endpoint. ELIGIBLE remains local policy evidence only,
not payment authorization.
npm install
npm test
npm run pack:checkDeterministically evaluates a proposed action against caller-supplied policy. This is local policy evidence only: it never authorizes, signs, sends, settles, custodies, or records a payment.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| policy | Yes | ||
| evaluationTime | Yes | ||
| alreadySpentMicros | Yes |
| Name | Required | Description |
|---|---|---|
| outcome | Yes | |
| reasonCode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by stating 'deterministically' and enumerating all the things it never does: 'never authorizes, signs, sends, settles, custodies, or records a payment.' This is critical behavioral context that annotations (readOnly, idempotent, non-destructive) do not fully convey, especially the deterministic nature and the explicit non-authorization boundary.
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 sentences long, with the primary action in the first sentence and critical boundary statements in the second. It is front-loaded with the main purpose and wastes no words. Every clause 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?
The tool has complex nested parameters and no parameter descriptions, but the output schema exists (not shown) and annotations provide safety hints. The description clearly conveys the tool's role as a local, deterministic policy check and its non-payment-execution boundary. It could add more detail about the evaluation result (e.g., what the response contains), but the output schema likely covers that, so the description is reasonably complete.
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 has 0% description coverage for its 4 parameters, so the description must compensate. It only loosely references 'proposed action' and 'caller-supplied policy' (mapping to 'action' and 'policy'), but it does not explain 'evaluationTime' or 'alreadySpentMicros'. The description adds minimal parameter-level meaning, leaving users to infer the rest from schema structure alone.
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 'deterministically evaluates a proposed action against caller-supplied policy,' specifying the exact verb and resource. It distinguishes the tool's purpose from typical payment execution by explicitly listing what it never does (authorize, sign, send, settle, custody, record). This makes it distinct even without sibling tools.
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 for policy evaluation ('Deterministically evaluates a proposed action against caller-supplied policy') and adds the context 'local policy evidence only.' However, it does not explicitly state when to use this tool versus other potential approaches, nor does it provide exclusions or alternatives (though no siblings exist). The guidance is present but mostly implicit.
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.
v0.1.0evaluate_spend_policyScored across 1 tool
With only one tool, there is no possibility of overlap or ambiguity. The tool's purpose is clearly defined and distinct.
The sole tool name 'evaluate_spend_policy' follows a clear verb_noun pattern, and with no other tools, there are no inconsistent conventions.
A single tool is slightly thin, but it is well-scoped for the server's narrow purpose of evaluating spend policies. The count is reasonable and not trivial.
The tool fully covers its domain: it deterministically evaluates a proposed action against policy and explicitly avoids out-of-scope actions. No obvious gaps exist for the stated purpose.
Deterministic allow/require_approval/deny verdicts for agent actions, before they happen.
Advisory policy preflight for AI-agent spend requests; never executes payments or accesses wallets.
Deterministic authorization for one proposed AI agent action, returned with a signed receipt.
Bind authority to the exact action and re-evaluate before commit. The hosted Decionis MCP service connects proposed actions to policy decisions, organization context, and signed evidence. Start in shadow mode before enabling enforcement through a supported executor. Requires OAuth or an organization API key.
