Signo

Draft a Signo Shield permission (Execute) for the owner to sign

signo_draft_permission

Draft an Execute agent on a deployed Shield chain: when something happens on the owner's wallet, do one action with its funds, inside caps the owner signs on chain (the Shield contract). Inactive until the owner signs on the review link it returns (review_url; also proposal_id, summary, limits, fee_bps, expires_at). No API key. New Execute setup is in early access: a wallet without access no longer gets 403 execute_team_only: no proposal is stored, and the response is a Prepare agent draft for the same trigger and action instead (status 'draft', fallback.from 'execute', its own review_url). The owner activates it and signs each plan, and can join the Execute waitlist in the Signo app.

Collect: wallet; trigger; action; cap_per (most per execution); budget (lifetime, before fees; the fee comes on top); expiry_days optional, default 30. The wallet need not hold the budget yet.

Trigger: { kind: "condition", request } for a supported plain-English Execute condition, e.g. "when XETH drops 10% in 24 hours" (what the Shield cannot read, the hourly check decides); or health_factor, token_balance or price, re-checked on chain, e.g. { kind: "price", asset: "XETH", comparator: "<", value: 3000 }. Execute is not available for the app's Portfolio move trigger; boxed Pendle PT loops are notify-only today, and a recurring schedule is not an Execute trigger.

Action: transfer, swap (OKX DEX; one of min_out or max_slippage_bps), vault (ERC-4626), supply (Aave), repay_from_wallet, repay_from_collateral. Assets by symbol or address. Fee 10 bps per firing.

Enforced on chain: the Shield re-checks caps, expiry and readable triggers each firing and pulls funds via the owner's allowance; the executor key is held in Google Cloud KMS and usable only by Signo's production service. Checked hourly; one successful execution completes a trigger by default, and public drafts do not opt into repay-from-collateral continuation. The signing service allows at most two attempts for one permission in a rolling hour. A successful firing reports Goal, Done, Remaining, Reasoning and Next. Each firing is an on-chain tx; revocable on the Agents page. No keyless status read yet.

Input Schema

TableJSON Schema

Name	Required	Description
`action`	Yes	What a firing does: transfer (to a fixed recipient), swap (through OKX DEX; exactly one of min_out or max_slippage_bps), vault (ERC-4626 deposit), supply (into Aave), repay_from_wallet (repay Aave debt from the wallet's balance), repay_from_collateral (repay Aave debt by selling collateral to a target health factor).
`budget`	Yes	Lifetime input-token budget, before fees. The Signo fee comes on top: the permission is registered with room for it, so 50 lifetime and 5 per execution allows ten full executions. The wallet does not need to hold it yet; each execution checks the balance for that execution. Must be at least cap_per, and may equal it.
`wallet`	Yes	The owner's EVM wallet; only this wallet can sign the permission on the review page. It does not need to hold the budget yet: each firing checks the balance then.
`cap_per`	Yes	Maximum input-token spend per execution, before the fee. At most budget.
`trigger`	Yes	When it fires: a supported plain-English Execute condition (the part the Shield can read is pinned and re-checked on chain; the rest is decided by the hourly check), or one of three typed triggers the Shield reads on chain: health_factor (the wallet's Aave health factor), token_balance (the wallet's balance of an asset), price (the asset's current USD price from the Aave oracle on the selected chain, Chainlink-backed; a current price only, never a move over a window), each with a comparator and a value. Execute is not available for the app's Portfolio move trigger; boxed Pendle PT loops are notify-only today. A recurring schedule is not an Execute trigger. A crossing fires once; it re-arms when the condition goes false again.
`chain_id`	Yes	A deployed Shield chain id, returned by GET /api/shield/compile.
`expiry_days`	No	Days until the permission can no longer fire, 1 to 90.
`schema_version`	Yes	Always 2.

Output Schema

TableJSON Schema

Name	Required	Description
`action`	No	For a Prepare agent, the step it prepares when it fires.
`limits`	No	The permission's limits: per execution, lifetime, expiry.
`status`	Yes	"draft" for an inactive agent draft, "proposed" for a stored Execute permission proposal.
`wallet`	No	The owner wallet, or null when the first wallet to sign claims it.
`cadence`	No	How often the condition is checked.
`fee_bps`	No	Signo's fee per firing, in basis points.
`summary`	No	The trigger (and action) in plain English.
`autonomy`	No	"notify" or "prepare".
`fallback`	No	Present when the wallet has no Execute early access: a Prepare agent draft was made instead (from "execute" to "prepare").
`activation`	No	What the owner must do before anything runs.
`expires_at`	No	When the draft or proposal expires, in ms since epoch.
`review_url`	Yes	Private link for the wallet owner: review, connect the wallet, and sign once to turn it on.
`proposal_id`	Yes	The draft's id.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "action": {
+      "description": "For a Prepare agent, the step it prepares when it fires.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "activation": {
+      "description": "What the owner must do before anything runs.",
+      "type": "string"
+    },
+    "autonomy": {
+      "description": "\"notify\" or \"prepare\".",
+      "type": "string"
+    },
+    "cadence": {
+      "description": "How often the condition is checked.",
+      "type": "string"
+    },
+    "expires_at": {
+      "description": "When the draft or proposal expires, in ms since epoch.",
+      "type": "number"
+    },
+    "fallback": {
+      "additionalProperties": true,
+      "description": "Present when the wallet has no Execute early access: a Prepare agent draft was made instead (from \"execute\" to \"prepare\").",
+      "properties": {
+        "from": {
+          "type": "string"
+        },
+        "note": {
+          "type": "string"
+        },
+        "reason": {
+          "type": "string"
+        },
+        "to": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "from",
+        "to",
+        "reason",
+        "note"
+      ],
+      "type": "object"
+    },
+    "fee_bps": {
+      "description": "Signo's fee per firing, in basis points.",
+      "type": "number"
+    },
+    "limits": {
+      "description": "The permission's limits: per execution, lifetime, expiry."
+    },
+    "proposal_id": {
+      "description": "The draft's id.",
+      "type": "string"
+    },
+    "review_url": {
+      "description": "Private link for the wallet owner: review, connect the wallet, and sign once to turn it on.",
+      "type": "string"
+    },
+    "status": {
+      "description": "\"draft\" for an inactive agent draft, \"proposed\" for a stored Execute permission proposal.",
+      "type": "string"
+    },
+    "summary": {
+      "description": "The trigger (and action) in plain English.",
+      "type": "string"
+    },
+    "wallet": {
+      "description": "The owner wallet, or null when the first wallet to sign claims it.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "proposal_id",
+    "review_url",
+    "status"
+  ],
+  "type": "object"
+}

First observedOct 15, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With annotations already declaring readOnlyHint=false and destructiveHint=false, the description still adds substantial behavioral context: no API key required, the 403 execute_team_only early-access fallback that returns a Prepare draft instead, on-chain enforcement of caps/expiry/triggers, KMS-held executor key, hourly checks, the two-attempts-per-rolling-hour signing limit, 10 bps fee per firing, and revocability. This is far beyond what the annotations convey.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is a dense multi-paragraph wall that restates schema content (action kinds, trigger kinds, budget/fee semantics) and piles on enforcement detail. Most sentences earn their place individually, yet the whole is longer than needed given the schema already carries the parameter contract.

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?

For a complex, 8-parameter, on-chain-action drafting tool it covers the ground an agent needs: trigger/action vocabularies, caps and fee model, activation flow via review_url, fallback behavior, and enforcement/rate constraints. An output schema exists (so return values needn't be explained), yet the description still lists key response fields usefully.

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 'Collect: …' sentence does clarify budget as lifetime-before-fees with the fee on top and notes the wallet need not hold the budget, but most of that is already stated in the schema's own field descriptions, and the action/trigger-kind enumerations largely mirror the schema's anyOf descriptions.

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 opening states a specific verb+resource+scope: 'Draft an Execute agent on a deployed Shield chain,' and immediately describes what that permission does ('when something happens on the owner's wallet, do one action with its funds'). It is clearly an Execute-specific drafting tool, distinguishable from signo_draft_agent's Prepare-agent domain which is only referenced obliquely via the fallback behavior, so sibling differentiation is present but not explicit.

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

Usage Guidelines4/5

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

The description gives strong when-not guidance: Execute is not available for the Portfolio move trigger, boxed Pendle PT loops are notify-only, and recurring schedules are not Execute triggers. It also covers the early-access fallback path. It never explicitly names the alternative tool (signo_draft_agent) for the non-Execute case, so it stops short of full when/when-not/alternatives routing.

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

All Signo 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.