Skip to main content
Glama
Sign In

Vike Data API

by io.vike
OverviewDiscussionsAdmin

Wallet Label Provenance

wallet_label_provenance
Read-onlyIdempotent

Full multi-source label cascade for one ETH wallet. Returns labels from several third-party label providers and the heuristic classifier with per-source attribution and a consensus entity/type. Source provider_e covers addresses that are, control or funded Polymarket wallets (category pm_wallet / pm_owner / pm_funder, with n_wallets, volume_usd, realized_pnl_usd, top_wallet and its public name) and mass payers of those wallets (bridge, exchange, batch_sender, campaign, pm_rewards_payer, ...), with basis onchain_fact or behaviour_inferred / behaviour_corroborated (a guess from behaviour) and evidence; it answers for an address on any EVM chain, and never feeds the consensus. found is true when any source knows the address. Use when the user asks 'what do you know about this address', 'who labeled this wallet' or 'is this a Polymarket trader'.

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": {
      "address": "<address>"
    },
    "name": "wallet_label_provenance"
  }
}

Input Schema

NameRequiredDescriptionDefault
addressYesWallet address (0x-prefixed hex)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld=false/idempotent, and the description adds genuinely non-structural behavior: the provider_e caveat 'never feeds the consensus', the basis distinction onchain_fact vs behaviour_inferred/behaviour_corroborated, and the meaning of the `found` flag. Density is high but the disclosure is real; only the return shape/pagination is left unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The lead sentence is well front-loaded, but the middle collapses into a long run-on listing categories (pm_wallet / pm_owner / pm_funder, n_wallets, volume_usd, realized_pnl_usd, ...) that would read better as a structured list. Content mostly earns its place; the packaging does not.

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 one fully described parameter, no output schema, and complete safety annotations, the description carries the necessary burden by explaining sources, consensus, and the `found` signal. Only the concrete response shape is unaddressed, which is minor here.

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 coverage is 100% and the single `address` parameter is fully documented in the schema, so the baseline applies. The description does add a subtlety (provider_e answers for any EVM chain, while the tool is framed for an ETH wallet), but that is scope, not parameter syntax.

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?

Opens with a specific verb+resource: 'Full multi-source label cascade for one ETH wallet', followed by what it returns (per-source attribution plus consensus entity/type). It implicitly distinguishes itself from wallet_batch_labels and polymarket_wallet by scope, but never names a sibling directly, so it stops short of a 5.

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

Usage Guidelines4/5

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

Gives three concrete trigger phrasings ('what do you know about this address', 'who labeled this wallet', 'is this a Polymarket trader') that map user intent to this tool. It provides no when-not guidance and does not route the agent to an alternative (e.g. wallet_batch_labels for many addresses), so it misses the 5 bar.

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

All Vike Data API 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