Eclipse Agent Wallet MCP

set_policy

Defines wallet spending limits by setting per-transaction and daily caps, approval thresholds, recipient allowlists, expiry, and purpose, then returns a liability receipt.

Instructions

The owner grants the spending scope: per-transaction cap, daily cap, approval threshold, recipient allowlist, expiry, purpose. Returns a plain-language liability receipt. Responsibility follows this scope.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wallet_id": "<wallet_id>",
      "per_tx_cap_usdc": "<per_tx_cap_usdc>",
      "daily_cap_usdc": "<daily_cap_usdc>"
    },
    "name": "set_policy"
  }
}

Input Schema

Name	Required	Description	Default
`purpose`	No
`allowlist`	No
`wallet_id`	Yes
`daily_cap_usdc`	Yes
`expires_in_days`	No
`per_tx_cap_usdc`	Yes
`approval_above_usdc`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 29, 2026

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations, the description still contributes real context: it declares the return value ('a plain-language liability receipt') and a semantic consequence ('Responsibility follows this scope'). However, it omits critical mutation behavior — whether an existing policy is overwritten, permission requirements for the owner, and whether setting caps retroactively affects pending payments.

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?

Three compact sentences with the scope enumeration front-loaded, and no filler. It is slightly too terse for a 7-parameter mutation tool, but every sentence earns its place.

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

Completeness2/5

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

A mutation tool with no annotations, no output schema, and 0% schema description coverage demands more than this. The description covers intent, output, and liability framing but leaves authorization, overwrite/idempotency behavior, and parameter formats undocumented anywhere in the definition.

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 0%, so the description must carry parameter meaning, and it does map six of seven fields to concepts (per-transaction cap, daily cap, approval threshold, allowlist, expiry, purpose). It leaves the required wallet_id entirely unmentioned and gives no format guidance for the USDC fields, which the schema types merely as strings.

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?

States a specific action (owner grants a spending scope) and enumerates the policy dimensions being set, which separates it from payment-execution siblings like pay and approve_payment. It never names the wallet explicitly and leaves the 'owner' role unstated relative to how it is derived, but the purpose is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use, when-not-to-use, or alternative routing. The only guidance is implicit in 'The owner grants the spending scope,' which hints at an owner-only prerequisite, and nothing tells the agent how this relates to revoke or what to do when a policy already exists.

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

Deploy Server