Rug Munch Intelligence

watch_token

Monitor cryptocurrency tokens for risk changes, rug pulls, or price drops and receive real-time alerts via webhook notifications.

Instructions

Set up real-time token monitoring with webhook alerts. When risk changes, rug detected, or price drops, we POST to your webhook. Covers 7 days. No other service offers proactive rug detection. Cost: $0.20.

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_address": "<token_address>",
      "webhook_url": "<webhook_url>"
    },
    "name": "watch_token"
  }
}

Input Schema

Name	Required	Description	Default
`token_address`	Yes
`webhook_url`	Yes	HTTPS URL to POST alerts to
`watch_type`	No		rug_detected

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Mar 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a setup operation with ongoing monitoring, specifies cost ($0.20), duration (7 days), and the alert mechanism (POST to webhook). It could improve by mentioning rate limits or error handling, but covers essential operational details.

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 front-loaded with the core purpose, followed by key details (events, duration, uniqueness, cost) in a compact three-sentence format. Every sentence adds value without redundancy, making it highly efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (setup for ongoing monitoring), lack of annotations, and no output schema, the description is largely complete: it covers purpose, behavior, parameters, and cost. It could be enhanced by specifying response format or error cases, but for a tool with structured input schema, it provides sufficient context for effective use.

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 description coverage is low (33%), with only webhook_url documented. The description compensates by adding meaning: it implies token_address is for monitoring, explains watch_type options (risk changes, rug detected, price drops), and clarifies the webhook_url's role in alerts. However, it doesn't detail token_address format or default behaviors beyond watch_type.

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 clearly states the tool's purpose with specific verbs ('Set up real-time token monitoring with webhook alerts') and resources ('token'), distinguishing it from siblings like check_token_risk (which appears to be a one-time check) by emphasizing proactive, continuous monitoring. It explicitly mentions unique features like 'proactive rug detection' and '7 days' coverage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: for real-time monitoring with alerts on specific events (risk changes, rug detected, price drops). However, it does not explicitly state when not to use it or name alternatives among siblings, such as check_token_risk for one-time assessments, leaving some guidance implicit.

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