Skip to main content
Glama

Signo

by fi.signo
OverviewDiscussionsAdmin

Server Details

AI agents that watch DeFi positions: read a wallet report, draft agents for the owner to sign.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
FlipLabsAI/signo-mcp
GitHub Stars
0

TDQS

A4/5.0

Scored across 3 tools

Disambiguation3/5

signo_draft_agent and signo_draft_permission both create agents and overlap conceptually, made worse by the documented fallback where a permission request silently returns a Prepare agent draft instead. wallet_insights_report is clearly distinct as a read-only analysis tool, but the two draft tools require careful reading to separate.

Naming Consistency3/5

The tools use a verb_noun flavor (draft_agent, draft_permission, insights_report), but two carry a signo_ prefix while wallet_insights_report does not, breaking the pattern. Conventions are mixed yet still readable.

Tool Count4/5

Three tools is a bit thin but defensible for a focused agent-drafting plus wallet-analysis surface. Each tool earns its place, though the small set leaves little room for lifecycle operations.

Completeness3/5

The surface covers drafting (both Prepare and Execute) and read-only analysis, but the description itself admits there is 'no keyless status read yet,' so created agents cannot be queried, updated, or deleted through the tools. This leaves create-only coverage with notable gaps in the agent lifecycle.

Available Tools

3 tools
signo_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 (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.

ParametersJSON Schema
NameRequiredDescriptionDefault
walletNoOptional. 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.
requestYesThe 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.
autonomyNonotify (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

ParametersJSON Schema
NameRequiredDescription
actionNoFor a Prepare agent, the step it prepares when it fires.
statusYes"draft" for an inactive agent draft, "proposed" for a stored Execute permission proposal.
walletNoThe owner wallet, or null when the first wallet to sign claims it.
cadenceNoHow often the condition is checked.
summaryNoThe trigger (and action) in plain English.
autonomyNo"notify" or "prepare".
activationNoWhat the owner must do before anything runs.
expires_atNoWhen the draft or proposal expires, in ms since epoch.
review_urlYesPrivate link for the wallet owner: review, connect the wallet, and sign once to turn it on.
proposal_idYesThe draft's id.

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.

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesWhat 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).
budgetYesLifetime 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.
walletYesThe 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_perYesMaximum input-token spend per execution, before the fee. At most budget.
triggerYesWhen 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_idYesA deployed Shield chain id, returned by GET /api/shield/compile.
expiry_daysNoDays until the permission can no longer fire, 1 to 90.
schema_versionYesAlways 2.

Output Schema

ParametersJSON Schema
NameRequiredDescription
actionNoFor a Prepare agent, the step it prepares when it fires.
limitsNoThe permission's limits: per execution, lifetime, expiry.
statusYes"draft" for an inactive agent draft, "proposed" for a stored Execute permission proposal.
walletNoThe owner wallet, or null when the first wallet to sign claims it.
cadenceNoHow often the condition is checked.
fee_bpsNoSigno's fee per firing, in basis points.
summaryNoThe trigger (and action) in plain English.
autonomyNo"notify" or "prepare".
fallbackNoPresent when the wallet has no Execute early access: a Prepare agent draft was made instead (from "execute" to "prepare").
activationNoWhat the owner must do before anything runs.
expires_atNoWhen the draft or proposal expires, in ms since epoch.
review_urlYesPrivate link for the wallet owner: review, connect the wallet, and sign once to turn it on.
proposal_idYesThe draft's id.

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.

wallet_insights_reportSigno: wallet insights reportA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesThe wallet to analyze — an EVM address (0x + 40 hex) or a Solana base58 address.
narrativeNoInclude a written plain-English summary alongside the structured findings. Slower; defaults to false.

Output Schema

ParametersJSON Schema
NameRequiredDescription
chainNo
addressNo
holdingsNoEvery chain's tokens, DeFi positions and loans with USD values.
draftWithNoExact arguments for signo_draft_agent on this host.
narrativeNo
walletAgeNo
categoriesYesFindings: state, headline, detail, next step, and agentSuggestion where an agent fits.
signoScoreYes0-100: how well the wallet's capital is managed; null when nothing could be read.
generatedAtNo
zeroActivityNo
riskToleranceNo
netPortfolioUsdNo
suggestedAgentsNo

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 3 tool updates
    • Changedsigno_draft_agent1 field changed
      • 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"
+}
    • Changedsigno_draft_permission1 field changed
      • 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"
+}
    • Changedwallet_insights_report1 field changed
      • changedOutput 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"
+}
  2. 3 tool updates
    • First observedsigno_draft_agent
    • First observedsigno_draft_permission
    • First observedwallet_insights_report

Related MCP Connectors

Related MCP Servers

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