Skip to main content
Glama

SwapEazi

Hold a map to constraints

check_constraints
Read-only

Re-evaluate every candidate in a stored Options Map against constraints supplied now: the principal's own policy, an AP2 open (intent) mandate, a Verifiable Intent credential, or x402 payment requirements (accepts[] with the listed price, verified against the reference). Each row comes back inside, outside or unknown, and carries the map's own route_family, regulatory_risk and onboarding_status/onboarding_gap for that candidate, so an agent can drop ineligible or blocked rows without a second call. Nothing is executed or issued. Free.

Input Schema

NameRequiredDescriptionDefault
x402No{ accepts: PaymentRequirements[], price: { currency, amount } }.
map_idYesThe map_id from map_options.
policy_idNoA release policy of this organisation (needs its key): supplies the limit and the map-age rule.
ap2_mandateNoAn AP2 intent mandate; recognised fields are read, the rest listed as unevaluable.
constraintsNomax_all_in_bps_vs_ref, max_settlement_days, allowed_rail_classes, disallowed_providers, must_include_provider_id, allowed_providers (restrict every row to your own already-connected panel, by provider id or name — a candidate outside it evaluates outside, never hidden; for embedding this assessment as a mandatory step inside your own already-licensed payment run, the way an EMS asks which of its own connected brokers should carry an order), corporate_only. Stablecoin risk appetite, the client's own thresholds held to each token's dated profile (/stablecoins): stablecoin_attestation_max_age_days, stablecoin_peg_min_share_within_50bps (0 to 1, last 30 days), stablecoin_peg_max_worst_bps (last 30 days), stablecoin_exit_depth_covers_amount (true), stablecoin_supervised_in (ISO codes or EU), stablecoin_no_single_key_mint_freeze (true). A fact not on record makes the row unknown, never inside.
verifiable_intentNoA Verifiable Intent credential: the serialised SD-JWT, or decoded mandate objects. Amount limits and expiry are held to the intent; where the payment crosses currencies, the result says the mandate does not bound the conversion cost.
instrument_classes_allowedNoOptional. Only these instruments are inside: spot, forward or stablecoin_rail. Default: all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / instrument_classes_allowed / description
      Added value: +"Optional. Only these instruments are inside: spot, forward or stablecoin_rail. Default: all."
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only and closed-world safety, and the description adds genuinely new behavior: each row is labelled inside/outside/unknown with enrichment fields so no second call is needed, and 'a fact not on record makes the row unknown, never inside' documents the fail-safe default. It also explicitly states nothing is executed or issued and that the call is free. Return shape is described despite no output schema, though pagination or row limits are unmentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences: the first states what is evaluated against what, the second states what comes back and why it matters. The lead is front-loaded and there is no filler. The long enumeration of constraint sources in the first sentence is heavy but earns its place for scope setting.

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 a 7-parameter tool with nested objects and no output schema, the description does the important work: it names the evaluation modes, describes the per-row verdict and enrichment fields, and states the safe default. Minor gaps remain around cost, bulk behavior and limits, but nothing essential for correct invocation is missing.

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 coverage is 100%, so the schema documents every parameter in detail. The description only gestures at the constraint sources (own policy, AP2 mandate, Verifiable Intent, x402 accepts with price) and repeats the unknown-not-inside rule already present in the schema. It adds little meaning beyond what the structured fields already carry, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: re-evaluate every candidate in a stored Options Map against newly supplied constraints. An agent can tell this is a batch re-scoring pass over an existing map, distinct from map_options and the payment-level mandate checks. It stops short of naming any sibling tool explicitly, so differentiation is inferred rather than stated.

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?

Usage is implied (call after map_options, before running a payment, to drop blocked rows without a second call), and the benefit of batching is clear. However, with many similar-sounding siblings such as check_payment_against_mandate and assess_route, the description never states when to prefer this tool over those, nor any when-not conditions.

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.

Resources