Skip to main content
Glama

mcp-server

by io.github.realopengroup

get_account_status

Read-onlyIdempotent

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 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
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pofNo
emailNo
user_idNo
walletsNoAggregate wallet counts. For per-wallet details, call get_wallet_summary.
last_nameNo
activationNoProgress + 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_nameNo
account_hintNoPresent 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_verificationNo

TDQS

A4.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is known. The description adds valuable beyond-annotation context: that the response renders an inline progress widget and instructs the agent to keep its text to a short summary. It does not mention rate limits or authentication needs, but with zero parameters and clear read-only semantics, the behavioral transparency is strong. No contradiction with annotations.

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 three sentences, each earning its place: first sentence states what the tool returns, second gives usage guidance and alternatives, third explains a key behavioral trait (the widget and agent response instructions). No fluff, front-loaded with the core purpose.

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?

Given zero parameters and a clear output schema (presence indicated), the description is complete. It states purpose, usage boundaries, and response behavior (widget rendering, agent response guidance). For a simple, zero-param, read-only tool with rich annotations, nothing is missing.

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

Parameters5/5

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

Schema description coverage is 100% and there are no parameters, so the description has no additional parameter documentation burden. The description is clear that no input is needed, and it fully explains the information returned.

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') and resource ('high-level account overview'), and details exactly what is included: identity verification state, wallet count (not details), and Proof of Funds eligibility. It clearly distinguishes itself from sibling get_wallet_summary by specifying its scope is account-level, not wallet-specific.

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 explicitly states when to use this tool ('is my account ready?' questions, resuming setup) and when NOT to use it (wallet summary, wallet list, wallet balances) with a direct alternative named: get_wallet_summary. It also explains the tool's unique value of providing the 'activation.next_action' for the user's state.

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

All mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (wallet management, verification, knowledge lookup, marketing, account status), but there is minor overlap between add_wallet and refresh_wallet_verification (both generate verification challenges) and between get_started and get_account_status (both touch on next-step resolution). Descriptions clarify the differences, so confusion is unlikely.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., add_wallet, get_wallet_summary, verify_wallet_transfer), with only 'logout' as a single verb, which is still consistent with the imperative style. No mixed conventions or cryptic names.

Tool Count4/5

The server exposes 20 tools, which is on the heavier side of the typical range but appropriate for the broad domain (wallet operations, verification, KYC, knowledge base, marketing assets, referral tracking). Each tool has a distinct role, so the count feels justified rather than bloated.

Completeness5/5

The surface covers the full lifecycle for crypto-to-real-estate transactions: wallet management (add, remove, refresh, verify), identity verification, proof-of-funds generation, knowledge tools (fees, coverage, supported crypto, how-it-works), marketing (snippets, assets, referral), and account navigation (get_started, logout). No obvious gaps that would leave an agent stuck.

Resources