mcp-server
Server Details
Verify crypto wallets and generate proof of funds letters for buying real estate with crypto.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- realopengroup/mcp-server
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 2.9/5 across 19 of 19 tools scored. Lowest: 1/5.
Most tools have distinct purposes, but there is some overlap between add_wallet and refresh_wallet_verification, as both can generate verification challenges for unverified wallets. Additionally, get_account_status and get_wallet_summary both provide wallet-related information, though their scopes are clarified in descriptions (high-level vs. detailed). Overall, descriptions help differentiate tools, but minor confusion could occur in wallet verification flows.
Tool names follow a consistent verb_noun pattern throughout (e.g., add_wallet, get_account_status, refresh_wallet_balance), with clear and descriptive naming. There are no deviations in style (all snake_case), making the set predictable and readable. The consistency supports easy identification and usage by agents.
With 19 tools, the server is slightly on the higher side but reasonable for its comprehensive domain of crypto-to-real-estate services, covering wallet management, identity verification, marketing, and information retrieval. Each tool appears to serve a specific function without obvious redundancy, though the count might feel heavy for simpler use cases.
The tool set provides complete coverage for the RealOpen platform, including wallet CRUD operations (add, refresh, remove, verify), identity verification, account status, proof-of-funds generation, and extensive informational tools (FAQs, fees, process, assets). There are no apparent gaps; agents can handle end-to-end workflows from onboarding to transaction support without dead ends.
Available Tools
19 toolsadd_walletAIdempotentInspect
Submit a public wallet address for verification. Detects the blockchain, scans on-chain balances, and returns verification options (message signing or dust transfer). Also serves as the retry path: if a previously-added wallet is in a FAILED or unverified state, call this tool again with the same address to get a fresh verification challenge. If the wallet is already verified, the response will indicate that. The response renders an inline Verify Wallet widget showing the verification message (with copy button), the dust-transfer deposit address, and the multi-asset menu; the user clicks through the widget rather than you reading the values aloud. CANCELLED-CALL HANDLING: if a prior invocation of this tool returned no result because the user dismissed or did not approve the client-side consent prompt, simply retry when the user asks again. Do NOT tell the user that the platform or safety checks blocked the action, and do NOT invent a server-side reason — there is no such block on the RealOpen side; it was just a missed consent tap. POST-VERIFY RE-CHECK: the widget runs verify_wallet_signature / verify_wallet_transfer internally via callTool when the user submits from inside it. That silent call does not always produce a visible follow-up in chat — the client can drop the sendFollowUpMessage trigger. If the user says they completed verification, or says the widget shows "verified", or asks to proceed, ALWAYS call get_wallet_summary first to read the fresh ownership_status before answering. Do not tell the user "still not verified" based on your prior tool output — that output is stale the moment the widget is used. PRESENTATION: identify the wallet to the user by its address, never by wallet_id (the UUID is internal — use it only as a parameter to other tools). EVM CHAIN NOTE: 0x... addresses are processed as Ethereum/Polygon/BSC by default. Self-serve verification on Base or Arbitrum is not currently available — if the user explicitly identifies their wallet as being on Base or Arbitrum, tell them: (a) signature verification still works (EVM signatures are chain-agnostic, so signing the message with their Base/Arbitrum wallet will verify successfully), but (b) the dust-transfer method will not work on those chains because the verifier does not yet inspect Base or Arbitrum transactions — they should either use signature verification or contact RealOpen support for manual verification. ZERO-BALANCE NOTE: If total_usd is 0, do NOT assume the wallet is empty. Many wallets use stealth addresses, HD-derived receive addresses, or UTXO shuffling that hide true balance behind the public address. If the response includes a zero_balance_hint, surface that guidance to the user and strongly suggest the test-transfer verification path.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The public wallet address to add |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's not read-only (readOnlyHint: false), open-world (openWorldHint: true), and non-destructive (destructiveHint: false). The description adds valuable context beyond this: it discloses that the tool performs blockchain detection and balance scanning, returns verification options, and includes critical behavioral instructions for presenting results (e.g., providing copy buttons, ensuring precise copying). This enriches the agent's understanding of the tool's behavior and output handling.
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 description is well-structured and concise, with two sentences that efficiently convey purpose, process, and critical instructions. Every sentence adds value: the first explains what the tool does, and the second provides essential usage guidance for results presentation, with no wasted words.
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 the tool's complexity (involving blockchain detection, balance scanning, and verification options), no output schema, and rich annotations, the description is mostly complete. It covers the tool's purpose, behavior, and result-handling instructions. However, it could be more complete by explicitly detailing the verification options or error cases, though the annotations provide some safety context.
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%, with one parameter 'address' fully documented in the schema. The description adds minimal semantics beyond the schema by implying the address is for verification and must be public, but does not provide additional details like format constraints or examples. Baseline 3 is appropriate as the schema carries the primary burden.
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 description clearly states the tool's purpose with specific verbs and resources: 'Submit a public wallet address for verification. Detects the blockchain, scans on-chain balances, and returns verification options (message signing or dust transfer).' It distinguishes from siblings like 'verify_wallet_signature' and 'verify_wallet_transfer' by focusing on initial submission and verification setup rather than execution.
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?
The description provides clear context for when to use this tool: to initiate wallet verification by submitting an address. It implies usage by describing the process and results, but does not explicitly state when not to use it or name alternatives among siblings, such as when to use 'verify_wallet_signature' directly instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_proof_of_fundsAInspect
Generate a Proof of Funds letter (PDF) for the authenticated user. Requires completed identity verification and at least one verified wallet. Returns a download link valid for 30 days. The response renders an inline widget with a thumbnail preview and download/share controls; you do not need to repeat the download URL in your text response — the widget handles presentation. CANCELLED-CALL HANDLING: if a prior invocation returned no result because the user dismissed or did not approve the client-side consent prompt, simply retry when the user asks again. Do NOT tell the user the POF was generated unless this tool actually returned a download_url — if the response is empty or missing, the call did not land and should be retried, not reported as complete. CEILING: the requested amount must be ≤ pof_ceiling_usd from get_wallet_summary; never use total_verified_usd or the sum of wallets[].total_usd as a ceiling — total_verified_usd is pre-haircut (before a volatility/pricing buffer) and the generator will reject amounts above the true ceiling. If unsure of the current ceiling, call get_wallet_summary first.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Requested Proof of Funds amount | |
| currency | No | Currency for the letter (default: USD) | USD |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only, is open-world, and non-destructive. The description adds valuable behavioral context beyond annotations: it specifies the output format ('PDF'), the return type ('download link'), validity period ('valid for 30 days'), and presentation instructions ('prominent clickable download link and a copy button'). This enriches the agent's understanding of the tool's behavior.
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 description is front-loaded with the core purpose in the first sentence, followed by prerequisites, return details, and presentation instructions. Each sentence adds essential information without redundancy, making it efficiently structured and appropriately sized for the tool's complexity.
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 the tool's moderate complexity (2 parameters, no output schema), the description is mostly complete: it covers purpose, prerequisites, output format, and usage instructions. However, it lacks details on error conditions (e.g., what happens if prerequisites aren't met) or how the amount parameter interacts with verified wallets, leaving minor gaps in context.
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%, with clear descriptions for both parameters. The description does not add further meaning to parameters beyond what the schema provides, such as explaining how 'amount' relates to verified wallets or default behaviors. However, the baseline score of 3 is appropriate given the comprehensive schema coverage.
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 description clearly states the specific action ('generate a proof-of-funds letter'), the resource type ('PDF'), and the target ('for the authenticated user'). It distinguishes this from sibling tools like 'get_wallet_summary' or 'search_assets' by focusing on document generation rather than data retrieval or verification processes.
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?
The description explicitly states prerequisites ('requires completed identity verification and at least one verified wallet'), providing clear context for when to use this tool. However, it does not specify when NOT to use it or name alternatives among sibling tools, such as whether 'get_account_status' might be a preliminary check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_statusARead-onlyIdempotentInspect
Returns a high-level account overview: identity verification state, wallet count (not individual wallet details), and Proof of Funds eligibility. DO NOT call this when the user asks for a wallet summary, wallet list, wallet balances, or to see their wallets — use get_wallet_summary for anything wallet-specific. This tool is for answering "is my account ready?"-style questions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read operation. The description adds context about what information is returned (e.g., identity verification status), which is useful but does not disclose additional behavioral traits like rate limits, authentication requirements, or response format details.
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 description is a single, well-structured sentence that efficiently conveys the tool's purpose, scope, and included data points. It is front-loaded with the main action and avoids any unnecessary words or redundant information.
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 the tool's low complexity (0 parameters, no output schema) and rich annotations covering safety and idempotency, the description provides sufficient context by detailing the specific account status information returned. However, it does not explain the return format or potential error conditions, leaving minor gaps in completeness.
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?
The tool has 0 parameters, and schema description coverage is 100%, so there is no need for parameter information in the description. The description appropriately focuses on the tool's purpose and output without redundant parameter details, earning a baseline score of 4 for zero-parameter tools.
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 description clearly states the specific action ('Returns') and resource ('authenticated user's RealOpen account status'), with explicit details on what information is included ('identity verification, wallet summary, and proof-of-funds eligibility'). It distinguishes itself from siblings like 'get_wallet_summary' by covering broader account status beyond just wallet details.
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?
The description implies usage context by specifying it returns 'the authenticated user's' status, suggesting it should be used for checking one's own account rather than others'. However, it does not explicitly state when to use this tool versus alternatives like 'get_wallet_summary' or 'verify_wallet_signature', nor does it provide exclusions or prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_faqDRead-onlyIdempotentInspect
Search RealOpen's frequently asked questions by keyword and/or category. Use this when a user asks a specific question about RealOpen's process, security, timing, taxes, closing, proof of funds, or other product details — returns up to 20 matching entries. When no entries match, responds with the list of available categories so the caller can refine the query. Prefer this over guessing from general knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search keyword or question to find relevant FAQ entries | |
| category | No | Filter by FAQ category (e.g. "Getting Started", "Crypto & Wallets", "Closing Process", "Security & Compliance", "Fees & Taxes", "Proof of Funds", "Differentiators") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fee_structureDRead-onlyIdempotentInspect
Return RealOpen's current pricing and fee breakdown with worked examples. Use this whenever a user asks about RealOpen cost, fees, commissions, or total out-of-pocket — it reflects the live fee schedule and supersedes any estimates from model knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_how_it_worksDRead-onlyIdempotentInspect
Return RealOpen's canonical explanation of how a crypto-to-real-estate transaction works. Use this to answer any question about RealOpen's process, timing, or end-to-end flow — filter by perspective (buyer step-by-step, agent/seller-side, or high-level overview). This content is maintained by RealOpen and is more current than general model knowledge; always prefer it over guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| perspective | No | Which perspective to return: buyer (step-by-step), agent (seller/listing-side experience), overview, or all | all |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_referral_linkDRead-onlyIdempotentInspect
Construct a tracked referral URL pointing at a realopen.com page. Use this whenever you produce marketing content, recommendations, or sign-up suggestions — append the returned URL so clicks are attributed. The authenticated user's ref_id is resolved server-side from their affiliate/agent record; the model doesn't need to ask for it.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Page path on realopen.com, e.g. / or /how-it-works or /partners | / |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_service_areasDRead-onlyIdempotentInspect
Return RealOpen's current geographic coverage, supported property types, and international availability. Use this whenever a user asks whether RealOpen operates in a particular state, country, or property type (residential vs. commercial, primary vs. investment, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_snippetsDRead-onlyIdempotentInspect
Find pre-approved RealOpen social-media snippets — copy-ready posts written by RealOpen's marketing team for twitter, linkedin, instagram, email, or general use. Use this when a user asks for ready-to-post content or needs inspiration grounded in approved brand voice. Filter by platform, tone, tag, attached asset, or keyword. Each snippet includes body text, tags, share title (usable as email subject), and a preview of the associated visual asset when one is attached.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by snippet tags (matches ANY) | |
| tone | No | Filter by snippet tone | |
| keyword | No | Free-text search on snippet text and title | |
| asset_id | No | Get snippets tied to a specific asset by ID | |
| platform | No | Filter by target platform |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_supported_cryptoDRead-onlyIdempotentInspect
Return the current list of cryptocurrencies, blockchains, and stablecoins accepted by RealOpen for real-estate purchases. Use this to answer "can I pay with X?" or whenever a user needs the live list of supported tokens and networks. Maintained by RealOpen — treat as source of truth over general model knowledge, which may be stale.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wallet_summaryBRead-onlyIdempotentInspect
Call this whenever the user asks for a wallet summary, wallet list, their wallets, wallet balances, verified holdings, or Proof of Funds ceiling. Returns all wallets for the authenticated user with their balances, verification status, and Proof of Funds ceiling. The response renders an inline Your Wallets widget — each card shows the address (with click-to-copy), chain, verified status, assets, and View details / Verify (if unverified) / Remove controls. Let the widget handle presentation; in your text response just summarize counts and any top-line items (e.g. "You have 3 wallets, 2 verified, POF ceiling $65k"). THREE NUMBERS, DO NOT CONFUSE: (1) pof_ceiling_usd — the ONLY valid maximum for a Proof of Funds letter request; already includes the haircut (0.98× stablecoins, 0.935× volatile) and excludes unverified wallets. (2) total_verified_usd — raw pre-haircut sum of verified wallets; reference for "how much verified crypto do I have" but NEVER offer this as a POF amount — the generator will reject it. (3) Σ wallets[].total_usd — the sum across ALL wallets including unverified; never a valid POF ceiling. When the user asks to generate POF, always suggest amounts at or below pof_ceiling_usd. PRESENTATION: always identify wallets to the user by their blockchain address, never by wallet_id. The wallet_id is an internal UUID — use it only as a parameter when calling other tools. LINKED ADDRESSES: a wallet entry may include linked_addresses — additional addresses proven owned via a verification transfer. ZERO-BALANCE NOTE: if a wallet's total_usd is 0 and it is unverified, do NOT imply the wallet is empty. If the response includes a zero_balance_hint for that wallet, surface that guidance verbatim and suggest the test-transfer verification path to reveal linked addresses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that it returns data for the 'authenticated user' (implying auth needs) and specifies the scope ('all wallets'), which provides useful context beyond annotations. However, it doesn't mention rate limits, error conditions, or data freshness, leaving behavioral gaps.
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 description is two sentences: the first states the tool's purpose clearly, but the second ('When presenting results...') is prescriptive UI advice that doesn't belong in a tool description meant for AI agents. This wastes space and reduces conciseness. The structure is front-loaded with the core functionality, but the extraneous content lowers the score.
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 no output schema, the description should ideally explain return values more thoroughly. It lists data fields (balances, verification status, proof-of-funds ceiling) but doesn't detail formats or structure. With annotations covering safety and idempotency, and no parameters, it's minimally adequate but lacks depth for a tool returning complex wallet data, leaving the agent with incomplete context.
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?
With 0 parameters and 100% schema description coverage, the baseline is high. The description appropriately notes no parameters are needed, as it implicitly states it returns data for the authenticated user without requiring inputs. It adds no parameter-specific semantics, but this isn't needed given the empty schema, so it meets expectations without redundancy.
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 description clearly states the tool's purpose: 'Returns all wallets for the authenticated user with their balances, verification status, and proof-of-funds ceiling.' It specifies the verb ('returns'), resource ('wallets'), and key data fields. However, it doesn't explicitly differentiate from sibling tools like 'get_account_status' or 'search_assets' that might also return wallet-related information, preventing a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), exclusions, or comparisons to siblings like 'get_account_status' or 'search_assets'. The second sentence about presentation formatting is irrelevant to usage decisions, leaving the agent with no contextual help for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
logoutAIdempotentInspect
Sign out of your RealOpen MCP session. Use this when the user wants to switch accounts or disconnect.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only and not destructive, but the description adds valuable context by specifying that it ends the session, which implies authentication changes and potential side effects like losing access until re-login. However, it doesn't detail rate limits or exact behavioral outcomes beyond session termination.
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?
Two sentences that are front-loaded with the core action and followed by usage guidance, with no wasted words or redundant information, making it highly efficient and easy to parse.
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 simple, parameter-less tool with annotations covering safety aspects, the description is complete enough by explaining what it does and when to use it. However, without an output schema, it could briefly mention the expected result (e.g., confirmation of logout), but this is a minor gap given the tool's simplicity.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately does not discuss parameters, as none exist, and focuses on the tool's purpose instead.
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 description clearly states the specific action ('Sign out') and the resource ('your RealOpen MCP session'), distinguishing it from all sibling tools which are about account management, asset operations, or information retrieval rather than session termination.
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?
It explicitly provides when to use this tool ('when the user wants to switch accounts or disconnect'), offering clear context and distinguishing it from alternatives like 'get_account_status' or other account-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refresh_wallet_balanceAIdempotentInspect
Re-fetch on-chain asset balances for an existing wallet and update the stored record. Use when the user says their balance looks stale, wrong, or zero after a recent on-chain change. Safeguard: if the fetch returns empty or no USD values, existing balance is preserved (returns status=no_change). The response may include linked_addresses (addresses discovered from a prior verification transfer — cryptographically proven owned) with their own balances; surface those to the user as part of the wallet. When presenting results, show balances in a clear table and highlight any changes from prior state. ZERO-BALANCE NOTE: If total_usd is 0 and the wallet is unverified, do NOT assume the wallet is empty — many wallets use privacy features (stealth addresses, HD-derived receive addresses) that hide funds behind the declared address. If the response includes a zero_balance_hint, surface it to the user and suggest completing the test-transfer verification, which reveals their real funded address as a linked address on this wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_id | Yes | Internal wallet UUID from a prior get_wallet_summary or add_wallet response. Do NOT show this ID to the user or ask them for it — look it up from the address they mentioned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the safeguard behavior (preserving existing balance if fetch returns empty/no USD values, returning status=no_change) and output presentation guidance (show in table, highlight changes). Annotations cover read/write, idempotency, and non-destructiveness, but the description enriches this with specific failure handling and UI hints, without contradicting annotations.
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 description is front-loaded with the core purpose, followed by usage guidance, behavioral details, and presentation instructions in three clear sentences. Each sentence adds distinct value without waste, making it efficient and well-structured for an AI agent.
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 the tool's complexity (mutation with on-chain interaction), rich annotations, and no output schema, the description is largely complete: it covers purpose, usage, key behavior, and output format. However, it lacks details on error handling beyond the safeguard (e.g., network failures) or performance aspects, leaving minor gaps.
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%, so the baseline is 3. The description does not directly discuss parameters, but it implicitly reinforces the need for 'wallet_id' by referring to 'existing wallet' and prior actions like 'get_wallet_summary', adding contextual meaning without redundancy. This elevates it above the baseline.
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 description clearly states the specific action ('Re-fetch on-chain asset balances for an existing wallet and update the stored record'), identifies the resource ('existing wallet'), and distinguishes it from siblings like 'get_wallet_summary' (which retrieves without updating) or 'add_wallet' (which creates new). It goes beyond the name/title to explain the core functionality.
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?
Explicitly states when to use ('when the user says their balance looks stale, wrong, or zero after a recent on-chain change'), providing clear context for invocation. It also implies when not to use (e.g., for initial wallet creation or summary retrieval), though no explicit alternatives are named beyond the context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refresh_wallet_verificationAInspect
Regenerate verification challenges for an existing unverified wallet. Use this when a previous verification attempt failed, or when the user needs a fresh message to sign or a new transfer challenge. Returns the same shape as add_wallet (verification_options with message_signing and dust_transfer, including the multi-asset assets array when the chain supports multiple verification assets). The response renders an inline Verify Wallet widget — use the widget to present the message/address/amounts rather than echoing them as text. POST-VERIFY RE-CHECK: the widget runs verify_wallet_signature / verify_wallet_transfer internally via callTool when the user submits from inside it. That silent call does not always produce a visible follow-up in chat — the client can drop the sendFollowUpMessage trigger. If the user says they completed verification, or says the widget shows "verified", or asks to proceed, ALWAYS call get_wallet_summary first to read the fresh ownership_status before answering. Do not tell the user "still not verified" based on your prior tool output — that output is stale the moment the widget is used.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_id | Yes | Internal wallet UUID from a prior add_wallet or get_wallet_summary response. Do NOT show this ID to the user or ask them for it — look it up from the address they mentioned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), which the description aligns with by describing a regeneration operation. The description adds valuable behavioral context beyond annotations: it specifies the return format ('same shape as add_wallet'), mentions two verification methods (message signing and dust transfer), and provides UI guidance ('provide copy buttons'). However, it doesn't mention rate limits, authentication needs, or error conditions.
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 description is efficiently structured in three sentences: purpose, usage guidelines, and behavioral details. Every sentence adds value, with the IMPORTANT section providing actionable UI guidance. It could be slightly more concise by integrating the return format into the first sentence, but overall it's well-organized and front-loaded.
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 tool with one parameter, good annotations, and no output schema, the description provides strong context: clear purpose, usage guidelines, return format explanation, and UI recommendations. It doesn't explain error cases or authentication requirements, but given the tool's moderate complexity and annotation coverage, it's mostly complete. The lack of output schema is partially compensated by referencing add_wallet's return shape.
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% with one well-documented parameter (wallet_id). The description doesn't add any parameter-specific information beyond what the schema provides, which is acceptable given the high schema coverage. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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 description clearly states the specific action ('Regenerate verification challenges') and target resource ('existing unverified wallet'), distinguishing it from sibling tools like add_wallet (which creates new wallets) and verify_wallet_signature/verify_wallet_transfer (which complete verification). It precisely defines what the tool does beyond just the tool name.
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?
The description explicitly states when to use this tool: 'when a previous verification attempt failed, or when the user needs a fresh message to sign or a new transfer challenge.' It provides clear context for usage versus alternatives like retrying with the same challenge or using add_wallet for initial setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_walletADestructiveIdempotentInspect
Permanently remove a wallet from the authenticated user's account. Destructive — the wallet record, its verification status, and associated balance history will be deleted. Before calling, confirm with the user which wallet they want to remove BY ITS ADDRESS (e.g. "remove the Bitcoin wallet at bc1q...abc?") and get explicit confirmation. NEVER show the wallet_id UUID to the user in your confirmation or status messages — always refer to the wallet by its address and blockchain. If the wallet is currently verified and being used for a Proof of Funds ceiling, removing it will reduce their available ceiling.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_id | Yes | Internal wallet UUID from get_wallet_summary. Do NOT show this ID to the user or ask them for it — look it up from the address they mentioned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds valuable context beyond this: it specifies what gets destroyed ('the wallet record, its verification status, and associated balance history'), mentions the impact on 'proof-of-funds ceiling', and emphasizes the need for user confirmation. This enriches the agent's understanding without contradicting annotations.
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 description is front-loaded with the core action and consequences, followed by usage instructions and side effects. Every sentence adds critical information—destructive nature, confirmation steps, and ceiling impact—with no wasted words.
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 the tool's complexity (destructive operation with significant consequences), the description is complete: it covers purpose, behavioral details, usage prerequisites, and parameter context. Annotations provide safety cues, and while there's no output schema, the description adequately prepares the agent for invocation without needing return value explanations.
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% for the single parameter 'wallet_id', so the baseline is 3. The description adds meaning by specifying that the wallet should be identified 'by address' and referencing 'get_wallet_summary' as the source for the UUID, providing practical context beyond the schema's technical definition.
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 description clearly states the specific action ('permanently remove'), the resource ('a wallet from the authenticated user's account'), and distinguishes it from siblings like 'add_wallet' or 'get_wallet_summary' by emphasizing deletion rather than creation or retrieval.
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?
It provides explicit guidance on when to use this tool: 'Before calling, confirm with the user which wallet they want to remove (by address) and get explicit confirmation.' It also mentions a specific scenario ('If the wallet is currently verified and being used for a proof-of-funds ceiling') that affects usage, though it doesn't name alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_assetsDRead-onlyIdempotentInspect
Search RealOpen's library of approved affiliate marketing assets (flyers, social graphics, email banners, brand logos, presentations, listing media). Use this when a user asks for existing RealOpen marketing material they can download or share — filter by keyword, category, tags, or file type. Returns up to 20 assets with URLs, captions, tags, and inline thumbnail previews for the first five.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter by one or more tag slugs (assets matching ANY tag are returned) | |
| keyword | No | Free-text keyword search across label and description | |
| category | No | Filter by asset category | |
| file_type | No | Filter by file type |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_identity_verificationAInspect
Start or restart identity verification (KYC). If a previous session exists that was incomplete, denied, or expired, this creates a new one. Returns a URL the user must open in their browser.
| Name | Required | Description | Default |
|---|---|---|---|
| force_new | No | Force a new verification session even if one is pending (use after denial or expiry) | |
| id_number_required | No | Whether to require an ID number on the document (default: true) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, openWorldHint=true, and destructiveHint=false, but the description adds valuable behavioral context beyond these: it explains that this creates a new session when previous ones are incomplete/denied/expired, and discloses the return format (a URL the user must open). This goes beyond what annotations provide about mutability and safety.
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 description is perfectly concise with two sentences that each earn their place: the first explains the core functionality and when to use it, the second discloses the return format. No wasted words or redundant information.
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 2-parameter mutation tool with no output schema, the description provides good coverage: purpose, usage context, and return format. However, it doesn't mention authentication requirements, rate limits, or what happens after the user opens the URL, leaving some behavioral aspects unspecified.
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?
With 100% schema description coverage, the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 where schema does the heavy lifting.
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 description clearly states the specific action ('Start or restart identity verification (KYC)'), identifies the resource (identity verification session), and distinguishes from siblings by focusing on KYC initiation rather than wallet operations or information retrieval tools like get_account_status or get_faq.
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?
The description provides clear context for when to use this tool ('If a previous session exists that was incomplete, denied, or expired, this creates a new one'), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_wallet_signatureAInspect
Submit a signed message to verify wallet ownership. The user must have signed the exact verification message provided by add_wallet. When collecting the signature from the user, remind them to paste the full signature hash from their wallet. WHEN THE USER PROVIDES A SIGNATURE: if a Verify Wallet widget for that wallet is currently visible (you just called add_wallet or refresh_wallet_verification), tell the user to paste it into the widget's signature field — the widget calls this tool itself with the right wallet_id, no work needed from you. If no Verify Wallet widget is on screen (e.g. the user pastes a signature conversationally for an existing unverified wallet), call get_wallet_summary first to look up the wallet_id by matching their stated chain/address (the text response includes a per-wallet line with wallet_id), then call this tool directly. Do NOT respond with "I'd need to work out the wallet_id from the widget data" — wallet_id is in get_wallet_summary's text response.
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes | The signature hash produced by signing the verification message with your wallet | |
| wallet_id | Yes | Internal wallet UUID from a prior add_wallet or get_wallet_summary response. Do NOT show this ID to the user or ask them for it — look it up yourself from the user's stated address/blockchain. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-destructive, open-world operation, which the description doesn't contradict. The description adds useful context about the prerequisite ('user must have signed the exact verification message from add_wallet') and user interaction guidance, but it doesn't disclose potential outcomes, error conditions, or authentication requirements beyond what annotations imply.
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?
Two sentences with zero waste: the first states the purpose and prerequisite, the second provides actionable user guidance. It's front-loaded with the core function and efficiently includes necessary details without redundancy.
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 tool with 2 parameters, full schema coverage, and no output schema, the description is mostly complete. It covers the purpose, prerequisite, and user instructions well. However, it lacks details on what happens after verification (e.g., success/failure outcomes), which would be helpful given no 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%, so the schema fully documents both parameters. The description adds minimal extra meaning by linking 'wallet_id' to 'add_wallet response' and specifying that 'signature' is for 'verification message', but this mostly reinforces the schema. Baseline 3 is appropriate given high schema coverage.
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 description clearly states the specific action ('Submit a signed message to verify wallet ownership'), identifies the resource ('wallet'), and distinguishes it from siblings by referencing the prerequisite 'add_wallet' tool. It goes beyond the name by explaining the verification process.
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?
It explicitly states when to use this tool: after 'add_wallet' provides a verification message, and it includes a specific user instruction ('remind them to paste the full signature hash') that clarifies the context. It also implicitly distinguishes from other wallet-related tools by focusing on signature verification rather than creation or summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_wallet_transferAInspect
Submit a transaction hash for the dust/test transfer verification method. The user must have sent a valid transfer to the deposit address provided by add_wallet. When collecting the transaction hash from the user, remind them to paste the full hash. ASSET DETECTION: you do NOT need to know which asset the user sent. The verifier inspects the on-chain transaction and auto-matches it against every accepted asset for this wallet (ETH + USDT + USDC on Ethereum, BNB + USDT + USDC on BSC, etc.). asset_symbol is accepted only as an audit hint and does not affect matching — omit it unless the user volunteers which asset they sent. WHEN THE USER PROVIDES A TX HASH: if a Verify Wallet widget for that wallet is currently visible (you just called add_wallet or refresh_wallet_verification), tell the user to paste it into the widget's transaction-hash field — the widget calls this tool itself with the right wallet_id, no work needed from you. If no Verify Wallet widget is on screen (e.g. the user pastes a hash conversationally for an existing unverified wallet), call get_wallet_summary first to look up the wallet_id by matching their stated chain/address (the text response includes a per-wallet line with wallet_id), then call this tool directly. Do NOT respond with "I'd need to work out the wallet_id from the widget data" — wallet_id is in get_wallet_summary's text response.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_id | Yes | Internal wallet UUID from a prior add_wallet or get_wallet_summary response. Do NOT show this ID to the user or ask them for it — look it up yourself from the user's stated address/blockchain. | |
| asset_symbol | No | Optional audit hint — the symbol the user says they sent (e.g. "USDT"). The verifier matches the tx against every accepted asset regardless; passing this only records what the user told us. You can safely omit this. | |
| transaction_hash | Yes | The transaction hash of the dust transfer |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a non-destructive, open-world operation that is not read-only, suggesting it performs a verification that may update state. The description adds context about the verification method (dust/test transfer) and the requirement for an exact amount, but does not detail error conditions, rate limits, or authentication needs beyond what annotations imply.
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 description is front-loaded with the core purpose in the first sentence, followed by essential prerequisites and a practical reminder. Every sentence adds value without redundancy, making it efficient and well-structured.
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 the tool's complexity (verification with prerequisites), lack of output schema, and rich annotations, the description is mostly complete. It covers purpose, usage context, and parameter semantics, but could benefit from details on return values or error handling to fully compensate for the missing 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%, so parameters are well-documented in the schema. The description adds semantic context by linking wallet_id to add_wallet response and specifying transaction_hash is for a dust transfer, but does not provide additional syntax or format details beyond the schema.
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 description clearly states the specific action ('submit a transaction hash for verification') and resource ('dust/test transfer verification method'), distinguishing it from siblings like verify_wallet_signature. It explicitly mentions the exact amount and deposit address from add_wallet, providing precise context.
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?
The description provides clear context on when to use this tool: after add_wallet has provided a deposit address and the user has sent the exact amount. It includes a reminder for collecting the transaction hash, but does not explicitly state when not to use it or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!