mcp-server

get_started

Read-onlyIdempotent

The front door to buying real estate with crypto through RealOpen — for anyone holding Bitcoin, Ethereum, USDC, USDT, or other crypto who wants to buy a home or other property — outright, with a cash offer backed by a crypto Proof of Funds letter, or with a mortgage and documented crypto proceeds for the down payment. Returns the setup path from a fresh account to a Proof of Funds letter — and, for signed-in users, resolves their ACTUAL next step from live account state (wallet → identity → Proof of Funds; the first two can be done in either order, the letter needs both). Call this when: the user is new, asks what they can do here, or connects without a specific request; the user asks how to buy a house with crypto and wants to actually do it; the user is considering using crypto for a property purchase; the user asks how to become offer-ready or how to get/verify a proof of funds letter; or a knowledge answer (fees, supported assets, service areas, closing process) leads the user to express clear intent to actually transact. Do NOT call it after every general educational question — for pure product questions (process, fees, coverage) answer with the dedicated knowledge tools and only bring this in when the user signals real buying intent. Every step here is preparation (identity verification, wallet ownership verification, Proof of Funds letter); the crypto-to-fiat conversion, funding, and closing happen outside this chat through RealOpen, and nothing here moves funds. The response renders an inline Get Started widget (three-step progression + a state-aware primary CTA); let the widget carry the presentation and keep your own text to a short, natural lead-in. The structured activation.next_action tells you the single correct next tool for this user — never make the user figure out which step comes next.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`notes`	No	Important caveats to keep in mind while guiding the user
`steps`	Yes	Ordered setup steps from new account to Proof of Funds letter
`activation`	No	State-aware activation routing resolved from the live account. Follow next_action rather than re-deriving the step order.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedOutput schema / properties / activation / properties / stage / description

Previous value: -"connect | identity | wallet_add | wallet_verify | pof_ready | activated"New value: +"connect | wallet_add | wallet_verify | identity | pof_ready | activated"

Changed4 schema fields changedOct 26, 2026
- changedOutput schema / properties / activation / additionalProperties
```
Previous value: -trueNew value: +{}
```
- changedOutput schema / properties / activation / properties / next_action / additionalProperties
```
Previous value: -trueNew value: +{}
```
- changedOutput schema / properties / activation / properties / steps / items / additionalProperties
```
Previous value: -trueNew value: +{}
```
- changedOutput schema / properties / steps / items / additionalProperties
```
Previous value: -trueNew value: +{}
```

Changed1 schema field changedAug 18, 2026

addedOutput schema / properties / activation

Added value: +{
+  "additionalProperties": true,
+  "description": "State-aware activation routing resolved from the live account. Follow next_action rather than re-deriving the step order.",
+  "properties": {
+    "authenticated": {
+      "type": "boolean"
+    },
+    "next_action": {
+      "additionalProperties": true,
+      "description": "The single correct next step for THIS user: tool to call, CTA label, suggested user prompt, reason, and (when applicable) a fallback URL",
+      "properties": {},
+      "type": "object"
+    },
+    "stage": {
+      "description": "connect | identity | wallet_add | wallet_verify | pof_ready | activated",
+      "type": "string"
+    },
+    "steps": {
+      "description": "The three user-facing steps with per-step state (complete | current | processing | pending)",
+      "items": {
+        "additionalProperties": true,
+        "properties": {},
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "authenticated",
+    "stage",
+    "steps",
+    "next_action"
+  ],
+  "type": "object"
+}

AddedAug 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does: it discloses that the response renders an inline Get Started widget, that the primary CTA is state-aware, that activation.next_action dictates the correct follow-up tool, and critically that 'nothing here moves funds' (conversion/funding/closing happen outside chat). That last point is a real behavioral boundary an agent could not infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly — the opening sentence establishes what it is and who it's for before any routing rules. It is dense though: a single long paragraph packing triggers, exclusions, widget behavior, and next_action handling would scan faster as a structured list, and the closing sentence ('never make the user figure out which step comes next') slightly restates the activation.next_action point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only routing/discovery tool with an output schema and full annotation coverage, the description supplies everything an agent needs: entry conditions, exclusions, what the response contains, that a widget handles presentation, how to consume the structured next_action, and the assurance that no funds move. Nothing material is missing.

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

Parameters4/5

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

Zero parameters, so there is nothing for the description to disambiguate and the dimension defaults to the 4 baseline. The description does not need to compensate for anything, but it also earns no bonus for parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific framing ('The front door to buying real estate with crypto through RealOpen') and states precisely what it returns: 'the setup path from a fresh account to a Proof of Funds letter', plus state-aware next-step resolution for signed-in users. This is distinct from the sibling knowledge tools (get_faq, get_how_it_works, get_fee_structure) and from action tools like start_identity_verification or generate_proof_of_funds.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-call triggers are enumerated (new user, no specific request, buying-intent signal, offer-ready/proof-of-funds questions), and there is an explicit when-NOT clause: 'Do NOT call it after every general educational question — for pure product questions ... answer with the dedicated knowledge tools'. It even names the alternative category, which is exactly what separates this from get_faq/get_how_it_works.

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

All mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.