token-launcher

ponzu_trigger_launch

Triggers DEX launch for a sold-out Ponzu presale by creating a liquidity pool with all raised ETH and 310,000 tokens.

Instructions

Trigger DEX launch for a Ponzu presale that has sold out. Creates the PonzuSwap liquidity pool with all raised ETH + 310,000 tokens. Anyone can call this once presale is sold out.

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": {
      "presaleAddress": "<presaleAddress>"
    },
    "name": "ponzu_trigger_launch"
  }
}

Input Schema

Name	Required	Description	Default
`presaleAddress`	Yes	Presale contract address

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Jul 5, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the core action (creating a liquidity pool with specific token amounts) and that anyone can call it. However, it lacks details on potential side effects (e.g., if called multiple times), failure modes (e.g., if presale not sold out), or gas implications, leaving some behavioral uncertainty.

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?

Description consists of three concise sentences with no filler. The first sentence states the action, the second provides details, and the third gives a usage condition. It is front-loaded with essential information.

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

Completeness3/5

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

Given a single parameter, no output schema, and no annotations, the description covers the purpose, condition, and basic mechanism. However, it lacks information on return values (e.g., transaction hash) or possible error scenarios (e.g., calling when not sold out), which would be helpful for an agent to verify success.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, presaleAddress, is described as 'Presale contract address' in the schema. The description does not add meaningful context beyond the schema, such as format requirements (hex string) or that it must be the address of a sold-out presale. Schema coverage is 100%, so baseline is 3, but the description fails to add extra value.

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?

Description clearly states the tool triggers a DEX launch for a sold-out presale by creating a liquidity pool with specific amounts (all raised ETH + 310,000 tokens). The verb 'Trigger' and resource 'DEX launch/PonzuSwap liquidity pool' are specific and distinguish it from sibling tools like ponzu_presale_buy or ponzu_claim_tokens.

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?

Description specifies the condition: 'once presale is sold out' and that anyone can call it. This provides clear when-to-use guidance. However, it does not explicitly state when not to use it or mention alternatives, which are not needed given the unique action among siblings.

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

Deploy Server