mcp-server

get_account_status

Read-onlyIdempotent

Returns a high-level account overview of where the user stands in getting ready to buy real estate with crypto: 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 and for resuming setup: the response includes activation.next_action — the single correct next step for this user's state. The response renders an inline progress widget (checklist + one next-step CTA); keep your text to a short summary and let the widget carry the presentation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`pof`	No
`email`	No
`user_id`	No
`wallets`	No	Aggregate wallet counts. For per-wallet details, call get_wallet_summary.
`last_name`	No
`activation`	No	Progress + next-step routing resolved from the account state. Follow next_action rather than re-deriving the step order. Fully-activated users get a "generate another POF / wallet summary" action, never an onboarding CTA.
`first_name`	No
`account_hint`	No	Present only for brand-new/empty accounts — if the user expected existing RealOpen data, surface this guidance (they may have connected with a different email than their realopen.com account)
`identity_verification`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 18, 2026

addedOutput schema / properties / activation

Added value: +{
+  "additionalProperties": true,
+  "description": "Progress + next-step routing resolved from the account state. Follow next_action rather than re-deriving the step order. Fully-activated users get a \"generate another POF / wallet summary\" action, never an onboarding CTA.",
+  "properties": {
+    "authenticated": {
+      "type": "boolean"
+    },
+    "next_action": {
+      "additionalProperties": true,
+      "description": "The single correct next step for this user: tool, CTA label, suggested prompt, reason",
+      "properties": {},
+      "type": "object"
+    },
+    "stage": {
+      "description": "identity | wallet_add | wallet_verify | pof_ready | activated",
+      "type": "string"
+    },
+    "steps": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {},
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "authenticated",
+    "stage",
+    "steps",
+    "next_action"
+  ],
+  "type": "object"
+}

Changed1 schema field changedAug 9, 2026

addedOutput schema / properties / account_hint

Added value: +{
+  "description": "Present only for brand-new/empty accounts — if the user expected existing RealOpen data, surface this guidance (they may have connected with a different email than their realopen.com account)",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed1 schema field changedMay 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "email": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "first_name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "identity_verification": {
+      "additionalProperties": true,
+      "properties": {
+        "next_step": {
+          "description": "Human-readable instruction for the user given the current status",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "status": {
+          "description": "One of: none, requires_input, processing, verified, has_error, canceled",
+          "type": "string"
+        },
+        "verified_name": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "required": [
+        "status"
+      ],
+      "type": "object"
+    },
+    "last_name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "pof": {
+      "additionalProperties": true,
+      "properties": {
+        "ceiling_usd": {
+          "description": "Maximum amount valid for a Proof of Funds letter (post-haircut, verified wallets only)",
+          "type": "number"
+        },
+        "eligible": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "eligible",
+        "ceiling_usd"
+      ],
+      "type": "object"
+    },
+    "user_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "wallets": {
+      "additionalProperties": true,
+      "description": "Aggregate wallet counts. For per-wallet details, call get_wallet_summary.",
+      "properties": {
+        "pending": {
+          "type": "number"
+        },
+        "total": {
+          "type": "number"
+        },
+        "verified": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "total",
+        "verified",
+        "pending"
+      ],
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

First observedApr 14, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond that: the response includes activation.next_action as the single correct next step, and it renders an inline progress widget with instructions to keep agent text short. This helps the agent know what to expect and how to respond.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: what the tool returns, what it does not return, the sibling to use instead, the primary use cases, the key response field, and the widget presentation guidance. Key information is front-loaded in the first sentence.

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 tool with an output schema, the description is complete. It covers the return contents, the critical next-action field, presentation behavior, and explicit routing away from get_wallet_summary. Nothing needed to call or interpret the tool correctly 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?

The tool has zero parameters, so there is no parameter semantics to document. Per calibration, a zero-parameter tool earns a baseline of 4; the description correctly avoids inventing parameter details.

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

Purpose5/5

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

The description uses a specific verb ('Returns') with a specific resource ('high-level account overview') and names the exact components: identity verification state, wallet count, and Proof of Funds eligibility. It also explicitly distinguishes itself from get_wallet_summary, so an agent can select it correctly without ambiguity.

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?

The description gives explicit when-to-use guidance ('answering "is my account ready?"-style questions' and 'resuming setup') and explicit when-not-to-use guidance with the named alternative ('DO NOT call this when the user asks for a wallet summary... use get_wallet_summary'). This fully covers selection logic.

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.