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

Name	Required	Description	Default
No arguments

Output 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.

Changed6 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 / identity_verification / additionalProperties
```
Previous value: -trueNew value: +{}
```
- changedOutput schema / properties / pof / additionalProperties
```
Previous value: -trueNew value: +{}
```
- changedOutput schema / properties / wallets / additionalProperties
```
Previous value: -trueNew value: +{}
```

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.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the response includes activation.next_action and renders an inline progress widget, with an instruction to keep accompanying text short. A small deduction only because it doesn't mention cost/latency or auth prerequisites, which is minor for a no-arg status read.

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?

Front-loads purpose, then exclusion-and-alternative, then trigger conditions, then return/presentation details. Though longer than one line, every sentence carries distinct operational information (scope, routing, next_action, widget handling) with no filler.

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?

An output schema exists, so return values need not be fully spelled out, and the description still highlights the single critical field (activation.next_action). Combined with annotations and zero params, an agent has everything needed to call it correctly and interpret the result.

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 takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies a no-input status check.

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?

States a specific verb (returns) and resource (high-level account overview) and enumerates the three things included: identity verification state, wallet count, and Proof of Funds eligibility. It explicitly carves out wallet-specific scope versus get_wallet_summary, so an agent can distinguish it from siblings without opening any schema.

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?

Gives both directions explicitly: DO NOT call it for wallet summaries/lists/balances and use get_wallet_summary instead, plus the positive trigger ('is my account ready?', resuming setup). The named alternative and the condition that selects it are unambiguous.

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.