Pre-flight regulatory check. Returns PASS/WARN/BLOCK with reason_codes, sources, confidence. Checks MiCA authorization, evidence quality, custody risk in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Action: swap, transfer, custody | swap |
| jurisdiction | No | Jurisdiction: EU, US, UK | EU |
| token_symbol | Yes | Token symbol e.g. USDC, RLUSD, USDT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return envelope (PASS/WARN/BLOCK with reason_codes, sources, confidence) and the evaluation dimensions. While it doesn't mention side effects, permissions, or rate limits, the read-only nature is strongly implied by 'pre-flight check' and the output description, providing adequate transparency for a non-mutating 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?
Two sentences, zero filler. The first sentence front-loads the purpose and output format; the second clarifies the exact checks included. Every word earns its place, achieving high information density.
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 3-param tool with no output schema, the description covers the core functional contract: what it returns and what it evaluates. It lacks some positional context relative to siblings (e.g., why choose this over mica_full_pack or custody_risk), but the 'in one call' note partially addresses that. The missing output schema is mitigated by describing the key response fields.
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 baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides; it mentions the three check categories but does not map them to action, jurisdiction, or token_symbol. Nonetheless, the schema descriptions are sufficient, so no exceptional credit or penalty is warranted.
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 performs a 'Pre-flight regulatory check' and specifies its output (PASS/WARN/BLOCK with reason_codes, sources, confidence). It enumerates the checks covered (MiCA authorization, evidence quality, custody risk), which distinguishes it from more focused siblings like custody_risk or mica_status.
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 phrase 'Pre-flight' establishes a clear temporal context (use before an action/transaction). 'Checks ... in one call' implies it is a combined alternative to invoking multiple individual tools. However, it does not explicitly name alternatives or state when NOT to use it, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool has a clearly distinct target: peg_deviation vs peg_history, mica_status vs mica_market_overview, audit_log/query/verify, and evidence_profile/bundle/leaderboard are all differentiated by their descriptions. No two tools appear to perform the same function.
All tools use lowercase snake_case with a consistent domain-prefix pattern (e.g., audit_*, mica_*, peg_*, evidence_*). There is no camelCase or mixed verb styles, making the naming predictable and easy to navigate.
With 25 tools, the server is at the upper boundary of the borderline range. The broad MiCA and compliance domain justifies many tools, but the count feels heavy, and some tools like rlusd_integrity are very specific to a single asset.
The server covers the core compliance workflow: authorization checks, peg and reserve monitoring, liquidity, evidence scoring, audit trails, and AI explainability. Minor gaps exist, such as no direct tool for generating a consolidated compliance report or scheduling recurring checks, but the main surface is well-covered.