loophole-tape

Outcome labels for one pump.fun memecoin ($0.001)

mint_outcome

Read-onlyIdempotent

$0.001 USDC per call. Use when you grade your own rug or graduation calls or backtest a signal on pump.fun memecoins and need outcome labels you did not write yourself, by a fixed public rule; for a live pre-trade rug check use GET /v1/check/mint ($0.005). Input: mint (any pump.fun mint, a mint or a pump.fun/gmgn/solscan/birdeye link). The outcome of one pump.fun launch from our own capture: launch time and age now, whether it rugged by the public rule (a drain from a peak of at least 5 SOL, or a creator dump) and when, whether that happened within 300 s of launch, whether it truly graduated and when it migrated, the creator's first sell, peak and last curve SOL, the mayhem flag, whether each label is settled (resolved) and the rule version. No probabilities and no opinions. A mint we never saw answers known:false and is charged like any answer: not being in our capture is itself the result. Labels settle when our capture closes the curve path, about an hour after it goes quiet (94% of launches are settled 2 to 3 h after launch); until then they read null, never a provisional false. A malformed mint is refused unpaid. Returns a JSON envelope with data{mint, known, source, t0, launched_at, age_at_query_s, creator, mayhem, graduated, migrate_dt_s, migrate_at, rugged, rug_dt_s, rug_at, rugged_within_300s, dev_first_sell_dt_s, peak_rs, terminal_rs, resolved, resolution, label_rule_version}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mint`	Yes	Any pump.fun mint (base58, 32-44 characters); one we never saw answers known:false. Accepts a mint or a pump.fun/gmgn/solscan/birdeye link.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 24, 2026

changedInput schema / properties / mint / description

Previous value: -"Any pump.fun mint (base58, 32-44 characters); one we never saw answers known:false."New value: +"Any pump.fun mint (base58, 32-44 characters); one we never saw answers known:false. Accepts a mint or a pump.fun/gmgn/solscan/birdeye link."

AddedSep 24, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: the tool charges even for unknown mints, malformed mints are refused unpaid, and labels settle about an hour after quiet (94% settled 2-3h after launch). This goes beyond the annotations to explain edge cases, which is excellent. Minor gap: it doesn't explicitly state that results may change over time as labels settle, but it does mention null values until settled.

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

Conciseness5/5

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

The description is dense but well-organized: it front-loads the purpose, pricing, and alternatives, then explains input, output, and edge cases. Every sentence adds information; no fluff. It's long but earns its length given the tool's complexity.

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?

The tool has a rich output schema, and the description maps it out almost field by field. It covers input formats, pricing, settlement, unknown mint behavior, and malformed input handling. For a complex data tool, this is complete enough for an agent to call it correctly without further investigation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already explains the mint parameter well. The description adds extra value by listing the output fields and explaining what happens for unknown mints (known:false) and the settlement behavior. It doesn't need to add more about the parameter itself, but it does enrich the context around it.

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 states a specific verb ('use when you grade... or backtest') and a specific resource ('outcome labels for one pump.fun memecoin'), and it distinguishes itself from sibling tools like mint_outcome_batch and check_pumpfun_risk. It clearly identifies what it does and what it does not do (no probabilities, no opinions).

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 states when to use this tool (grading past calls or backtesting) and when not to (live pre-trade rug check, pointing to a specific sibling). It also mentions pricing, which indirectly signals it's a paid tool. The description is precise about the use case and alternatives.

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

All loophole-tape 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.