Safe Solana swaps for AI agents with risk checks, unsigned transactions, x402, and 3-bp fees.
Describe Preflight SafeSwap capabilities, pricing, discovery endpoints, and integration details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. The verb 'Describe' signals a read-only, informational operation, which is a useful trait, but the description does not explicitly state that it has no side effects, what form the response takes, or whether any integration/auth context is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that enumerates the covered topics without filler or repetition. Every part contributes to making the tool's scope clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter informational tool with no output schema, the description adequately covers the content an agent needs to know before invoking it. A small gap is the absence of any indication of the response structure or relationship to preflight_safe_swap, but nothing about actually calling the tool is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter detail for the description to add. A baseline of 4 is appropriate because the tool cannot have parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with the verb 'Describe' and names the specific resource: Preflight SafeSwap capabilities, pricing, discovery endpoints, and integration details. It is distinguishable from the sibling preflight_safe_swap as an informational tool, though it does not explicitly contrast itself with that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the agent should call this when it needs to learn about Preflight SafeSwap's capabilities, pricing, endpoints, or integration details. However, it provides no explicit when-to-use versus the sibling tool preflight_safe_swap, and no when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover and prepare a risk-checked Solana swap through Preflight SafeSwap. Use this when an autonomous agent needs a USDC-paired Solana swap with explicit route, risk, slippage and fee disclosure. The paid HTTP endpoint costs $0.005 USDC and embeds a disclosed 3 bp execution fee.
| Name | Required | Description | Default |
|---|---|---|---|
| taker | Yes | Solana signer wallet | |
| token_in | Yes | Solana input token mint | |
| amount_in | Yes | Amount in input-token base units | |
| token_out | Yes | Solana output token mint | |
| slippage_bps | No | ||
| referrer_usdc_account | No | Optional existing USDC token account that receives 1 bp of the 3 bp fee |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the paid endpoint cost ($0.005 USDC) and the embedded 3 bp execution fee, which is valuable. However, it doesn't explicitly state whether the tool executes the swap on-chain or only prepares it, nor does it mention auth, rate limits, or side effects beyond the fee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences carry the essential information: what the tool does, when to use it, and what it costs. There is no filler or repetition, and the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description names the key output qualities (route, risk, slippage, fee disclosure) and the cost, which helps an agent decide to invoke it. However, with no output schema and no annotations, it leaves ambiguity about what 'prepare' returns, whether the swap is actually executed, and what prerequisites or follow-up steps the agent must handle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so most parameters are already documented. The description adds the useful constraint that the swap is USDC-paired, but it does not explicitly map that to token_in/token_out. It adds little per-parameter meaning beyond what the schema already provides, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Discover and prepare') with a concrete resource ('risk-checked Solana swap'), and adds distinguishing qualifiers: USDC-paired, explicit route, risk, slippage, and fee disclosure. It clearly separates this tool from the sibling preflight_capabilities by focusing on swap preparation rather than capability introspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: when an autonomous agent needs a USDC-paired Solana swap with route, risk, slippage, and fee disclosure. It provides clear use context but does not explicitly mention when not to use it or name the sibling as an alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Non-custodial, rug-gated crypto swaps + token safety + discovery for AI agents.
Token swaps and honeypot/rug checks for AI agents on 8 chains, paid per-call in USDC via x402.
Non-custodial DeFi tools for AI agents on Solana: swaps, perps, lending, staking, equities.
Solana token safety for AI agents — rug-pull, honeypot & Token-2022 trap detection before you buy.
Add one secure layer between your agents and this server.
The two tools have clearly distinct purposes: one explains capabilities and integration details, the other performs the actual swap discovery/preparation. No overlap or chance of misselection.
Both tools follow a consistent preflight_ prefix with a verb-like noun ('capabilities', 'safe_swap'). The naming pattern is uniform and predictable.
With only two tools, the server feels minimal but appropriate for a narrow, focused integration. It is borderline thin, though the two tools cover the essential info and action needs for this specific service.
The safe_swap tool covers the core workflow (discovery, risk check, route/slippage/fee disclosure), and capabilities covers server metadata. Minor gaps exist such as no separate quote-only or status tool, but the primary purpose is well served.