# io.github.realopengroup/mcp-server (remote · mcp.realopen.app) Verify crypto wallets and generate proof of funds letters for buying real estate with crypto. - Trust score: 67/100 (medium) - Change this week: +5 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-08-03 ## Components - remote · `mcp.realopen.app`: 67/100 (this document), [markdown](https://verifymcp.io/servers/realopengroup-mcp-server/mcp.md), [page](https://verifymcp.io/servers/realopengroup-mcp-server/mcp) ## Channel facts - Endpoint: `https://mcp.realopen.app/mcp` - Transports: `streamable-http` - Auth: `none` - Version: `1.0.0` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-08-03. - **Endpoint Security**: 63/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (remove_wallet). - HTTPS is enforced; there's no plaintext access path. - The HSTS (Strict-Transport-Security) header is present. - DNSSEC check failed: this domain isn't protected by DNSSEC. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 63/100 - 56% of prompts and resources have a non-trivial description (not blank, and not just the item's name). - AI-judged instruction clarity (excellent). - Context-footprint check failed: tool/resource definitions use about 4508 tokens (~196/item across 23 items; 19 tools + 4 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 27/100 - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 100/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 100% of tool parameters carry a description. - Structured output schemas are declared (100% of tools); any adoption earns full credit. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. - Supports UI / widget rendering. ## Install ### Claude ```bash claude mcp add --transport http realopengroup-mcp-server https://mcp.realopen.app/mcp ``` ### Codex ```toml [mcp_servers.realopengroup-mcp-server] url = "https://mcp.realopen.app/mcp" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "realopengroup-mcp-server": { "type": "remote", "url": "https://mcp.realopen.app/mcp", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add realopengroup-mcp-server --url https://mcp.realopen.app/mcp --transport streamable-http ``` ### Hermes ```yaml mcp_servers: realopengroup-mcp-server: url: "https://mcp.realopen.app/mcp" ``` ### Other ```json { "mcpServers": { "realopengroup-mcp-server": { "type": "http", "url": "https://mcp.realopen.app/mcp" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-08-03 (score 67, +1) No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-08-01 (score 66, +1) No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-07-31 (score 65, +1) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-30 (score 64, 0) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-29 (score 64, +1) No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-07-28 (score 63, +1) No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-07-27 (score 62, 0) - [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server ### 2026-07-26 (score 62) First indexed and scored. ## MCP tools (19) ### `search_assets` (~148 tokens) 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. Input parameters: - `category` (string): Filter by asset category - `file_type` (string): Filter by file type - `keyword` (string): Free-text keyword search across label and description - `tags` (array): Filter by one or more tag slugs (assets matching ANY tag are returned) Output parameters: - `assets` (array): Up to 20 matching assets (ordered most-recent first) ### `get_snippets` (~172 tokens) 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. Input parameters: - `asset_id` (string): Get snippets tied to a specific asset by ID - `keyword` (string): Free-text search on snippet text and title - `platform` (string): Filter by target platform - `tags` (array): Filter by snippet tags (matches ANY) - `tone` (string): Filter by snippet tone Output parameters: - `snippets` (array): Up to 20 matching snippets (random order to avoid stale top-matches) ### `get_referral_link` (~99 tokens) 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. Input parameters: - `path` (string): Page path on realopen.com, e.g. / or /how-it-works or /partners Output parameters: - `referral_url` (string): Fully-qualified realopen.com URL with ref_id query param appended ### `get_how_it_works` (~137 tokens) 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, title/escrow company settlement, or high-level overview). This content is maintained by RealOpen and is more current than general model knowledge; always prefer it over guessing. Input parameters: - `perspective` (string): Which perspective to return: buyer (step-by-step), agent (seller/listing-side experience), escrow (title/escrow company settlement experience), overview, or all Output parameters: - `get_started` (string): Sign-up URL for users ready to begin - `last_updated` (string|null): ISO timestamp of the most recently updated underlying knowledge entry - `learn_more` (string): External URL with more detail - `sections` (array): Ordered content sections, each with a heading and body ### `get_supported_crypto` (~78 tokens) 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. Output parameters: - `last_updated` (string|null) - `learn_more` (string) - `sections` (array) ### `get_fee_structure` (~58 tokens) 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. Output parameters: - `last_updated` (string|null) - `learn_more` (string) - `sections` (array) ### `get_faq` (~154 tokens) 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. Input parameters: - `category` (string): Filter by FAQ category (e.g. "Getting Started", "Crypto & Wallets", "Closing Process", "Security & Compliance", "Fees & Taxes", "Proof of Funds", "Differentiators") - `query` (string): Search keyword or question to find relevant FAQ entries Output parameters: - `available_categories` (array): All distinct FAQ categories — returned when no entries matched, so callers can refine the query - `last_updated` (string|null) - `learn_more` (string) - `message` (string): Diagnostic message — only present when no entries matched - `result_count` (number): Number of matching FAQ entries returned - `results` (array): Matching FAQ entries (empty when no entries match) ### `get_service_areas` (~60 tokens) 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.). Output parameters: - `last_updated` (string|null) - `learn_more` (string) - `sections` (array) ### `get_account_status` (~83 tokens) 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. Output parameters: - `email` (string|null) - `first_name` (string|null) - `identity_verification` (object) - `last_name` (string|null) - `pof` (object) - `user_id` (string|null) - `wallets` (object): Aggregate wallet counts. For per-wallet details, call get_wallet_summary. ### `start_identity_verification` (~96 tokens) 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. Input parameters: - `force_new` (boolean): Force a new verification session even if one is pending (use after denial or expiry) - `id_number_required` (boolean): Whether to require an ID number on the document (default: true) Output parameters: - `instructions` (string|null) - `message` (string|null) - `previous_status` (string|null): The prior session status if this call is restarting a stale session - `status` (string): One of: already_verified, processing, redirect_required - `verification_url` (string|null): Stripe Identity URL the user opens in their browser. Present when status=redirect_required. - `verified_name` (string|null): Set when status=already_verified ### `add_wallet` (~567 tokens) 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 verified across Ethereum, Base, and Arbitrum. Signature verification is chain-agnostic and works for any EVM wallet — both regular (EOA) and smart-contract wallets (the ver… Input parameters: - `address` (string, required): The public wallet address to add Output parameters: - `address` (string|null) - `assets` (array): Per-asset on-chain balances detected for this wallet - `blockchain` (string|null) - `linked_addresses` (array) - `message` (string|null) - `ownership_status` (string|null): NOT_VERIFIED | PENDING_SIGNATURE | PENDING_TRANSACTION | VERIFIED_SIGNATURE | VERIFIED_TRANSACTION | FAILED - `status` (string|null): Set to "already_verified" when re-adding an already-verified wallet - `total_usd` (number|null) - `verification_options` (object) - `wallet_id` (string|null) - `zero_balance_hint` (string|null) ### `verify_wallet_signature` (~274 tokens) 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. Input parameters: - `signature` (string, required): The signature hash produced by signing the verification message with your wallet - `wallet_id` (string, required): 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. Output parameters: - `message` (string|null) - `ownership_status` (string|null): Underlying wallet state — VERIFIED_SIGNATURE | PENDING_SIGNATURE | NOT_VERIFIED | FAILED - `status` (string): verified | pending | failed | already_verified - `wallet_id` (string|null) ### `verify_wallet_transfer` (~417 tokens) 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. Input parameters: - `asset_symbol` (string): 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 s… - `transaction_hash` (string, required): The transaction hash of the dust transfer - `wallet_id` (string, required): 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. Output parameters: - `asset_symbol` (string|null): Asset the verifier auto-matched the transaction against - `message` (string|null) - `ownership_status` (string|null): Underlying wallet state — VERIFIED_TRANSACTION | PENDING_TRANSACTION | NOT_VERIFIED | FAILED - `status` (string): verified | pending | failed | already_verified - `wallet_id` (string|null) ### `remove_wallet` (~165 tokens) 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. Input parameters: - `wallet_id` (string, required): 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. Output parameters: - `message` (string|null) - `status` (string): removed | not_found - `wallet_id` (string|null) ### `refresh_wallet_balance` (~255 tokens) 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. Input parameters: - `wallet_id` (string, required): 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. Output parameters: - `address` (string|null) - `assets` (array): Per-asset balances on the wallet - `blockchain` (string|null) - `linked_addresses` (array): Additional addresses proven owned via a prior verification transfer - `message` (string|null) - `status` (string): refreshed | no_change - `total_usd` (number|null) - `wallet_id` (string|null) - `zero_balance_hint` (string|null): Surfaced when balance is 0 and the wallet is unverified — explains stealth/HD addressing ### `refresh_wallet_verification` (~271 tokens) 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. Input parameters: - `wallet_id` (string, required): 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. Output parameters: - `address` (string|null) - `assets` (array) - `blockchain` (string|null) - `linked_addresses` (array) - `message` (string|null) - `ownership_status` (string|null) - `status` (string|null) - `total_usd` (number|null) - `verification_options` (object) - `wallet_id` (string|null) - `zero_balance_hint` (string|null) ### `get_wallet_summary` (~409 tokens) 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. Output parameters: - `eligible_tokens` (array): Asset symbols that count toward POF eligibility - `pof_ceiling_usd` (number|null): Maximum amount valid for a Proof of Funds letter. Already includes the haircut (0.98× stables, 0.935× volatile) and excludes unverified wallets. - `total_verified_usd` (number|null): Raw pre-haircut sum of verified wallets. NEVER use as a POF ceiling — pof_ceiling_usd is the only correct max. - `wallets` (array): All wallets on the user's account ### `generate_proof_of_funds` (~267 tokens) 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. Input parameters: - `amount` (number, required): Requested Proof of Funds amount - `currency` (string): Currency for the letter (default: USD) Output parameters: - `amount` (number) - `currency` (string) - `download_url` (string): PDF download URL — handed to the widget; the model should not echo it - `file_name` (string|null) - `status` (string): ready when the letter generated successfully - `thumbnail_url` (string): Top-of-letter PDF preview image URL — used by the widget - `valid_until` (string|null): ISO date — letter expires after 30 days ### `logout` (~28 tokens) Sign out of your RealOpen MCP session. Use this when the user wants to switch accounts or disconnect. Output parameters: - `message` (string|null) - `status` (string): signed_out ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/realopengroup-mcp-server/mcp#diagnostics ## Score history - 2026-08-03: 67 - 2026-08-02: 66 - 2026-08-01: 66 - 2026-07-31: 65 - 2026-07-30: 64 - 2026-07-29: 64 - 2026-07-28: 63 - 2026-07-27: 62 - 2026-07-26: 62 ## Links - Remote endpoint: https://mcp.realopen.app/mcp - Repository: https://github.com/realopengroup/mcp-server - Website: https://realopen.com/ - Changelog RSS feed: https://verifymcp.io/servers/realopengroup-mcp-server/mcp/changelog.xml - Changelog JSON feed: https://verifymcp.io/servers/realopengroup-mcp-server/mcp/changelog.json - HTML version of this page: https://verifymcp.io/servers/realopengroup-mcp-server/mcp