paladin-swap
Server Details
Multi-aggregator swap router for AI agents on Base. 10 bps fee. MCP-native, non-custodial.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- paladinfi/paladin-swap-mcp
- GitHub Stars
- 0
- Server Listing
- paladin-swap-mcp
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 3 of 3 tools scored.
swap_health and swap_quote are clearly distinct, but trust_check_preview could be confused with a real trust check tool. Since it only returns sample data and the actual trust check endpoint is not exposed as a tool, an agent might mistakenly use it for real decisions.
swap_health and swap_quote follow a consistent 'swap_' prefix, but trust_check_preview uses a different 'trust_check_' prefix. This breaks the pattern and could cause confusion.
With only 3 tools, the server feels very thin for a swap router. Core functionality like executing a swap or listing supported tokens is missing. The count is too low for the apparent domain.
The tool surface lacks essential operations for a swap service: no swap execution, no token list, no price feed. The trust_check_preview is a sample and not a real tool. Significant gaps exist.
Available Tools
3 toolsswap_healthSwap Service HealthARead-onlyInspect
Return the swap router's health + configuration (fee recipient, bps, supported chains).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds specific behavioral context by listing the configuration details returned (fee recipient, bps, supported chains), enhancing transparency beyond the annotations.
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?
Single sentence, front-loaded with the action and details. Every word adds value; no wasted text.
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?
Given the tool's simplicity (no params, safe read-only operation, output schema exists), the description sufficiently covers what the tool does and returns. No missing information for correct invocation.
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 tool has zero parameters, so baseline is 4 as per scoring rules. The description adds no parameter info, which is appropriate since none exist.
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 returns the swap router's health and configuration, specifying key fields (fee recipient, bps, supported chains). This distinguishes it from sibling tools 'swap_quote' (for quotes) and 'trust_check_preview' (for previews).
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 implicitly conveys usage: check service health and config. Not explicit about when to avoid using, but the context is clear due to the tool's simple no-parameter design and distinct purpose from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
swap_quoteGet Swap QuoteARead-onlyInspect
Get a competitive multi-aggregator swap quote with ready-to-execute calldata. PaladinFi does not represent any returned route as the best available across the broader DeFi market.
| Name | Required | Description | Default |
|---|---|---|---|
| taker | Yes | Wallet address that will execute the swap (the agent's wallet) | |
| chainId | No | EVM chain ID (default 8453 = Base). Currently only Base is supported. | |
| buyToken | Yes | ERC20 contract address to buy (e.g. WETH on Base = 0x4200000000000000000000000000000000000006) | |
| sellToken | Yes | ERC20 contract address to sell (e.g. USDC on Base = 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) | |
| sellAmount | Yes | Amount to sell in smallest unit (decimal string; e.g. "1000000000" = 1000 USDC) | |
| slippageBps | No | Optional slippage tolerance in basis points (default from provider) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so description adds value with the caveat: 'PaladinFi does not represent any returned route as the best available across the broader DeFi market.' This warns about quote quality and limitations, which is useful behavior beyond annotations.
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 sentences: first states purpose with specific verbs and resources, second adds a crucial caveat. No wasted words, front-loaded. Highly efficient.
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?
Given 6 parameters, annotations, and output schema (not shown but present), description effectively explains tool purpose and adds important caveat. It does not detail return values or execution steps, but output schema covers that. Slight gap: no guidance on when to use vs other quoting approaches, but not critical.
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 100% (all 6 parameters described). The description adds no additional parameter-specific information, but the baseline of 3 is appropriate as schema already documents parameters well. The overall disclaimer does not directly enhance parameter semantics.
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?
Description clearly states 'Get a competitive multi-aggregator swap quote with ready-to-execute calldata,' identifying verb (get), specific resource (swap quote), and unique context (multi-aggregator, calldata). Distinguishes from siblings swap_health and trust_check_preview, which are unrelated.
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?
Usage is implied (get a quote before executing a swap) but not explicit. No mention of when not to use or alternatives. With siblings not directly competing, the lack of explicit guidance is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trust_check_previewToken Trust Check (Preview)ARead-onlyIdempotentInspect
Get a SAMPLE-FIXTURE preview of the PaladinFi token-contract trust check.
⚠️ NOT a real evaluation. Returns fixed sample data with _preview: true,
every factor marked real: false, and recommendation prefixed sample-
(sample-allow / sample-warn / sample-block). Use this for shape-testing
your integration; DO NOT use the verdict to gate real swaps, signing, or any
production agent decision.
Programmatic safety check: before consuming any field of this response,
agents should test resp.get("_real") is True (top-level) — preview always
returns _real: false. Substring-matching on recommendation (e.g.
"allow" in resp["trust"]["recommendation"]) will INCORRECTLY match
sample-allow; use exact-equality (resp["trust"]["recommendation"] == "allow")
or test the _real field instead.
For REAL evaluations (3 paths, cheapest -> most-featured):
Free wallet-OFAC screen (v0.11.77+):
POST https://swap.paladinfi.com/v1/trust-check/ofacanonymous, rate-limited (1 r/s + burst 3), runs only the OFAC SDN wallet-screen leg with real data (
_real: true). Returns the samerecommendation: "allow" | "block"shape as the full endpoint (nowarnstate — OFAC is binary). Useful for agents that just need sanctions screening without the full composition. Includes_paid_endpoint_infoupgrade hint pointing at the paid endpoint. Wallet-OFAC scope — the Treasury SDN list carries wallet/EOA addresses, not token contracts. Use the paid endpoint for token-contract risk.
Install
@paladinfi/eliza-plugin-trust(ElizaOS) or@paladinfi/agentkit-actions(Coinbase AgentKit). Both handle x402 payment ($0.001 USDC per call on Base) automatically and expose apaladin_trust_checkaction to your agent.OR call
POST https://swap.paladinfi.com/v1/trust-checkvia an x402-capable HTTP client. See https://paladinfi.com/trust-check/ for full integration docs.
The paid endpoint composes live OFAC SDN screening (refreshed daily from the
Treasury XML feed), GoPlus token security, Etherscan source verification, and
PaladinFi anomaly + lookalike heuristics into a single
recommendation: "allow" | "warn" | "block" verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ERC20 contract address to evaluate (Base 8453 only currently; must match `^0x[a-fA-F0-9]{40}$`) | |
| chainId | No | EVM chain ID (default 8453 = Base; only chain supported) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, etc. Description adds behavioral details: returns sample data with _preview: true, _real: false, recommendation prefixed sample-, and warns about substring-matching pitfalls. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, bullet points, and warnings. Slightly lengthy but justified due to safety concerns. Front-loaded with key purpose.
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?
Given complexity, full schema coverage, annotations, and output schema, the description provides comprehensive guidance on usage, alternatives, and safety considerations, including edge cases like substring matching.
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 coverage is 100%, so baseline 3. Description does not add new info beyond schema descriptions, which already include format and constraints for both parameters.
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 it provides a sample-fixture preview of the PaladinFi token-contract trust check, emphasizing it is not a real evaluation. It distinguishes from siblings (swap_health, swap_quote) by focusing on trust check preview.
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?
Explicitly says to use for shape-testing integration, not for real decisions. Provides programmatic safety checks and lists three alternative paths for real evaluations with detailed explanations of each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.