Skip to main content
Glama

mcp-server

by io.github.realopengroup

generate_proof_of_funds

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesRequested Proof of Funds amount
currencyNoCurrency for the letter (default: USD)USD

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYes
statusYesready when the letter generated successfully
currencyYes
file_nameNo
valid_untilNoISO date — letter expires after 30 days
download_urlYesPDF download URL — handed to the widget; the model should not echo it
thumbnail_urlYesTop-of-letter PDF preview image URL — used by the widget

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the sparse annotations, the description discloses prerequisites, a 30-day download link, inline widget rendering, cancellation handling, and the ceiling constraint. It warns against using incorrect ceiling sources, adding important behavioral context not present in 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?

The description is long but well-structured with clear sections for cancellation handling and ceiling. Every sentence serves a purpose, though some operational details could be condensed. It is appropriately sized for the tool's complexity.

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?

The description covers prerequisites, return value (download link, widget), error/retry handling, and the critical ceiling calculation. With an output schema present, it fully equips the agent to invoke the tool 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 schema already documents both parameters (amount, currency) with descriptions, so baseline is 3. The description adds crucial constraint semantics for the amount parameter (must be ≤ pof_ceiling_usd from get_wallet_summary), which is not in the schema. This elevates the score to 4.

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 begins with a specific verb ('Generate') and resource ('Proof of Funds letter (PDF)'), clearly stating the action and output. It distinguishes itself from sibling tools like get_wallet_summary and verify_wallet_signature by focusing on document generation.

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?

It specifies preconditions (completed identity verification, at least one verified wallet) and explicitly recommends calling get_wallet_summary to check the ceiling. It also provides guidance on cancellation handling and when not to report success, giving clear expected usage.

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