Skip to main content
Glama
arcnow-io

@arcnow/mcp

Official
by arcnow-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Quote a buy

arcnow_quote_buy
Read-onlyIdempotent

Quote what a token buy would return right now, with fee breakdown, average fill price, and minimum-out at chosen slippage. Use it before any purchase to see the real cost instead of the spot price.

Instructions

What a given amount of the token's quote would buy right now, wherever the token trades: tokens out, every fee and who receives it — on a curve the flat 1% split four ways between creator, platform, referrer and protocol — the average price the order would fill at, and the minimum-out floor at several slippage tolerances.

Costs nothing and signs nothing. Use it before every buy, and use it INSTEAD of a spot price whenever someone asks what an amount would get them — an order moves the price across its own size, so the spot price is only ever its first infinitesimal slice.

ON A BONDING CURVE: if the buy would fill the curve, this says so, reports the refund, and explains the gas-limit trap that decides whether the token's market is created in that same transaction or never. Read that part before quoting a graduating buy to anyone.

IN A UNISWAP V4 POOL (the token graduated and migrated): the quote says it is a pool quote, priced by simulating the real swap through arcnow.io's router. It shows the two charges apart — arcnow.io's fee hook's 0.80% and the pool's own 0.20% LP fee, 1.00% in all, both read off the pool — the average fill price against the pool's spot price, and the price impact. referrer does not exist on a pool swap and is refused.

A token that graduated but never migrated trades nowhere; this says so and names arcnow_migrate. A quote is a snapshot of one block. Anyone else's trade changes it.

THE AMOUNT IS IN THE TOKEN'S QUOTE: native USDC, or the ERC-20 (such as EURC) it was launched in — arcnow_token names it. Every figure in the answer is labelled with that quote's symbol. An ERC-20 quote is pulled with an exact approval, which the answer says.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesThe curve address, or the token address. Either works.
quoteInYesHow much of the token's quote to spend, in whole units as a person writes it — "25", "1.5" — in the quote the token is priced in: native USDC (18 decimals) or an ERC-20 such as EURC (6). It is read exactly in that quote's decimals; more decimal places than the quote has is refused, never rounded. A string, because a JSON number cannot hold 18 decimals.
referrerNoCURVE ONLY: the address credited with the referral share of the fee. With no referrer that share goes to the platform instead. Refused for a token in its pool, whose swap has no referrer. (There is no developer share and no developer argument: the fee has four parties — creator, platform, referrer, protocol.)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.0
    • removedInput schema / properties / developer
      Removed value: -{
-  "description": "CURVE ONLY: the address credited with the developer share of the fee. With none, it goes to the platform. Refused for a token in its pool.",
-  "pattern": "^0x[0-9a-fA-F]{40}$",
-  "type": "string"
-}
    • changedInput schema / properties / referrer / description
      Previous value: -"CURVE ONLY: the address credited with the referral share of the fee. With no referrer that share goes to the platform instead. Refused for a token in its pool, whose swap has no referrer."New value: +"CURVE ONLY: the address credited with the referral share of the fee. With no referrer that share goes to the platform instead. Refused for a token in its pool, whose swap has no referrer. (There is no developer share and no developer argument: the fee has four parties — creator, platform, referrer, protocol.)"
  2. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, and the description adds meaningful behavior beyond those: 'Costs nothing and signs nothing,' the quote is a one-block snapshot, anyone else's trade changes it, ERC-20 quotes use an exact approval, and the curve fill/gas-limit trap is disclosed. No contradiction with annotations.

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 long but deliberately structured with labeled sections for curve, pool, and no-market cases, and the core purpose is front-loaded. There is little filler, though some details are re-emphasized across sections. The length is justified by the tool's multi-context behavior.

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 an agent what the answer contains: tokens out, fees and recipients, average fill price, minimum-out floors, slippage, refunds, pool-quote indicators, price impact, and no-market messaging. It also covers edge cases like graduating buys and ERC-20 exact approvals, making it complete for invoking the tool.

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%, and the schema already documents address, quoteIn, and referrer well. The description adds useful extra semantics: the amount is denominated in the token's quote currency, figures are labelled with that symbol, ERC-20 quotes are pulled with an exact approval, and referrer is refused on pool swaps. This exceeds the baseline but is somewhat redundant with the schema.

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 specific verb and resource: 'What a given amount of the token's quote would buy right now' and explicitly contrasts itself with a spot price. It also enumerates the returned information (tokens out, fees, recipients, average fill price, minimum-out floor), making it clearly distinguishable from siblings like quote_sell or quote_tokens.

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 gives direct guidance: 'Use it before every buy, and use it INSTEAD of a spot price whenever someone asks what an amount would get them.' It also differentiates when the token is on a bonding curve, in a Uniswap v4 pool, or nowhere tradable, and specifies when referrer is refused.

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