Skip to main content
Glama
Sign In

Scienter

by xyz.scienter
OverviewDiscussionsAdmin

Solana token: who launched it

solana_token
Read-onlyIdempotent

Who created a Solana token, and what that wallet's OTHER launches did. Takes a mint — the identifier a user actually has — and resolves the wallet that created it, which requires a census that watched Solana launches prospectively since 2026-09-08.

EVERY NUMBER IT RETURNS COUNTS LAUNCHES BY THAT WALLET, NOT EVENTS IN THIS TOKEN. Never write that the token had launches or has a death rate; the true statement is about its maker, and it is a reason to look harder at the token rather than a measurement of it.

Three outcomes, and they must not be collapsed:

  • flagged: every settled launch by the creating wallet has died.

  • not flagged: that wallet has a settled record and at least one launch survived. This is NOT a positive finding; it means the screen does not fire.

  • no record: either the mint is not one the census publishes evidence for, or its wallet has no settled launch on record. This is the answer for most of the chain and it is NOT a clean result — it is a statement about coverage. Never report it as clear.

What the flag is worth, scored once on a later window: flagged launches were still listed a day later about 0.8% of the time against about 4.3% for the rest, non-overlapping 95% intervals.

It is a NEGATIVE screen. It does not identify anything worth buying, and over this same data every return bucket loses money after costs. Never restate it as a recommendation, a risk score, or a safety verdict.

Case is significant: a mis-cased mint is a different mint and will answer no record.

Call this when a user asks about a specific Solana token, who made it, or whether its creator has a history. Use solana_deployer instead when a deployer wallet is already known.

Args:

  • mint (string): a base58 Solana mint address, exact case.

Input Schema

NameRequiredDescriptionDefault
mintYesA base58 Solana mint (token) address, exact case. Lowercasing it makes it a different mint and the answer will be no record.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Despite readOnly and idempotent annotations, the description adds extensive behavioral context beyond structured fields: the prospective census coverage since 2026-09-08, the distinction between token-level and wallet-level counts, the three non-collapsible outcomes, the measured flag performance, and the explicit negative-screen framing. This is unusually complete disclosure for a read-only tool.

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 description is front-loaded with purpose and structured with clear bullets for the three outcomes. It is long, but the length is largely justified by the interpretive stakes; however, it repeats the case-sensitivity warning already present in the schema and uses several emphatic warnings that could be tightened.

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 one-parameter, read-only, no-output-schema tool with high interpretive risk, the description covers purpose, alternatives, outcomes, coverage limitations, scoring evidence, and prohibited restatements. An agent has enough context to invoke and interpret it correctly.

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 schema itself already documents that mint must be a base58 Solana mint address with exact case. The description reinforces the case-sensitivity point and frames the mint as the identifier a user actually has, but it does not add syntax or validation semantics beyond what the schema provides.

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 precise verb and resource: resolving the creator wallet of a Solana mint and reporting that wallet's other launch history. It clearly distinguishes itself from solana_deployer, which is for when a deployer wallet is already known.

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?

Explicitly says when to call this tool (specific token, who made it, creator history) and names the alternative (solana_deployer) with the condition that selects it. It also explains the three possible outcomes and how they must be interpreted, leaving very little to inference.

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

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