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 (hourly, daily, weekly or monthly) 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, daily, weekly or monthly), 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

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

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 safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false); the description carries the real behavioral load: drafts are inactive and keyless, ownership binds to the first signing wallet, an action request without autonomy=prepare is refused as autonomy_mismatch rather than downgraded, ambiguous requests return 422 with no clarification round trip, and there is no agent-status read yet. That is far beyond what annotations provide.

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 purpose and ownership model, and every clause is substantive. It loses a point for internal repetition: the 422 no-clarification rule and the autonomy_mismatch behavior each appear twice, inflating a single dense paragraph.

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?

Covers the full lifecycle an agent needs: drafting, the private review_url claim flow, Telegram linking, what is returned (review_url, summary, cadence, autonomy, action, expires_at), and the known limitation that keyless drafts have no status read. Complete for a 3-parameter draft tool even before accounting for the output schema.

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% and the field text already explains the wallet binding rule and the autonomy_mismatch refusal, so the description largely restates structured data rather than adding syntax or format detail. The only marginal addition is framing autonomy as a cross-parameter consequence of whether the request contains an action, which earns the baseline rather than more.

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?

Opens with a specific verb+resource+state: 'Draft a complete inactive Notify or Prepare agent, without an API key.' It immediately distinguishes itself from the sibling signo_draft_permission ('Automatic execution is the separate signo_draft_permission tool'), so an agent can pick between them 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?

Explicit about when this applies and when it does not: it enumerates watchable condition families, names execute-only exclusions (Portfolio move trigger, boxed Pendle PT loops, recurring schedules are not Execute triggers today), and routes execution to signo_draft_permission. The wallet-present vs wallet-omitted branch is also spelled out as a usage decision.

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.