Skip to main content
Glama
arcnow-io

@arcnow/mcp

Official
by arcnow-io

Recent token launches

arcnow_list_tokens
Read-onlyIdempotent

List recent token launches on Arc, newest first. Filter by creator and optionally fetch live curve state to monitor graduation progress.

Instructions

Recent arcnow.io launches, newest first, read from the launchpad's Launched log.

There is no index and no backend behind this: it walks the chain backwards from the tip in bounded chunks, so it sees a WINDOW of recent history and the result says exactly which blocks it covered. If it stopped on its budget before finding what you asked for, that is reported and is not the same as 'there are no more' — do not tell a user a token does not exist on the strength of this tool.

Filter by creator to find what one address launched. Set includeState to false when you only need the addresses; each token's curve state is an extra round trip.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many launches to return. Each one with includeState costs a round trip.
creatorNoOnly launches by this creator address.
includeStateNoAlso read each curve's live state: price, reserve, progress to graduation, whether it graduated. Off is faster and tells you only what the launch log recorded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the lack of an index/backend, the bounded backward chain walk, the meaning of budget exhaustion, and the extra round-trip cost of `includeState`. This is substantive behavioral context that annotations alone would not convey.

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 listing behavior and every paragraph adds distinct information: purpose, window limitation, and parameter guidance. No sentence is filler.

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?

Even without an output schema, the description tells the agent what the result will contain (addresses, optional curve state, covered blocks) and how to interpret a budget stop. This is complete for correct invocation and result interpretation.

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 structured descriptions already handle the parameters. The description adds value by mapping `creator` to a use case and by framing `includeState` around a trade-off between speed and returned data.

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 opens with 'Recent arcnow.io launches, newest first' and identifies the source as the launchpad's `Launched` log. This names a specific verb and resource and is clearly distinct from siblings like arcnow_token or arcnow_list_platforms.

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?

It provides concrete conditional guidance: use `creator` to find a single address's launches and set `includeState` to false when only addresses are needed. It also gives a clear 'when not' by warning that the bounded window must not be used to assert nonexistence, though it doesn't explicitly name alternative sibling tools.

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