Moby

Scan for tokens that pass a strategy

scan_tokens

Read-only

THE first call of a scheduled scan: Moby applies a strategy's thresholds server-side and returns only the Solana tokens that pass, already deduplicated for this user. Empty qualifiers = end the run silently. Pass the previous run's next_since back as since: tokens returned to you for the same rules in the last (the preset's scan interval, 5-15 min) are dropped. Deep-check ONLY the qualifiers, with get_token_trade_brief and get_whale_wallet_profiles; agent_checks is what the scan did NOT check, so apply it yourself. rejected counts why candidates failed; null fields are left out. At most 12 candidates are enriched per scan (wallets desc, liquidity desc, market cap desc, smart-money h1 desc, address asc); the rest come back as not_enriched in that order, first = next in line. An override replaces that one rule of the preset. safety_tier: grey is NOT a red flag; red = caution, and Moby refuses agent buys on red.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scan_tokens"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max qualifiers, 1-10.
`since`	No	`next_since` from the previous scan. Omit on the first run. ISO 8601 UTC, e.g. `2026-08-11T14:30:00Z`.
`is_new`	No	Override: only new launches (true) or only not new.
`sources`	No	Override: candidate sources.
`strategy`	No	Strategy preset (its id from list_strategies). Omit only to scan with overrides alone.
`launchpad`	No	Override: only tokens from this launchpad.
`min_wallets`	No	Override: min distinct tracked wallets buying.
`smart_money`	No	Override: `not_selling` (h1 flow >= 0), `inflow` (h1 > 0), `inflow_h1_h4`, `any`.
`mover_period`	No	Override: `movers` source period.
`safety_tiers`	No	Override: allowed safety tiers.
`mark_reported`	No	false = a look that does not count as returned (a pre-check). Default true.
`max_top10_pct`	No	Override: max % of supply in the top 10 holders.
`min_liquidity`	No	Override: min liquidity, USD.
`max_market_cap`	No	Override: max market cap, USD.
`min_market_cap`	No	Override: min market cap, USD.
`wallet_actions`	No	Override: whale-buy kinds counted (`buy` = any buy).
`mover_event_types`	No	Override: `movers` source event types (values from get_screener_event_filters).
`min_wallet_buy_usd`	No	Override: min USD per counted wallet buy.
`exclude_asset_classes`	No	Override: drop these asset classes before enrichment (unknown class is kept).
`wallet_window_minutes`	No	Override: window for counting those wallets.
`max_price_change_pct_h4`	No	Override: max 4h price change, % (-10 = down >= 10% over 4h).
`min_price_change_pct_h4`	No	Override: min 4h price change, % (20 = up >= 20% over 4h).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedNov 8, 2026
- removedInput schema / properties / exclude_asset_classes / title
```
Removed value: -"Exclude Asset Classes"
```
- removedInput schema / properties / is_new / title
```
Removed value: -"Is New"
```
- removedInput schema / properties / launchpad / title
```
Removed value: -"Launchpad"
```
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / mark_reported / title
```
Removed value: -"Mark Reported"
```
- removedInput schema / properties / max_market_cap / title
```
Removed value: -"Max Market Cap"
```
- removedInput schema / properties / max_price_change_pct_h4 / title
```
Removed value: -"Max Price Change Pct H4"
```
- removedInput schema / properties / max_top10_pct / title
```
Removed value: -"Max Top10 Pct"
```
- removedInput schema / properties / min_liquidity / title
```
Removed value: -"Min Liquidity"
```
- removedInput schema / properties / min_market_cap / title
```
Removed value: -"Min Market Cap"
```
- removedInput schema / properties / min_price_change_pct_h4 / title
```
Removed value: -"Min Price Change Pct H4"
```
- removedInput schema / properties / min_wallet_buy_usd / title
```
Removed value: -"Min Wallet Buy Usd"
```
- removedInput schema / properties / min_wallets / title
```
Removed value: -"Min Wallets"
```
- removedInput schema / properties / mover_event_types / title
```
Removed value: -"Mover Event Types"
```
- removedInput schema / properties / mover_period / title
```
Removed value: -"Mover Period"
```
- removedInput schema / properties / safety_tiers / title
```
Removed value: -"Safety Tiers"
```
- removedInput schema / properties / since / title
```
Removed value: -"Since"
```
- removedInput schema / properties / smart_money / title
```
Removed value: -"Smart Money"
```
- removedInput schema / properties / sources / title
```
Removed value: -"Sources"
```
- removedInput schema / properties / strategy / title
```
Removed value: -"Strategy"
```
- removedInput schema / properties / wallet_actions / title
```
Removed value: -"Wallet Actions"
```
- removedInput schema / properties / wallet_window_minutes / title
```
Removed value: -"Wallet Window Minutes"
```
- removedInput schema / title
```
Removed value: -"scan_tokensArguments"
```

Changed3 schema fields changedNov 6, 2026

addedInput schema / properties / exclude_asset_classes

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "const": "tokenized_stock",
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Override: drop these asset classes before enrichment (unknown class is kept).",
+  "title": "Exclude Asset Classes"
+}

addedInput schema / properties / max_price_change_pct_h4

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Override: max 4h price change, % (-10 = down >= 10% over 4h).",
+  "title": "Max Price Change Pct H4"
+}

addedInput schema / properties / min_price_change_pct_h4

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Override: min 4h price change, % (20 = up >= 20% over 4h).",
+  "title": "Min Price Change Pct H4"
+}

AddedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly=true and destructive=false, and the description adds substantial behavior beyond them: server-side thresholding, per-user deduplication over a 5-15 minute window, a hard cap of 12 enriched candidates with a stated tie-break order, `not_enriched` queueing order, `rejected` counts, null-omission, and the safety-tier rule that grey is not a red flag and that Moby blocks agent buys on red. The non-idempotent hint is consistent with the since-based deduplication.

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-loaded with the essential role and the empty-result exit, and nearly every sentence carries operational information. However, it is a dense run-on chain, and the literal '<window>' placeholder ('in the last <window>') is awkward in an otherwise precise definition.

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 22-parameter, zero-required tool with an output schema, the description covers the workflow position, the qualifying output fields (qualifiers, rejected, not_enriched, next_since), the enrichment cap, and the safety-tier rule. An agent could run the scan and hand off correctly without reading anything else.

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%, so the baseline would be 3, but the description adds real semantics: `since` must be the previous run's `next_since`, overrides replace exactly one preset rule, `mark_reported=false` makes a look not count as returned, and safety_tiers only accepts green/grey because red is refused. A few override parameters (mover_event_types, wallet_window_minutes, exclude_asset_classes) are left to the schema alone.

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 action and object: 'first call of a scheduled scan' where 'Moby applies a strategy's thresholds server-side and returns only the Solana tokens that pass'. It also distinguishes the tool from siblings by naming the actual downstream tools for deep-checking (get_token_trade_brief, get_whale_wallet_profiles) and by clarifying that overrides only replace one preset rule.

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?

Explicit positioning as 'THE first call of a scheduled scan', plus a concrete termination rule ('Empty qualifiers = end the run silently') and explicit next steps (deep-check ONLY the qualifiers, get_token_trade_brief, get_whale_wallet_profiles). It also warns that `agent_checks` is what the scan did NOT cover, so the agent must apply it, and explains how to chain runs via since/next_since.

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

All Moby 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.

Resources

Need Help?