TokenBank — tokenized real-world assets

Find permissionless assets

find_permissionless_assets

Read-onlyIdempotent

Instruments whose secondary market needs no KYC and which a self-custody wallet holds itself — a property of how the token works, read from hand-verified gates. For real-world assets the gate to MINT and the gate to trade on a secondary market routinely differ, so a fund can be permissioned at the issuer while its token trades freely. Strict by design — an instrument whose gate is merely unverified is excluded. This says nothing about who may buy it: the issuer's terms and local law decide that.

Input Schema

Name	Required	Description
`limit`	No	Max results (default 20)
`offset`	No	Skip this many matches before returning. Use the nextOffset from the previous answer to walk the whole set; its absence means you reached the end.
`pillar`	No	Limit to one category pillar
`min_yield_pct`	No	Minimum comparable yield in percent
`include_unverified`	No	Default false. When true, also returns instruments whose secondary-market gate is unknown — clearly flagged. Use only when the user asked what MIGHT be open, never to answer what IS open.

Output Schema

Name	Required	Description
`count`	Yes
`results`	Yes
`nextOffset`	No	Pass as offset to fetch the next page; absent when there is no more
`unverified`	No	Possibly open, not confirmed — excluded from results
`confirmedOpen`	No	Secondary-market gate verified as no KYC
`totalMatching`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 2, 2026

removedInput schema / properties / eu_only

Removed value: -{
-  "description": "Only instruments explicitly stated as EU-available",
-  "type": "boolean"
-}

changedOutput schema / properties / confirmedOpen / description

Previous value: -"Verified as buyable without KYC"New value: +"Secondary-market gate verified as no KYC"

First observedSep 16, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so safety is covered; the description adds real domain behavior beyond that — the strict gating policy, the buy-vs-trade scope caveat, and the mint-gate/trading-gate distinction for real-world assets. It does not mention rate limits or result-set behavior, but the disclosure is substantive for a read tool.

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?

Four sentences, front-loaded with the core definition, and each sentence carries distinct information (definition, gating nuance, strictness policy, scope caveat). Dense but not padded; a slight trim of the last sentence's framing would be possible.

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

Completeness4/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 and pagination (nextOffset) need not be restated, and the description fully covers the conceptual domain an agent needs to route and interpret the tool. Adequate and well-matched to the structured fields it sits alongside.

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

Parameters3/5

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

Schema description coverage is 100% and the include_unverified, offset, limit, pillar, and min_yield_pct fields are all self-documenting. The description supplies the conceptual model (verified vs merely-unverified gates) that makes include_unverified interpretable, but adds no per-parameter detail beyond the schema. Baseline 3 applies.

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

Purpose4/5

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

The description states a precise verb+resource and, unusually helpfully, defines what "permissionless" means here: secondary market with no KYC, held in a self-custody wallet, read from hand-verified gates. That sharply distinguishes it from siblings like find_tokenized_security or compare_tokenized_access. It stops short of naming an alternative tool to use instead, so it is clear but not fully sibling-differentiated.

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

Usage Guidelines3/5

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

The description conveys when the semantic fit applies ('strict by design — an instrument whose gate is merely unverified is excluded'), but the actual when-to-use instruction for the unverified case lives in the include_unverified schema field, not the description. No sibling tool or exclusion path is named in the description itself.

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

All TokenBank — tokenized real-world assets 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.

Resources

Need Help?