Skip to main content
Glama

DPX — Institutional Cross-Border Settlement

policy.create

Create a spending policy for an AI agent. Sets rules the agent must follow before any financial action: per-transaction ceiling, daily limit, hold threshold, blocked counterparties, allowed purposes, oracle stability gate. Once set, every payment by this agent is checked against the policy automatically via policy.check.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesHuman-readable policy name
agent_idYesStable identifier for the agent or org (wallet address, session prefix, org slug, etc.)
max_per_txNoUSD ceiling per single transaction. Payments above this are BLOCKED.
max_per_dayNoUSD rolling daily ceiling. Payments that would exceed this are HOLDed.
blocked_regionsNoISO 3166-1 alpha-2 country codes to block.
allowed_purposesNoIf set, only payments with a purpose in this list are allowed.
require_hold_aboveNoRoute to HOLD queue for human review if amount exceeds this threshold.
require_oracle_stableNoIf true, HOLD on CAUTION as well as UNSTABLE oracle status.
blocked_counterpartiesNoWallet addresses or LEIs to block.

TDQS

A4/5.0
Behavior4/5

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

The description reveals the key behavioral side effect: once set, every payment by the agent is automatically checked against the policy via policy.check. It also lists the rules applied. However, it does not mention whether the policy is immediately effective, if it can be updated, or any prerequisites (e.g., the agent must exist). Annotations already indicate it is not read-only, consistent with the write operation.

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 three sentences, each adding value: states purpose, lists rules, links to policy.check. It is front-loaded with the key action and perfectly efficient with no wasted words.

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

Completeness4/5

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

Given 9 parameters (100% schema coverage), no output schema, and minimal annotations, the description is fairly complete. It explains the purpose and side effect. It could be more complete by clarifying the lifecycle (e.g., can policies be updated?) or that some parameters are optional, but the schema already handles that. The description suffices for a create tool.

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 baseline is 3. The description summarizes the rules (per-transaction ceiling, daily limit, etc.) roughly corresponding to parameters, but does not add new meaning beyond what the schema already provides. It offers a high-level overview but no extra details.

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 spending policy for an AI agent, listing specific rules it sets (per-transaction ceiling, daily limit, etc.). It distinguishes from the sibling 'policy.check' by explaining that payments are checked against the policy automatically via that tool.

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?

The description implies the tool is used to set up policies before payments, but it does not explicitly state when to use this tool versus alternatives like 'policy.delegate' or provide conditions for when not to use it. No exclusion guidance is given.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, especially within their domains (e.g., analytics, compliance, ESG, forecasting). However, a few tools like route and stability.stablecoin_route or settlement.quote and fx.cost_certainty may cause confusion despite distinct descriptions, and the large number of intelligence tools (cascade, aftershock, contagion, etc.) could lead to misselection without careful reading.

Naming Consistency3/5

Naming follows a domain prefix pattern (e.g., agent.kya_register, settlement.quote, esg.score), which provides some structure. However, inconsistencies exist: some tools use underscores (batch_settle, flow_check), others are single words (route), and the mix of verb_noun and noun_verb styles (e.g., compliance.pep_screen vs market.fx) reduces predictability.

Tool Count3/5

At 71 tools, the server is very broad in scope, covering compliance, ESG, forecasting, intelligence, treasury management, and more. While each tool seems justified for the complex institutional domain, the sheer number may overwhelm agents and makes the set feel bloated. A more focused scope or tighter tool grouping would improve appropriateness.

Completeness4/5

The tool surface is remarkably comprehensive for cross-border settlement, covering end-to-end workflow from quoting, FX analysis, compliance screening, ESG scoring, forecasting, and multiple payment rails (Mercury, Ramp, SWIFT). Minor gaps exist (e.g., no tool to update a settlement after execution), but core operations are well-covered, and the addition of integration and audit trails enhances completeness.

Resources