Skip to main content
Glama
Sign In

Saylor Innovations: pay-per-call data

by com.saylorinnovations
OverviewDiscussionsAdmin

Wallet intelligence report

check_wallet
Read-onlyIdempotent

On-chain wallet profile on Solana, seven EVM chains read in parallel (Ethereum, Base, Arbitrum, Optimism, Polygon, BNB, Avalanche), Tron, Sui or TON: balances and valued holdings, account type including EIP-7702 delegation, activity, OFAC sanctions screening and ranked flags. Costs $0.01.

Input Schema

NameRequiredDescriptionDefault
chainNoOptional: one chain id, or a comma list (base,ethereum), to limit an EVM address to those chains.
tokensNoOptional comma list of up to 10 ERC-20 contract addresses to read; requires chain to name a single chain.
addressYesWallet address: Solana base58, EVM 0x, Tron T, Sui 0x (64 hex), or TON.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / address / description
      Previous value: -"Solana wallet address (base58)."New value: +"Wallet address: Solana base58, EVM 0x, Tron T, Sui 0x (64 hex), or TON."
    • addedInput schema / properties / chain
      Added value: +{
+  "description": "Optional: one chain id, or a comma list (base,ethereum), to limit an EVM address to those chains.",
+  "type": "string"
+}
    • addedInput schema / properties / tokens
      Added value: +{
+  "description": "Optional comma list of up to 10 ERC-20 contract addresses to read; requires chain to name a single chain.",
+  "type": "string"
+}
  2. Changed3 schema fields changed
    • changedInput schema / properties / address / description
      Previous value: -"Wallet address: Solana base58, EVM 0x, Tron T, Sui 0x (64 hex), or TON."New value: +"Solana wallet address (base58)."
    • removedInput schema / properties / chain
      Removed value: -{
-  "description": "Optional: one chain id, or a comma list (base,ethereum), to limit an EVM address to those chains.",
-  "type": "string"
-}
    • removedInput schema / properties / tokens
      Removed value: -{
-  "description": "Optional comma list of up to 10 ERC-20 contract addresses to read; requires chain to name a single chain.",
-  "type": "string"
-}
  3. Changed3 schema fields changed
    • changedInput schema / properties / address / description
      Previous value: -"Solana wallet address (base58)."New value: +"Wallet address: Solana base58, EVM 0x, Tron T, Sui 0x (64 hex), or TON."
    • addedInput schema / properties / chain
      Added value: +{
+  "description": "Optional: one chain id, or a comma list (base,ethereum), to limit an EVM address to those chains.",
+  "type": "string"
+}
    • addedInput schema / properties / tokens
      Added value: +{
+  "description": "Optional comma list of up to 10 ERC-20 contract addresses to read; requires chain to name a single chain.",
+  "type": "string"
+}
  4. Changed3 schema fields changed
    • changedInput schema / properties / address / description
      Previous value: -"Wallet address: Solana base58, EVM 0x, Tron T, Sui 0x (64 hex), or TON."New value: +"Solana wallet address (base58)."
    • removedInput schema / properties / chain
      Removed value: -{
-  "description": "Optional: one chain id, or a comma list (base,ethereum), to limit an EVM address to those chains.",
-  "type": "string"
-}
    • removedInput schema / properties / tokens
      Removed value: -{
-  "description": "Optional comma list of up to 10 ERC-20 contract addresses to read; requires chain to name a single chain.",
-  "type": "string"
-}
  5. Changed3 schema fields changed
    • changedInput schema / properties / address / description
      Previous value: -"Solana wallet address (base58)."New value: +"Wallet address: Solana base58, EVM 0x, Tron T, Sui 0x (64 hex), or TON."
    • addedInput schema / properties / chain
      Added value: +{
+  "description": "Optional: one chain id, or a comma list (base,ethereum), to limit an EVM address to those chains.",
+  "type": "string"
+}
    • addedInput schema / properties / tokens
      Added value: +{
+  "description": "Optional comma list of up to 10 ERC-20 contract addresses to read; requires chain to name a single chain.",
+  "type": "string"
+}
  6. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the parallel multi-chain read behavior, the cost of $0.01, EIP-7702 delegation detection, and OFAC sanctions screening. These are behavioral traits not derivable from the 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?

A single dense sentence that front-loads the core resource and chains, then lists outputs and closes with cost. Every clause carries information. It is slightly run-on, but no sentence is wasted.

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?

With no output schema, the description carries the return-value burden and does so by enumerating the report contents (balances, holdings, account type, activity, sanctions, flags) and disclosing cost. An agent knows what it gets and what it pays. Pagination/response format is the only minor omission.

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%, so the schema already documents chain, tokens and address fully (including the single-chain constraint for tokens). The description's mention of parallel chain reads lightly reinforces the chain parameter but adds no syntax or format 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?

States a specific verb+resource (on-chain wallet profile) and enumerates exactly what is returned: balances, valued holdings, account type, activity, OFAC screening, ranked flags. It clearly conveys multi-chain coverage. However, it never names or contrasts the obvious sibling get_evm_wallet_snapshot, leaving the agent to infer the boundary between them.

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 implied by the enumerated outputs and the disclosed $0.01 cost, which helps a cost-sensitive agent decide. But there is no explicit when-to-use, when-not-to-use, or alternative (e.g. get_evm_wallet_snapshot for EVM-only, cheaper paths) guidance.

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

All Saylor Innovations: pay-per-call data toolsInspect
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