Moneda

create_agent_session

Create a scoped autonomous payment session bound to your agent. The user pre-funds a dedicated child Safe and installs an on-chain spending policy (single pinned recipient, per-execution and per-period caps) with a passkey in the Moneda app. After that you can call agent_execute_payment repeatedly within the policy — no per-payment approval. This call does NOT activate the session: it returns a counterfactual child Safe address and an activation deep link the user must open in the Moneda app. Poll get_agent_session until status is ACTIVE before executing.

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": {
      "recipient": "<recipient>",
      "currency": "<currency>",
      "maxAmountPerExecution": "<maxAmountPerExecution>",
      "maxAmountPerPeriod": "<maxAmountPerPeriod>",
      "periodSeconds": "<periodSeconds>"
    },
    "name": "create_agent_session"
  }
}

Input Schema

Name	Required	Description
`currency`	Yes	Stablecoin denomination for the session (USD or EUR).
`expiresAt`	No	Optional ISO-8601 expiry. After this, executions are rejected and the session can no longer be used.
`recipient`	Yes	The single crypto recipient address (0x…) pinned for this session. Phase 1 is crypto-to-crypto; every execution must go to this address.
`fundingAmount`	No	Optional initial parent→child funding amount, in user-facing units. The child Safe balance is the hard ceiling on worst-case loss.
`periodSeconds`	Yes	Length of the spending period in seconds (e.g. 86400 for a daily cap).
`maxAmountPerPeriod`	Yes	Max total spend per rolling period, in user-facing units (e.g. '100.00'). Must be > 0.
`maxAmountPerExecution`	Yes	Max per single payment, in user-facing units (e.g. '25.00'). Must be > 0 and ≤ maxAmountPerPeriod.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes well beyond by disclosing that the call does NOT activate the session and returns a counterfactual address plus an activation deep link requiring user action. That is exactly the non-obvious behavior an agent would otherwise get wrong on first call.

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 purpose and the counterintuitive non-activation caveat are front-loaded, and each subsequent sentence carries distinct information: prerequisites, downstream reuse, return values, polling requirement. No sentence is redundant with the schema or annotations.

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

Completeness5/5

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

With no output schema, the description still covers what the call returns and what the agent must do next, and it documents the human-in-the-loop activation step. For a 7-parameter write tool this is complete enough to invoke correctly on the first try.

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 currency, recipient, caps, period and expiresAt are already fully documented. The description restates the policy shape ('single pinned recipient, per-execution and per-period caps') but adds no syntax, units, or edge-case detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('create a scoped autonomous payment session bound to your agent') and immediately scopes it against siblings: agent_execute_payment for spending and get_agent_session for status polling. An agent can distinguish this from every other payment tool without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit preconditions (user pre-funds a child Safe and installs an on-chain policy with a passkey in the Moneda app) and explicit follow-up (poll get_agent_session until ACTIVE before executing). It also names the downstream alternative the session exists to enable: agent_execute_payment with no per-payment approval.

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

All Moneda tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?