SiteCheck Crypto & Finance

Solana SPL mint audit from the chain: program, authorities

crypto_solana_token_extensions

Read-only

Solana SPL mint audit from the chain: program (Token or Token-2022), authorities, supply and decimals, plus Token-2022 extensions with risk flags for permanent delegate, transfer hook, transfer fee, default frozen state and mint close. Reads the mint account only; it does not check holders or liquidity. Related tools on this server, for a different need: crypto_solana_validator_cluster when you need Solana validator snapshot from the public RPC: active; crypto_jupiter_solana_routing when you need Jupiter aggregator quote on Solana for an exact-input swap. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "mint": "<mint>"
    },
    "name": "crypto_solana_token_extensions"
  }
}

Input Schema

Name	Required	Description	Default
`mint`	Yes	Solana mint address (base58, 32 to 44 characters)

Output Schema

Name	Required	Description	Default
`mint`	No
`flags`	No
`source`	No
`supply`	No
`program`	No
`decimals`	No
`checkedAt`	No
`extensions`	No
`mintAuthority`	No
`freezeAuthority`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover readOnlyHint and openWorldHint, so the safety profile is known; the description still adds real context beyond them: the read is limited to the mint account (no holder/liquidity data), and it discloses the x402 payment model ($0.002 USDC per successful call, failed calls not charged, payable on Base/Solana/Arc). The only gap is that it doesn't mention rate limits, latency, or behavior on an invalid/non-existent mint address.

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?

The purpose and scope are front-loaded in the first two sentences, and the alternative-routing and pricing sentences come after. The sibling-routing clause is a bit listy and could be trimmed, but every sentence carries information an agent needs (capability, exclusion, alternatives, cost).

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?

For a single-parameter, read-only chain-lookup tool with an output schema present, the description covers capability, scope limits, sibling disambiguation, and cost/payment mechanics. Nothing an agent needs to decide to call it or to interpret the call setup is missing.

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?

There is a single parameter with 100% schema description coverage ('Solana mint address, base58, 32 to 44 characters'), so the schema carries parameter semantics fully. The description adds no format or validation detail beyond that, which is the expected baseline when schema coverage is complete.

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?

The description opens with a specific verb+resource ('Solana SPL mint audit from the chain') and enumerates exactly what is returned: program (Token vs Token-2022), authorities, supply/decimals, and Token-2022 extensions with named risk flags. It also draws a scope boundary ('Reads the mint account only; it does not check holders or liquidity'), which separates it from holder-concentration and liquidity siblings without the agent needing to open a 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?

It states the use case (mint authority/extension risk audit), states the exclusions explicitly ('does not check holders or liquidity'), and routes to named alternatives with the condition that selects them (crypto_solana_validator_cluster for validator snapshots, crypto_jupiter_solana_routing for swap quotes). Nothing about when to pick this tool 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.

All SiteCheck Crypto & Finance 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?