Skip to main content
Glama

Credit Score

wallet.credit_score
Read-onlyIdempotent

Calculate an on-chain credit score (0-100) for any wallet. Factors: transaction history, native balance, token diversity, stablecoin holdings, DeFi activity. Returns grade (AAA to C). Use for a wallet's on-chain financial behavior and activity score. It is not an agent identity or reputation registry result and does not assess a token or contract; use agent.reputation for trust signals and token.risk or security.contract.scan for asset risk.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNoEVM chain only. Supported chains: base, ethereum, arbitrum, optimism, polygon, bsc, avalanche, zksync, linea, scroll, blast, mantle, gnosis, polygon-zkevm, mode, sei, celo, manta, taiko, fantom, cronos, opbnb, zora, worldchain, metis, fraxtal, kava, zetachain, filecoin, core-dao, aurora, moonbeam, klaytn, bob, canto, monad, tempo, megaeth, arc, plasma, katana, robinhood, pharos, hyperevm.base
addressYesWallet address to score

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainYesBlockchain queried
gradeYes
walletYesAddress
factorsYes
maxScoreYes
timestampYesUnix timestamp ms
creditScoreYes
descriptionYes
methodologyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/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 behavior context beyond that: the exact factors that feed the score and the grade band it returns. It stops short of noting rate limits, indexer freshness, or whether contract addresses are accepted, which keeps it out of the top band.

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?

Front-loaded with purpose, then factors, then routing exclusions; every sentence carries weight. There is minor redundancy between the opening sentence and the 'Use for a wallet's on-chain financial behavior and activity score' sentence, which restates the same idea.

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?

An output schema exists, so return values need not be explained, and the schema plus annotations cover parameters and safety. The description supplies the remaining missing pieces: what the score means, what feeds it, and when to pick a different tool.

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 chain enum is fully enumerated in the schema, so the schema already does the parameter work. The description adds no address format, chain-default, or EVM-only detail beyond what the schema states, which is the expected baseline.

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?

States a specific verb and resource (calculate an on-chain credit score for a wallet), specifies the output range 0-100 and grade band AAA to C, and enumerates the scoring factors. It explicitly distinguishes itself from agent.reputation, token.risk, and security.contract.scan, so an agent can separate it from siblings without opening any schema.

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?

Gives an explicit use case ('a wallet's on-chain financial behavior and activity score') and explicit exclusions with named alternatives: not agent identity/reputation (use agent.reputation), not token or contract assessment (use token.risk or security.contract.scan). Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources