Signo

Draft a Signo agent (Notify or Prepare) for the owner to claim

signo_draft_agent

Draft a complete inactive Notify or Prepare agent, without an API key. Name the owner wallet when you know it; omit it and the first wallet to sign on the review page owns the agent. It can watch anything the app can: a price threshold or percent move, portfolio movement, a lending health factor (Aave, Spark, Compound V3, Morpho), the owner's own DeFi positions (PTs, LPs, supplied assets, claimables, APY or value changes, days to expiry), Pendle loops, a daily market brief, a recurring schedule (daily, weekly or monthly at a set time, or hourly checks) or any plain-English condition the compiler accepts. Execute is a separate permission flow with its own supported conditions and typed on-chain triggers; Execute is not available for the app's Portfolio move trigger, boxed Pendle PT loops are notify-only, and recurring schedules are not Execute triggers today. Returns a private review_url plus summary, cadence (hourly or daily checks), autonomy, action and expires_at in unix milliseconds. The owner opens the link, connects that wallet, links Telegram and signs once to create the agent. Set autonomy to prepare for an action request; otherwise it is refused as autonomy_mismatch, not silently downgraded. Prepare builds an unsigned plan on each fire; it never spends automatically. No clarification round trip: an ambiguous or unwatchable request is a 422 with the reason, so rephrase and call again. Keyless has no agent-status read yet: the owner sees fires on the Agents page and on Telegram. Automatic execution is the separate signo_draft_permission tool.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`wallet`	No	Optional. The owner's EVM (0x…) or Solana address, when you know it: then only that wallet can claim the draft. Omit it and the draft is bound to the first wallet that signs on the review page.
`request`	Yes	The complete condition or recurring schedule in plain English, 8 to 2000 characters, and for Prepare the action to run when it fires. There is no clarification round trip: an ambiguous or unwatchable request is a 422 with the reason, so rephrase and call again.
`autonomy`	No	notify (default): the owner is told when it fires. prepare: the action in the request is stored and pre-planned on fire as an unsigned plan for the owner to sign. A request that includes an action must explicitly choose prepare; otherwise it is refused as autonomy_mismatch, not silently downgraded. Execute is not available here; it needs a Shield mandate.	notify

Output Schema

TableJSON Schema

Name	Required	Description
`action`	No	For a Prepare agent, the step it prepares when it fires.
`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.
`summary`	No	The trigger (and action) in plain English.
`autonomy`	No	"notify" or "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"
+    },
+    "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.6/5.0

Behavior5/5

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

Annotations only declare the generic mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds substantial context beyond them: keyless operation with no agent-status read, the private review_url claim flow (connect wallet, link Telegram, sign once), the 422-no-clarification behavior, the autonomy_mismatch refusal, and that prepare builds an unsigned plan and never spends. This is exactly the kind of side-effect and prerequisite disclosure the annotations cannot carry.

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?

Front-loaded with the core action and the claim mechanic before the supported-condition catalog. It is dense and mostly earns its length, though it carries mild redundancy (the Execute exclusion is stated twice, once mid-text and once as the closing pointer to signo_draft_permission, and the 422 rule is echoed from the schema).

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?

An output schema exists, yet the description still usefully summarizes the return shape (review_url, summary, cadence, autonomy, action, expires_at in unix ms) and covers the full lifecycle: what is created, how it is claimed, what happens on fire, and the keyless visibility limitation. Nothing needed to call it correctly 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 description coverage is 100%, so the baseline is 3; the schema already documents wallet claiming, the 8-2000 char request, the 422 behavior, and the notify/prepare enum. The description largely restates these (owner-wallet binding, autonomy semantics, 422 rephrase) rather than adding format or syntax detail the schema lacks.

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 ('Draft a complete inactive Notify or Prepare agent') and immediately scopes it ('without an API key'). It explicitly names and distinguishes the sibling flow ('Automatic execution is the separate signo_draft_permission tool'), so an agent can separate it from signo_draft_permission without opening either 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 when-to-use guidance for both modes: notify vs prepare, including the refusal rule ('A request that includes an action must explicitly choose prepare; otherwise it is refused as autonomy_mismatch'). It also carves out exclusions (Execute not available, boxed Pendle PT loops notify-only, recurring schedules not Execute triggers) and routes to the alternative tool.

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.