Skip to main content
Glama
arcnow-io

@arcnow/mcp

Official
by arcnow-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Inspect a token and where it trades

arcnow_token
Read-onlyIdempotent

Check a token's price, bonding curve state, graduation status, and where it trades now—bonding curve, Uniswap v4 pool, or nowhere—plus quote token and holder balance.

Instructions

Everything about one arcnow.io token: its metadata, its bonding curve's live state, the price, how far it is from graduation, whether it has graduated — and WHERE IT TRADES NOW: its bonding curve, its Uniswap v4 pool, or nowhere.

For a token in its pool this reports the router this server would trade through, whether that router can actually reach the pool, the PoolManager the liquidity is in (a v4 pool has no address of its own), and what a trade there costs — arcnow.io's fee hook's 0.80% plus the pool's own 0.20% LP fee, 1.00% in all, both read off the pool.

It names the token's QUOTE TOKEN — native USDC or an ERC-20 such as EURC, fixed at launch — with its address and decimals: every amount here, and every amount the trade tools take for this token, is in that quote.

Pass either the token address or its curve address; this works out which it got. Pass holder to include that address's balance and any refund the curve is holding for it.

Two things this tool reports that are easy to misread. The spot price is the marginal price of the next infinitesimal token, NOT the price a trade of any size fills at — use arcnow_quote_buy for that. And 'graduated' and 'migrated' are different states: a curve can have graduated (trading on it is over, permanently) while its pool was never created, which leaves the token tradeable nowhere until somebody runs migrate().

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
holderNoOptional: also report this address's token balance and any of the token's quote the curve is holding for it after a failed payout.
addressYesThe token address, or its curve address. Either works.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and side-effect-free. The description adds valuable behavioral context beyond that: it reports the router, reachability, PoolManager, fees (1.00% total), and the concept that a v4 pool has no address. It also warns about potential confusion in interpreting spot price and graduation state, which is extra transparency. However, it doesn't mention any rate limits or failure modes, but no annotations contradict.

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?

The description is fairly long but justified given the complexity of the tool's output. It front-loads the purpose and key information, then provides necessary warnings at the end. Each paragraph adds value: overview, details on trading venue, quote token, and parameter usage. The warning about spot price is crucial and placed appropriately. It could be slightly tighter, but every sentence earns its place.

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?

Given the complexity (bonding curve, migration states, Uniswap v4 specifics, trade fees) and that there is no output schema, the description is remarkably thorough. It covers key outputs (metadata, price, graduation status, trading venue), explains how to interpret them (spot vs fill price, graduated vs migrated), and provides necessary domain knowledge (quote token, fee structure). An agent has enough to call this tool correctly and interpret results properly.

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%, with descriptions for both parameters: 'address' says token or curve address, and 'holder' explains it adds balance and refund info. The description adds significant meaning beyond the schema: it explains that the token address or curve address both work, and elaborates on the 'holder' parameter's purpose in detail (including failed payout refunds). It also clarifies the quote token context, which directly relates to parameter usage. Baseline is 3, and the description clearly adds more, so 4.

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 states a clear, specific purpose: inspect a token and its trading venue, covering metadata, bonding curve state, price, graduation status, and where it trades. It explicitly distinguishes from siblings like arcnow_quote_buy by noting the spot price is not the fill price and pointing to that tool for actual trade quotes. The opening line 'Everything about one arcnow.io token' immediately signals scope and differentiates from list-type tools.

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?

The description explicitly explains when to use this tool versus alternatives: use arcnow_quote_buy for trade fill prices, and clarifies the distinction between 'graduated' and 'migrated' states, warning about misreading these. It also specifies that either token address or curve address can be passed, and the optional 'holder' parameter for balance queries. This provides clear decision guidance for an agent.

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

Deploy Server

Other Tools