Skip to main content
Glama
Sign In

chaink9

by com.chaink9
OverviewDiscussionsAdmin

report

Read-only

The latest stored ChainK9 report for a token on BNB Smart Chain, Ethereum, Base or Arc, without running a new scan; its tier field says whether it was a lite, full or ultra scan. Most funded new launches are scanned in the background within minutes of their first liquidity and re-scanned an hour later, so this is usually the fastest answer for a new token. Not charged if the token was never scanned on that chain (404). Costs $0.002 per successful call in USDC on Base, Polygon, Arbitrum, Avalanche, BNB Smart Chain (USDT) or Solana, paid with x402 in the call's _meta; failed calls are free.

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": {
      "token": "<token>"
    },
    "name": "report"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNobsc (BNB Smart Chain, the default), eth (Ethereum) or base (Base)
tokenYesToken address on the chosen chain

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations it discloses the 404 no-charge behavior, the exact per-call price, the accepted payment chains, the x402-in-_meta payment mechanism, and that failed calls are free. The background scan cadence (within minutes of first liquidity, re-scan an hour later) and tier semantics explain staleness risk that annotations could never convey.

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-loads the core claim and the scan-avoidance distinction, then layers freshness and cost. The payment sentence is long and rail-heavy, but each clause carries information an agent needs before committing to a paid call.

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 lookup with no output schema, it covers everything that matters: what is returned, what the tier field means, freshness guarantees, failure behavior, and cost. An agent can decide and call without further information.

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 both parameters are already documented, giving a baseline of 3. The description adds chain-name expansions and mentions the tier output, but does not clarify the 'arc' enum value that appears in the schema yet is absent from the chain property's own description, leaving a small ambiguity unresolved.

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?

Names a specific verb and resource ('latest stored ChainK9 report for a token') and explicitly scopes it as 'without running a new scan', which separates it from the scan/scan-lite/scan-ultra siblings. The supported chains and the meaning of the tier field are stated up front.

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 a clear selection rule — 'usually the fastest answer for a new token' because funded launches are pre-scanned in the background — and implicitly routes fresh-scan needs elsewhere via 'without running a new scan'. It never names a specific alternative sibling (e.g. scan-ultra) as the fallback when no stored report exists, so exclusion guidance stays implicit.

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

All chaink9 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