Solana Wallet Intel

swap_build

Read-onlyIdempotent

Call this when your agent wants to buy or swap a Solana token. One call runs the full pretrade check on outputMint (token risk, holder concentration, stablecoin and xStock lookalikes), then builds the best Jupiter route with a price-impact estimate (and a split-fill chunk plan when impact is over 1%) as an UNSIGNED versioned transaction with your taker wallet as fee payer. Non-custodial: we never hold keys or funds; you sign and send it yourself. If pretrade says avoid, no transaction is built unless allowRisky=1. A 0.5% (50 bps) integrator fee via the Jupiter Referral Program is taken from the swap and already reflected in the quoted out_amount; it is always disclosed in platform_fee (null when off). amount is in the input token's smallest unit. Invalid input returns HTTP 400 and unknown mints 404, before payment. If Jupiter has no route or is down, or every pretrade factor fails, the call returns HTTP 502 and you are not charged. Not financial advice. Costs $0.025 USDC (25000 base units) via x402. The same price is charged for HTTP GET /swap/build. An unpaid HTTP call returns 402 even when the query is missing or invalid. A signed call with invalid arguments is rejected before settlement and is not charged. A successful result can set cached, stale, and cacheAgeMs. stale true means a previous result was served while a refresh runs or the upstream failed. You are charged only when the tool result is not an error.

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": {
      "inputMint": "<inputMint>",
      "outputMint": "<outputMint>",
      "amount": "<amount>",
      "taker": "<taker>"
    },
    "name": "swap_build"
  }
}

Input Schema

Name	Required	Description	Default
`taker`	Yes
`amount`	Yes
`symbol`	No
`inputMint`	Yes
`allowRisky`	No
`outputMint`	Yes
`slippageBps`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond annotations, the description discloses non-custodial behavior, unsigned transaction construction, integrator fees, error-status billing rules, cache/stale behavior, and payment details. These are substantial behavioral traits not captured by readOnlyHint/openWorldHint/idempotentHint/destructiveHint.

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 front-loaded with the core workflow and remains information-dense, but it is long and includes repeated billing/error details that could be tightened. The length is mostly justified by the tool's financial transaction complexity and the lack of schema descriptions.

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?

There is no output schema, but the description still explains key return details like out_amount, platform_fee, cached, stale, and cacheAgeMs, plus important HTTP error behavior. It is not fully complete because symbol and slippageBps semantics are absent despite 0% schema coverage.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains amount units, taker as fee payer, outputMint for pretrade checks, and allowRisky behavior, but leaves symbol and slippageBps unexplained and only implies inputMint's role.

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 action: buy or swap a Solana token by running pretrade checks and building a Jupiter route as an unsigned transaction. It clearly distinguishes this composite workflow from simpler sibling checks like pretrade or token_check_demo.

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 explicitly says to call this when the agent wants to buy or swap a Solana token, which gives clear usage context. It does not explicitly say when not to use it or name alternatives such as pretrade for risk-only checks, so it stops short of full routing guidance.

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

All Solana Wallet Intel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?