UNIALL RWA Index

Check investor eligibility

check_eligibility

Read-onlyIdempotent

Answers whether a given investor profile can buy or hold one UNIALL asset, and why. Combines sourced offering rules with the on-chain transferability oracle. Returns ELIGIBLE | NOT_ELIGIBLE | REQUIRES_ONBOARDING | UNKNOWN. UNKNOWN when rules are missing or older than 90 days. Informational only.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "assetId": "<assetId>",
      "jurisdiction": "<jurisdiction>",
      "investorType": "<investorType>"
    },
    "name": "check_eligibility"
  }
}

Input Schema

Name	Required	Description	Default
`assetId`	Yes
`investorType`	Yes
`jurisdiction`	Yes
`investmentUsd`	No
`walletAddress`	No

Output Schema

Name	Required	Description
`facts`	Yes	Sourced scalar facts. Each item has field, value, source_url, source_type, as_of.
`answer`	Yes	Short natural-language summary of the result.
`assets`	No	Matched assets when applicable (find_assets). Empty or omitted for stats/summary tools.
`disclaimer`	Yes	Fixed data-only disclaimer; not investment advice.
`request_id`	Yes	Request correlation id.
`index_as_of`	Yes	ISO timestamp for index freshness.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.7/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing the data sources (sourced offering rules plus the on-chain oracle), the four possible outcomes, the exact UNKNOWN condition (rules missing or older than 90 days), and the 'informational only' caveat. That staleness rule is operationally important and cannot be inferred from any structured field.

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?

Four short sentences, front-loaded with the core answer and then the return states and the caveat. No filler, and the enum outcomes are stated compactly rather than enumerated in prose.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description did not strictly need to explain return values, though doing so is a plus. The real gap is the five undocumented inputs at 0% schema coverage — for a decision tool whose answer depends on jurisdiction and investor type, the agent gets no guidance on how those inputs shape the verdict.

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

Parameters2/5

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

Schema description coverage is 0% across five parameters, so the description carries the full burden — yet it explains none of them. assetId, jurisdiction, investorType, investmentUsd, and walletAddress are never mentioned, and there is no hint that investmentUsd or walletAddress are optional or how they affect the verdict.

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?

States a specific verb and resource — 'Answers whether a given investor profile can buy or hold one UNIALL asset' — and adds the 'why' aspect plus the combination of offering rules with the on-chain transferability oracle. The scoping to 'one asset' implicitly separates it from the plural filter tool screen_eligible_assets, but no sibling is named outright.

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?

Usage is only implied: the single-asset, single-profile framing suggests it is the point-check tool versus a bulk screening tool, but the description never says when to prefer it over check_transferability or screen_eligible_assets. No exclusions or prerequisites are given.

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

All UNIALL RWA Index 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?