Skip to main content
Glama

What did the dev do?

dev_check
Read-only

The wallet that launched a token and what it did since: when it launched, how much it received, how much it still holds, how much it sold (how many sells, when, and roughly what that's worth), which wallets it sent tokens to and what they hold now. Tokens on Robinhood Chain, Ethereum or Base, or a Solana mint (the dev is whoever paid to create the mint; sells are in SOL). Use for 'is the dev selling?', 'did the dev dump?', 'who launched this?'. To see where the dev's money went on Robinhood Chain, follow up with wallet_flows on the deployer. Works for 0x tokens on Robinhood Chain, Ethereum and Base (pass chain, or it finds the chain); on Ethereum and Base the dev is whoever created the token's contract, and a very busy token is read from its most recent transfers. Premium: 2¢ a call from prepaid agent credits (3 free premium calls a day). Send your agent key as Authorization: Bearer .

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "token": "<token>"
    },
    "name": "dev_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNoFor a 0x address: the chain. Default: Robinhood Chain if the token is there, else Ethereum, else Base
tokenYesToken contract address (0x...) on Robinhood Chain, Ethereum or Base, or a Solana mint

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / chain
      Added value: +{
      +  "description": "For a 0x address: the chain. Default: Robinhood Chain if the token is there, else Ethereum, else Base",
      +  "enum": [
      +    "robinhood",
      +    "ethereum",
      +    "base"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / token / description
      Previous value: -"Token contract address (0x...) on Robinhood Chain, or a Solana mint"New value: +"Token contract address (0x...) on Robinhood Chain, Ethereum or Base, or a Solana mint"
  2. Changed1 schema field changed
    • changedInput schema / properties / token / description
      Previous value: -"Token contract address (0x...) on Robinhood Chain"New value: +"Token contract address (0x...) on Robinhood Chain, or a Solana mint"
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description adds real value: pricing (2¢ per call, 3 free premium calls/day), Authorization: Bearer <key> requirement, and a data-completeness caveat that very busy tokens are read from most recent transfers. The one gap is that it doesn't say what happens on failure or whether results are cached/stale beyond that transfers note.

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?

Output enumeration is front-loaded and every major clause carries information (usage phrasings, chain scope, pricing/auth). It loses a point for repeating the chain coverage twice ('Tokens on Robinhood Chain, Ethereum or Base' and later 'Works for 0x tokens on Robinhood Chain, Ethereum and Base').

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?

There is no output schema, and the description compensates by itemizing exactly what is returned for the deployer. Combined with pricing, auth, chain scope, and the follow-up tool recommendation, an agent has everything needed to decide and call correctly.

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 baseline is 3, but the description adds semantics the schema lacks: what 'the dev' actually means per chain (contract creator on Ethereum/Base, mint payer on Solana) and that sell values are denominated in SOL for Solana mints. The chain auto-detection order is largely duplicated from the schema and is the only redundant piece.

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 leads with a concrete verb+resource: the wallet that launched a token and what it did since, then enumerates the outputs (launch time, received, holdings, sells with count/timing/value, recipient wallets). It is clearly distinguishable from siblings like check_seller, bundle_check and snipe_check because it centers on the deployer's own behavior.

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?

It supplies explicit user-phrasings that select this tool ('is the dev selling?', 'did the dev dump?', 'who launched this?') and names the follow-up path (wallet_flows on the deployer for Robinhood Chain money movement). Chain applicability and the 0x-vs-Solana-mint split further define the invocation context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.