A memecoin research agent should do more than watch a token ticker and ask a language model whether the chart looks bullish. Before it can make a useful decision, it has to answer more specific questions: who launched this token, who was buying it, which wallets are actually profitable, how reliable is the signal, and what changed since the last check?
Those are separate data problems. Solana and Robinhood Chain also have different market structures, data sources and definitions of token-launch success. A prompt alone cannot turn an unobserved transaction into a verified trade.
This tutorial uses the six read-only actions of the MadeOnSol Agent Intelligence Gateway to design a reproducible research workflow. Each response includes source evidence and explicit coverage limits, so your agent can distinguish an observed fact from missing data.
For a broader explanation of existing MCP-based research, read Use the MadeOnSol MCP Server in Claude and Cursor. For the technical action contract, see the Agent Gateway reference.
What your agent will investigate
Consider a newly launched Solana token showing an unusual burst of tracked KOL activity. A careful research agent can perform six tasks in order:
discover_opportunities — find tokens with observed multi-KOL activity or relevant launch context.evaluate_token — inspect risk factors, liquidity and buyer quality; record which checks were unavailable.inspect_deployer — look at the creator's indexed past launches and outcomes rather than judging a token in isolation.inspect_wallet — investigate a relevant buyer or tracked wallet and its observed trading performance.evaluate_signal — check the historical reliability of the signal and its sample size.changes_since — resume a bounded journal of relevant changes instead of re-fetching the same snapshot indefinitely.
These are intelligence tools, not buy/sell instructions. They neither sign swaps nor guarantee that a token is safe. An agent that does act on signals needs its own execution, sizing, risk and custody systems.
Step 1: Choose the right data-access model
Use a subscription API key for a production bot with recurring usage. The gateway preserves subscription identity and tier checks on the underlying data, so one high-level tool should not silently bypass an ULTRA-only source. For a customer-facing terminal or data product, read the commercial redistribution terms — a BUSINESS or Enterprise agreement may be required.
For occasional experiments, MadeOnSol already has x402 pay-per-call data routes. Eligible calls return an HTTP 402 challenge with payment amount, token and network; an authorized wallet client can pay and retry. Do not assume that every new six-tool composite is available on the x402 rail merely because an underlying token-risk endpoint has a price. Check the Solana x402 catalog and Robinhood Chain x402 options.
MCP is a tool protocol, not a payment plan. Agents can use MCP over authorized API-key access or supported wallet-funded endpoints. See MCP servers and SDKs.
Step 2: Ask a structured question, not a free-form recommendation
The intended Gateway transport accepts a named action and a strict JSON input. This call discovers candidate tokens from the supported tracked-KOL universe:
{
"tool": "discover_opportunities",
"input": {
"chain": "solana",
"lookback": "1h",
"min_kols": 2,
"limit": 10
}
}
The lookback and result count are bounded so one agent request cannot fan out into an unlimited chain scan.
A discovery result should be treated as a candidate shortlist, not a complete universe of all onchain tokens. Solana launchpad context and Robinhood Chain launchpad context are not interchangeable. On Robinhood Chain, the indexed KOL-coordination query covers the requested supported window rather than simply ranking the newest 1,000 KOL-trade rows, but it still describes the tracked KOL cohort, not every wallet on the chain.
Step 3: Run an inspectable workflow
The example below uses Node.js 20+ with the native fetch API. Configure a paid API key and valid addresses in environment variables. The example calls the subscriber REST endpoint and does not sign a transaction or spend wallet funds.
export MADEONSOL_API_KEY="msk_your_subscriber_key"
export SOLANA_TOKEN_MINT="paste_a_valid_token_mint"
export SOLANA_DEPLOYER_WALLET="paste_the_verified_creator_wallet"
export SOLANA_WALLET_TO_CHECK="paste_a_wallet_to_investigate"
const apiKey = process.env.MADEONSOL_API_KEY;
const tokenMint = process.env.SOLANA_TOKEN_MINT;
const deployer = process.env.SOLANA_DEPLOYER_WALLET;
const wallet = process.env.SOLANA_WALLET_TO_CHECK;
if (![apiKey, tokenMint, deployer, wallet].every(Boolean)) {
throw new Error("Provide an API key and all three valid Solana addresses");
}
const URL = "https://madeonsol.com/api/v1/agent-gateway/actions";
async function research(tool, input) {
const response = await fetch(URL, {
method: "POST",
headers: {
Authorization: "Bearer " + apiKey,
"Content-Type": "application/json"
},
body: JSON.stringify({ tool, input }),
signal: AbortSignal.timeout(12000)
});
const result = await response.json();
if (!response.ok) {
throw new Error(tool + " returned HTTP " + response.status +
": " + (result.error ?? "unknown error"));
}
if (result.status !== "available") {
console.warn(tool + " was " + result.status, result.warnings);
}
return result;
}
const chain = "solana";
const discovery = await research("discover_opportunities", {
chain, lookback: "1h", min_kols: 2, limit: 10
});
const token = await research("evaluate_token", { chain, address: tokenMint });
const creator = await research("inspect_deployer", { chain, address: deployer });
const trader = await research("inspect_wallet", { chain, address: wallet });
const scorecard = await research("evaluate_signal", {
chain, signal_name: "runner_rate", history: false
});
const changes = await research("changes_since", {
chain, since: new Date(Date.now() - 10 * 60000).toISOString(), limit: 50
});
console.log(JSON.stringify({
discovery, token, creator, trader, scorecard, changes
}, null, 2));
The three addresses are deliberately provided separately. A token's deployer cannot safely be inferred from its symbol, and the first wallet in a buyers list is not automatically the owner.
For a real deployment, add source-specific validation, incremental caching and logging of reason codes, not raw API keys. Never treat a 503 from an unavailable source as "no risk found."
Step 4: Interpret the token report properly
The most important part of evaluate_token is not a single risk score. It is the list of observable factors and the ones that could not be checked.
A sensible agent distinguishes:
| Observation | What it means | What it does not prove |
|---|
| Two tracked KOLs bought | Activity in a known tracked cohort | That all smart-money wallets are buying |
| Creator has prior graduations | Indexed past outcomes exist | Future success is guaranteed |
| Wallet has positive observed PnL | Performance on measured trades | Current token balances or forward returns |
| Liquidity factor unavailable | The source could not confirm the factor | Liquidity is safe or zero |
| No matching alert in the last page | No match in that bounded feed | Nothing happened across the entire chain |
Robinhood Chain deployer graduation can refer to a $40K peak-market-cap milestone. Solana launchpad bonding refers to curve completion and migration rules. An automated report that treats those as an identical yes/no label will mislead users.
Use the token-risk solution, smart-money solution and existing AI Agents solution for the underlying data and use cases.
Step 5: Check signal reliability before trusting a pattern
One alert is an anecdote, not a strategy. evaluate_signal is intended to retrieve Signal Scorecard history with named metrics, a test horizon and limitations. The supported Solana signal names include runner_rate, coordination_count, dump_cluster_count, recycled_early_buyer_count and scout_first_touch.
Ask whether the sample is large enough, whether outcomes were measured independently of the features used to rank candidates, and whether the signal's baseline is already strong or weak. A high win rate without sample size, market regime and a baseline can be meaningless.
Do not infer that the identical historical Scorecard exists on RHC. The Gateway must report unsupported RHC factors explicitly rather than copying Solana figures.
Step 6: Monitor changes without losing events
Polling a sorted "latest 20" endpoint repeatedly is not a reliable change feed. New events can arrive between requests, and backfills can have older chain timestamps than their database observation time.
changes_since uses an opaque, signed cursor tied to the calling subscriber and chain. Its scope is , not a complete Solana or Robinhood Chain transfer ledger. The cursor has a bounded 24-hour horizon, with additional short-lived storage for replay.
