Signo
Server Details
AI agents that watch DeFi positions: read a wallet report, draft agents for the owner to sign.
- Status
- Healthy
- Uptime
- 99.9% over 25 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- FlipLabsAI/signo-mcp
- GitHub Stars
- 0
- Server Listing
- Signo MCP Server
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 3 tools
The three tools split along clear lines: drafting a Notify/Prepare agent, drafting an Execute (Shield) permission, and read-only wallet analysis. The two 'draft' tools share a verb and both produce review links, which could momentarily confuse an agent, but the descriptions explicitly distinguish autonomy, triggers, and the early-access fallback between them.
signo_draft_agent and signo_draft_permission follow a signo_ + verb_noun pattern consistently. wallet_insights_report breaks it slightly (no signo_ prefix, noun-first, no verb), but it is still readable and self-descriptive.
Three tools is on the lean side, but each is a heavyweight, well-scoped operation (full agent drafting with parameter validation, Execute permission drafting, and a full wallet report), so nothing feels redundant or missing from the count perspective.
Creation and analysis are covered, but the surface is write-mostly: the descriptions themselves admit there is no agent-status/read tool and revocation happens only via the app's Agents page, so an agent cannot list, inspect, or cancel what it drafted. Lifecycle coverage is a notable gap rather than a fatal one, since review_url flows let the owner finish the loop.
Available Tools
3 toolssigno_draft_agentDraft a Signo agent (Notify or Prepare) for the owner to claimAInspect
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.
| 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. |
TDQS
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.
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.
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.
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.
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.
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.
signo_draft_permissionDraft a Signo Shield permission (Execute) for the owner to signAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the annotations (readOnlyHint=false, destructiveHint=false): the permission is inactive until the owner signs the returned review_url, no API key is needed, an early-access wallet gets a Prepare fallback draft instead of a 403, execution is enforced on chain with a KMS-held executor key, checks run hourly, one success completes the trigger, and the signing service allows two attempts per rolling hour. It also discloses the 10 bps per-firing fee and that firing is revocable on the Agents page. This is exactly the operational context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, but the body is a dense run of comma-spliced sentences mixing operation, fallback behavior, trigger taxonomy, on-chain enforcement and rate limits. Trigger constraints are stated twice (description and schema description), and semicolon-heavy clauses slow parsing. Content earns its place but the packaging does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, multi-branch, 8-parameter mutation tool, the description covers activation state, fallback path, fee model, rate limits, failure semantics and return identifiers. An output schema and 100% schema coverage already handle field-level and return-value detail, so nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description genuinely adds meaning: budget is lifetime and pre-fee with the fee registered on top (50 lifetime / 5 per execution = ten firings), cap_per is per-execution spend, expiry_days defaults to 30, and the wallet need not hold the budget yet. It also summarizes the action and trigger vocabularies and the min_out/max_slippage_bps exclusivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb and resource: 'Draft an Execute agent on a deployed Shield chain', scoped to the owner's wallet, one action, owner-signed caps. It is unambiguous about what is produced (an inactive permission plus review_url). It does not, however, distinguish this from the sibling signo_draft_agent, leaving the agent to infer which draft tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong when-not guidance is present: Execute is unavailable for the Portfolio move trigger, boxed Pendle PT loops are notify-only, and a recurring schedule is not a valid Execute trigger. The 'Collect:' line effectively lists prerequisites. It stops short of naming an alternative tool for the excluded cases or contrasting with signo_draft_agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wallet_insights_reportSigno: wallet insights reportARead-onlyInspect
Analyze any public onchain wallet and return its Signo Score plus prioritized findings. Covers yield left on the table, leverage safety, LP health, idle capital, dust and unclaimed rewards. Read-only: it inspects public chain data and never moves funds, needs no keys, and requires no connected session — so it works on any address you can name, not just one the caller controls. Returns signoScore (0-100, the Signo Score: how well the wallet's capital is managed, from idle cash, yield against the cash benchmark, unclaimed rewards, the leverage guard and dust; it is not a safety or liquidation-risk score). This public tool cannot read the owner's private Agents, so watch coverage is not_applicable with 'Agent coverage isn't shown here' and signoScore omits that category; the signed-in owner's app score can differ. riskTolerance, walletAge, holdings (every chain's tokens, DeFi positions and loans with USD values, largest first, so you can structure your own view), and a categories array where each entry carries state, headline, detail and a suggested next step. Findings that call for an agent carry agentSuggestion, and the report carries suggestedAgents plus draftWith: exact request and autonomy arguments for the sibling signo_draft_agent tool on this host, so you can draft the agent for the wallet owner to activate. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The wallet to analyze — an EVM address (0x + 40 hex) or a Solana base58 address. | |
| narrative | No | Include a written plain-English summary alongside the structured findings. Slower; defaults to false. |
Output Schema
| Name | Required | Description |
|---|---|---|
| chain | No | |
| address | No | |
| holdings | No | Every chain's tokens, DeFi positions and loans with USD values. |
| draftWith | No | Exact arguments for signo_draft_agent on this host. |
| narrative | No | |
| walletAge | No | |
| categories | Yes | Findings: state, headline, detail, next step, and agentSuggestion where an agent fits. |
| signoScore | Yes | 0-100: how well the wallet's capital is managed; null when nothing could be read. |
| generatedAt | No | |
| zeroActivity | No | |
| riskTolerance | No | |
| netPortfolioUsd | No | |
| suggestedAgents | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them — never moves funds, no keys, no session required, free, public-only scope, and the explicit caveat that watch coverage is not_applicable and the owner's app score can differ. It also discloses a limitation of the score itself (not a safety or liquidation-risk score).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and the prose is dense with useful caveats, but it is a single very long paragraph that spends considerable space describing return values even though an output schema exists. It mostly earns its place but is longer than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a read-only, two-param tool with an output schema, the description supplies everything an agent needs: purpose, safety profile, scope limits, score semantics, and the handoff to signo_draft_agent. Return-shape detail is a bonus rather than a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented in the schema (address formats, narrative slowness/default). The description reinforces 'any address you can name' but adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Analyze any public onchain wallet and return its Signo Score plus prioritized findings') and enumerates the analysis categories. It clearly differentiates itself from siblings by positioning signo_draft_agent as the downstream consumer, so an agent can place it in the workflow without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the key selection context — read-only, no keys, no session, works on any address you can name 'not just one the caller controls' — and points to signo_draft_agent for drafting. It lacks an explicit when-not-to-use or a contrast against the owner-app score path beyond noting they can differ.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
signo_draft_permission1 field changed- changed
Input schema / properties / action / anyOfPrevious value: -[ - { - "additionalProperties": false, - "description": "Send the asset to one fixed recipient.", - "properties": { - "asset": { - "description": "The token: the symbol Signo uses on the selected chain (X Layer accepts USDT for USDT0), or a symbol on its token catalog (OKX on X Layer, LI.FI on Arbitrum) (a symbol several tokens share is refused with the candidates so you can pass the address), or its ERC-20 address. Symbols are names, not an allowlist; Aave actions need an Aave reserve.", - "pattern": "^(0x[0-9a-fA-F]{40}|[A-Za-z0-9.$_-]{1,16})$", - "type": "string" - }, - "kind": { - "const": "transfer", - "type": "string" - }, - "recipient": { - "description": "Fixed recipient; never the owner wallet itself.", - "pattern": "^0x[0-9a-fA-F]{40}$", - "type": "string" - } - }, - "required": [ - "kind", - "asset", - "recipient" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "Swap the asset through OKX DEX into token_out.", - "properties": { - "asset": { - "$ref": "#/properties/action/anyOf/0/properties/asset" - }, - "kind": { - "const": "swap", - "type": "string" - }, - "max_slippage_bps": { - "description": "Slippage bound in basis points, 1 to 1000. Give exactly one of min_out or max_slippage_bps.", - "maximum": 1000, - "minimum": 1, - "type": "integer" - }, - "min_out": { - "description": "Output-token floor per execution. Give exactly one of min_out or max_slippage_bps.", - "pattern": "^\\d{1,30}(\\.\\d{1,18})?$", - "type": "string" - }, - "token_out": { - "$ref": "#/properties/action/anyOf/0/properties/asset" - } - }, - "required": [ - "kind", - "asset", - "token_out" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "Deposit the asset into an ERC-4626 vault.", - "properties": { - "asset": { - "$ref": "#/properties/action/anyOf/0/properties/asset", - "description": "The token: the symbol Signo uses on the selected chain (X Layer accepts USDT for USDT0), or a symbol on its token catalog (OKX on X Layer, LI.FI on Arbitrum) (a symbol several tokens share is refused with the candidates so you can pass the address), or its ERC-20 address. Symbols are names, not an allowlist; Aave actions need an Aave reserve." - }, - "kind": { - "const": "vault", - "type": "string" - }, - "max_slippage_bps": { - "default": 0, - "maximum": 1000, - "minimum": 0, - "type": "integer" - }, - "vault": { - "pattern": "^0x[0-9a-fA-F]{40}$", - "type": "string" - } - }, - "required": [ - "kind", - "vault" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "Supply the asset into Aave on the selected chain.", - "properties": { - "asset": { - "$ref": "#/properties/action/anyOf/0/properties/asset" - }, - "kind": { - "const": "supply", - "type": "string" - } - }, - "required": [ - "kind", - "asset" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "Repay Aave debt in the asset from the wallet's own balance.", - "properties": { - "asset": { - "$ref": "#/properties/action/anyOf/0/properties/asset" - }, - "kind": { - "const": "repay_from_wallet", - "type": "string" - } - }, - "required": [ - "kind", - "asset" - ], - "type": "object" - }, - { - "additionalProperties": false, - "description": "Repay Aave debt by swapping the collateral asset, until the health factor reaches the target.", - "properties": { - "collateral": { - "$ref": "#/properties/action/anyOf/0/properties/asset" - }, - "debt": { - "$ref": "#/properties/action/anyOf/0/properties/asset" - }, - "kind": { - "const": "repay_from_collateral", - "type": "string" - }, - "max_slippage_bps": { - "$ref": "#/properties/action/anyOf/1/properties/max_slippage_bps" - }, - "target_health_factor": { - "exclusiveMinimum": 1, - "maximum": 10, - "type": "number" - } - }, - "required": [ - "kind", - "collateral", - "debt", - "target_health_factor" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "description": "Send the asset to one fixed recipient.", + "properties": { + "asset": { + "description": "The token: the symbol Signo uses on the selected chain (X Layer accepts USDT for USDT0), or a symbol on its token catalog (OKX on X Layer, LI.FI on Arbitrum) (a symbol several tokens share is refused with the candidates so you can pass the address), or its ERC-20 address. Symbols are names, not an allowlist; Aave actions need an Aave reserve.", + "pattern": "^(0x[0-9a-fA-F]{40}|[A-Za-z0-9.$_-]{1,16})$", + "type": "string" + }, + "kind": { + "const": "transfer", + "type": "string" + }, + "recipient": { + "description": "Fixed recipient; never the owner wallet itself.", + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + } + }, + "required": [ + "kind", + "asset", + "recipient" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "Swap the asset through OKX DEX into token_out.", + "properties": { + "asset": { + "$ref": "#/properties/action/anyOf/0/properties/asset" + }, + "kind": { + "const": "swap", + "type": "string" + }, + "max_slippage_bps": { + "description": "Slippage bound in basis points, 50 to 1000. Give exactly one of min_out or max_slippage_bps.", + "maximum": 1000, + "minimum": 50, + "type": "integer" + }, + "min_out": { + "description": "Output-token floor per execution. Give exactly one of min_out or max_slippage_bps.", + "pattern": "^\\d{1,30}(\\.\\d{1,18})?$", + "type": "string" + }, + "token_out": { + "$ref": "#/properties/action/anyOf/0/properties/asset" + } + }, + "required": [ + "kind", + "asset", + "token_out" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "Deposit the asset into an ERC-4626 vault.", + "properties": { + "asset": { + "$ref": "#/properties/action/anyOf/0/properties/asset", + "description": "The token: the symbol Signo uses on the selected chain (X Layer accepts USDT for USDT0), or a symbol on its token catalog (OKX on X Layer, LI.FI on Arbitrum) (a symbol several tokens share is refused with the candidates so you can pass the address), or its ERC-20 address. Symbols are names, not an allowlist; Aave actions need an Aave reserve." + }, + "kind": { + "const": "vault", + "type": "string" + }, + "max_slippage_bps": { + "default": 0, + "maximum": 1000, + "minimum": 0, + "type": "integer" + }, + "vault": { + "pattern": "^0x[0-9a-fA-F]{40}$", + "type": "string" + } + }, + "required": [ + "kind", + "vault" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "Supply the asset into Aave on the selected chain.", + "properties": { + "asset": { + "$ref": "#/properties/action/anyOf/0/properties/asset" + }, + "kind": { + "const": "supply", + "type": "string" + } + }, + "required": [ + "kind", + "asset" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "Repay Aave debt in the asset from the wallet's own balance.", + "properties": { + "asset": { + "$ref": "#/properties/action/anyOf/0/properties/asset" + }, + "kind": { + "const": "repay_from_wallet", + "type": "string" + } + }, + "required": [ + "kind", + "asset" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "Repay Aave debt by swapping the collateral asset, until the health factor reaches the target.", + "properties": { + "collateral": { + "$ref": "#/properties/action/anyOf/0/properties/asset" + }, + "debt": { + "$ref": "#/properties/action/anyOf/0/properties/asset" + }, + "kind": { + "const": "repay_from_collateral", + "type": "string" + }, + "max_slippage_bps": { + "$ref": "#/properties/action/anyOf/1/properties/max_slippage_bps", + "description": "Slippage bound in basis points, 50 to 1000. When omitted, defaults to 100 on X Layer and 50 on Arbitrum." + }, + "target_health_factor": { + "exclusiveMinimum": 1, + "maximum": 10, + "type": "number" + } + }, + "required": [ + "kind", + "collateral", + "debt", + "target_health_factor" + ], + "type": "object" + } +]
3 tool updates
- Changed
signo_draft_agent1 field changed- changed
Output 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" +}
- Changed
signo_draft_permission1 field changed- changed
Output 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" +}
- Changed
wallet_insights_report1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "address": { + "type": "string" + }, + "categories": { + "description": "Findings: state, headline, detail, next step, and agentSuggestion where an agent fits.", + "items": {}, + "type": "array" + }, + "chain": { + "type": "string" + }, + "draftWith": { + "description": "Exact arguments for signo_draft_agent on this host." + }, + "generatedAt": { + "type": "number" + }, + "holdings": { + "description": "Every chain's tokens, DeFi positions and loans with USD values." + }, + "narrative": {}, + "netPortfolioUsd": { + "type": "number" + }, + "riskTolerance": {}, + "signoScore": { + "description": "0-100: how well the wallet's capital is managed; null when nothing could be read.", + "type": [ + "number", + "null" + ] + }, + "suggestedAgents": { + "items": {}, + "type": "array" + }, + "walletAge": {}, + "zeroActivity": { + "type": "boolean" + } + }, + "required": [ + "signoScore", + "categories" + ], + "type": "object" +}
3 tool updates
- First observed
signo_draft_agent - First observed
signo_draft_permission - First observed
wallet_insights_report
Related MCP Connectors
Discover DeFi yield opportunities and manage Zyfai positions with self-custodial AI agents.
Recurring wallet, USDC and ERC-20 monitoring for autonomous agents.
Crypto wallet for AI agents: balances, payments, swaps and trading with owner controls.
Read-only watchtower for AI agents on-chain: decoded receipts, plan vs execution, Safe audits.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to analyze Ethereum wallets, simulate transactions, and draft transfers with deterministic policy and risk scoring, requiring human approval before on-chain execution.12 npmISC
- AlicenseNot gradedqualityDmaintenanceAutonomous AI agent monitoring X Layer DeFi protocols via real RPC calls, providing MCP tools for pool scanning, anomaly detection, risk scoring, alerts, position health checks, and audit trails.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to query multichain balances, inspect smart contracts, and draft DeFi interactions while enforcing anti-drainer protections such as approval blocking, destination whitelisting, spend caps, and human approval gates.11 npmMIT
- FlicenseAqualityDmaintenanceEnables AI agents to discover verifiable DeFi yield opportunities, generate algorithmic portfolio plans, and track cryptographic proof receipts, bridging LLMs with blockchain yield protocols.9-
Glama MCP Gateway
Add one secure layer between your agents and this server.