Skip to main content
Glama

Ask Anon

ask_anon
Destructive

Send the user's request to Anon, the Hey Anon on-chain AI agent (balances, swaps, bridging, lending, staking, CEX, scheduled automations, research). It can execute transactions and returns a Message ID. Anon plans and executes the operation; you only pass the request on: use the user's own words and language, do not build the transaction, look up routes, compute amounts or split it into steps yourself, and add only what Anon cannot know (wallet addresses, details from earlier in the conversation). Asynchronous: the output is only a confirmation with the Message ID; poll anon_message with that ID (every 2-3 s) until status is "done" (or "failed" / "aborted"), then read the answer from reply and show its cards (anon_message also returns them as HTML for clients that can display it). While it is "running", activity shows the current stage. Clients that support the io.modelcontextprotocol/tasks extension get an MCP task instead and poll it with tasks/get. Anon keeps NO conversation context: every message is processed from a clean slate, so each message must be self-contained (repeat the wallet, network, token and amount every time; follow-ups like "and on Base?" will not work). Before sending, the tool checks that Anon is idle: if the previous request is still processing it returns an error, poll anon_message for the previous Message ID until it is done (or call abort) and retry. Anon can execute real transactions from the attached wallets: send an action request (swap, send, bridge, stake, create an automation) only when the user asked for that action, and never add actions the user did not ask for. For general crypto research not tied to the user wallets, prefer ask_gemma.

Input Schema

NameRequiredDescriptionDefault
textYesThe user's request for Anon in their own words, self-contained (Anon keeps no context), e.g. "What is my S balance on Sonic?" or "Swap 10 USDC to ETH on Base". An action request can make Anon execute a real transaction from the attached wallet: send it only when the user asked for that action, token and amount
filesNoOptional attachments (publicly reachable URL + MIME type), e.g. a screenshot or document for Anon to analyze
walletsYesWallet addresses to attach: at least one, and at most ONE per wallet type (e.g. one evm, one solana, one ton). Two addresses of the same type are rejected by the backend ("Multiple wallets found for type evm"). Take addresses from wallet_list. If the user has several wallets of the same type, use the one the user named (by displayName or address); otherwise ask which one to use rather than picking arbitrarily.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / text / description
      Previous value: -"Natural-language message or instruction for Anon. Phrase information requests as questions, e.g. \"What is my S balance on Sonic?\" or \"Show my Aave positions\". Action instructions such as \"Swap 10 USDC to ETH on Base\" can make Anon execute a real transaction from the attached wallet: send them only when the user explicitly requested that exact action, token and amount"New value: +"The user's request for Anon in their own words, self-contained (Anon keeps no context), e.g. \"What is my S balance on Sonic?\" or \"Swap 10 USDC to ETH on Base\". An action request can make Anon execute a real transaction from the attached wallet: send it only when the user asked for that action, token and amount"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The annotations already flag destructiveHint=true and openWorldHint=true, and the description corroborates that by stating Anon can execute real transactions from attached wallets, so the safety profile and its rationale agree. Beyond that it discloses the asynchronous contract (output is only a Message ID confirmation), the polling cadence (every 2-3 s until 'done', 'failed' or 'aborted'), what 'running' returns, the tasks extension path, and the idle precondition. The statelessness of Anon ('keeps NO conversation context') is a critical behavioral trait an agent could not infer from the annotations.

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?

The structure is front-loaded and logical: purpose, execution semantics, async protocol, statelessness, idle check, safety rule, alternative. Given the number of contracts an agent must honor, most of the length is earned, but the 'no conversation context' point is restated (parenthesis plus a full sentence plus schema text) and the parenthetical card/HTML detail could be tightened.

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?

There is no output schema, and the description compensates fully: it names the returned Message ID, the confirmation shape, the reply and cards fields, and how to render and poll them. Error paths, the idle guard, the task-extension variant and the general-research alternative are all covered, so an agent has everything needed to call it correctly on the first try.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description goes beyond the schema in explaining that 'text' must be self-contained and in the user's own words and must carry wallet, network, token and amount on every message. It also surfaces the one-per-wallet-type constraint enforced by the backend and the displayName-or-ask resolution rule. It does not add much on 'files' beyond what the schema says, which keeps it out of the top band.

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?

The opening sentence names a specific verb and resource (sending a request to the 'Hey Anon' on-chain agent) and enumerates the domains it covers: balances, swaps, bridging, lending, staking, CEX, research and automations. It also separates itself from siblings without ambiguity, e.g. 'For general crypto research not tied to the user wallets, prefer ask_gemma' and the polling handoff to anon_message.

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?

It states when to use (action requests only when the user asked for that action), when not to ('never add actions the user did not ask for', research goes to ask_gemma), and the operational preconditions: the tool errors if the previous request is still processing, so you should poll anon_message or call abort and retry. It also spells out what the caller must NOT do (do not build the transaction, do not look up routes, do not compute amounts, do not split into steps), which is unusually explicit routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.