loophole-tape

Push pump.fun and Robinhood Chain alerts to Discord or Telegram ($0.10)

subscribe_alerts

$0.10 USDC once, for 30 days. Use when a Discord or Telegram room wants new pump.fun memecoins with high graduation odds, true graduations, avoid flips or Robinhood Chain ring flags posted to it without running a server; to poll from code use GET /v1/launches/since ($0.001). Input: destination (a Discord webhook URL or telegram::), kinds (array of graduation_odds, ring_flags, graduations, avoid_flips), optional min_p_grad, max_age_s, pumpfun_only, rhc_only, label. One payment registers your room's own delivery endpoint for 30 days: a Discord webhook URL, or telegram:: for a Telegram bot you own; any other host is refused unpaid. A test message is posted first and the payment settles when it arrives; a failed test is unpaid. Then every 60 s each new item of the kinds you pick is posted as one plain-text message ending with its public record and paid card links: graduation_odds and graduations are the items of our free Atom feeds (5 minutes delayed), ring_flags the Robinhood Chain pons ring-structure flags, avoid_flips a published graduation candidate whose verdict turns avoid. Filters min_p_grad, max_age_s, pumpfun_only, rhc_only; at most 20 messages an hour and 200 a day. The endpoint is stored encrypted and never echoed or logged: POST it in the JSON body. POST, or GET with the X-Alert-Destination header, is the same purchase. Unsubscribe with the link in the answer. Returns a JSON envelope with data{subscription_id, status, kinds, filters, label, destination_kind, test_delivery, registered_at, expires_at, unsubscribe_url, delivery}.

Input Schema

TableJSON Schema

Name	Required	Description
`kinds`	Yes	One or more of graduation_odds, ring_flags, graduations, avoid_flips.
`label`	No	optional name printed at the start of every message (letters, digits, spaces and basic punctuation)
`rhc_only`	No	true: leave out the pump.fun kinds
`max_age_s`	No	keep items whose launch was at most this many seconds old when the item was recorded; for graduations the time to graduation (0 = no limit)
`min_p_grad`	No	graduation_odds and avoid_flips: keep items whose P(true graduation) at publication is at least this (0 = no floor)
`destination`	Yes	Your room's delivery endpoint: a Discord webhook URL https://discord.com/api/webhooks/<id>/<token>, or telegram:<bot_token>:<chat_id> for a Telegram bot you own. Send it in the POST JSON body or the X-Alert-Destination header: a query string can be recorded by proxies.
`pumpfun_only`	No	true: leave out the Robinhood Chain kind (ring_flags)

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 24, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Reveals far more than annotations: one-time payment, 30-day validity, test message before settlement, 60-second delivery cadence, hourly/daily rate limits, encrypted endpoint storage, and how to unsubscribe. It also discloses that a failed test message is unpaid, clarifying the side-effect and payment behavior.

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?

Despite being long, every sentence carries operational information: pricing, use case, input format, delivery mechanics, rate limits, security, and response shape. The most important differentiator (use case and alternative) is front-loaded, and details are logically organized.

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 paid subscription with multiple parameters, rate limits, and delivery behavior, the description covers everything needed to call correctly: destination format, kind enum, filters, payment flow, allow/deny hosts, output envelope fields, and unsubscription. The output schema is also described, so no major gaps remain.

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% already, but the description adds meaningful context beyond the schema: it explains what each kind represents (e.g., avoid_flips is a published graduation candidate whose verdict turns avoid), mentions the 5-minute Atom feed delay, and clarifies filter interactions. This enriches rather than merely repeats schema descriptions.

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+resource: subscribe to push pump.fun/Robinhood Chain alerts to Discord or Telegram. It clearly distinguishes itself from polling via GET /v1/launches/since and lists the alert kinds (graduation_odds, ring_flags, graduations, avoid_flips).

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 gives the condition to use this tool: when a Discord/Telegram room wants alerts 'without running a server'. It names the alternative polling endpoint and even compares pricing ($0.10 vs $0.001), giving the agent clear decision criteria.

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.