Provides tools for interacting with the PactFi AMM DEX on the Algorand blockchain, enabling pool discovery, quote computation, and building unsigned swap/liquidity transactions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PactFi MCP swap 100 ALGO for USDC"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for the PactFi AMM DEX on Algorand. Part of the UluOS agent ecosystem.
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ PactFi MCP │────▶│ UluWalletMCP │────▶│ UluBroadcastMCP │
│ (this repo) │ │ (signing) │ │ (submit to net) │
└──────┬───────┘ └──────────────┘ └──────────────────┘
│
├── PactFi REST API (api.pact.fi) ── pool discovery & metadata
└── Algorand algod (algonode.cloud) ── on-chain state & tx paramsNo PactFi SDK dependency — pools are queried via the PactFi REST API, quotes are computed locally using constant-product AMM math, and transactions are built directly with algosdk.
Related MCP server: Tapp Exchange MCP Server
Tool | Description |
| List PactFi pools with optional filters (symbol, verified, pool type) |
| Get detailed pool info by app ID (on-chain reserves + API metadata) |
| Compute swap quote with expected output, fee, price impact, and slippage |
| Build unsigned swap transaction group |
| Build unsigned add-liquidity transaction group |
| Build unsigned remove-liquidity transaction group |
List PactFi liquidity pools. Supports filtering by token symbol, verification status, pool type (CONST or STABLE), and result limit.
Fetch on-chain pool state (reserves A/B, LP supply, fee configuration) merged with API metadata (token names, prices, TVL, APR).
Simulate a swap without building transactions. Provide fromToken/toToken symbols and an amount. Optionally specify poolAppId to target a specific pool, or let it auto-discover the highest-TVL pool for the pair.
Build a 2-transaction atomic group:
Deposit (payment or asset transfer) to pool escrow
Application call with SWAP + minimum received
Build a 3-transaction atomic group:
Deposit primary asset to pool escrow
Deposit secondary asset to pool escrow
Application call with ADDLIQ + minimum LP tokens
Build a 2-transaction atomic group:
Deposit LP tokens to pool escrow
Application call with REMLIQ + minimum primary + minimum secondary
Agent: get_quote(fromToken="ALGO", toToken="USDC", amount="100")
→ { expectedOutput: "8.52", minimumReceived: "8.47", poolAppId: 1073557308, ... }
Agent: swap_txn(fromToken="ALGO", toToken="USDC", amount="100", sender="ABC...")
→ { transactions: ["base64...", "base64..."], details: { ... } }
Agent: UluWalletMCP.sign_transactions(signerId="my-signer", transactions=["base64..."])
→ { signedTransactions: ["base64..."] }
Agent: UluBroadcastMCP.broadcast_transactions(network="algorand-mainnet", txns=["base64..."])
→ { txIds: ["TXID..."] }npm installnode index.js{
"mcpServers": {
"pactfi-mcp": {
"command": "node",
"args": ["/absolute/path/to/pactfi-mcp/index.js"]
}
}
}PactFi REST API (api.pact.fi): pool listing, token metadata, TVL, volume, APR
Algorand algod (mainnet-api.algonode.cloud): on-chain pool state, transaction parameters
Constant Product (CONST): Standard x·y=k AMM pools — fully supported for quotes and transactions
NFT Constant Product: Same AMM math as constant product — fully supported
Stableswap (STABLE): Curve-style stable pools — get_quote returns an approximate result (with warning); swap_txn rejects stableswap pools since the constant-product math cannot produce correct minimum-received values for on-chain execution
Stableswap transactions: Building swap/liquidity transactions for stableswap pools is not supported. The on-chain contract uses the StableSwap (Curve) invariant which requires different math than constant-product. get_quote provides an approximation with a warning.
Pool discovery: The PactFi API is used for token metadata (symbols, decimals, prices). For specific pools, use the appId parameter directly.
MIT
Build unsigned transactions to add liquidity to a PactFi pool. Returns base64-encoded transaction group for signing via UluWalletMCP.
| Name | Required | Description | Default |
|---|---|---|---|
| sender | Yes | Sender wallet address | |
| slippage | No | Slippage tolerance in percent (default 0.5) | |
| poolAppId | Yes | Pool application ID | |
| primaryAmount | Yes | Amount of primary asset in human-readable units | |
| secondaryAmount | Yes | Amount of secondary asset in human-readable units |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden but does disclose two useful traits: the transaction is unsigned and the return is a base64-encoded transaction group for signing via UluWalletMCP. It omits failure modes, approval/permission requirements, and how slippage or missing pools are handled.
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 tight sentences, front-loaded with the core action and followed by the return/signing detail. No filler 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?
There is no output schema, and the description compensates by explaining the return value (base64 transaction group) and the downstream signing step. Safety and failure behavior are unstated, but for a transaction-builder tool this is largely complete.
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%, so all five parameters are already documented in the schema, including units and the slippage default. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
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 states a specific verb and resource: 'Build unsigned transactions to add liquidity to a PactFi pool.' This clearly separates it from siblings like swap_txn and remove_liquidity_txn by intent, though it never names those alternatives explicitly.
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?
There is no guidance on when to use this tool versus the sibling transaction builders (swap_txn, remove_liquidity_txn) or any prerequisites such as pool existence or required approvals. Usage is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed PactFi pool information by application ID. Returns on-chain reserves, fee configuration, LP supply, and API metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | Pool application ID on Algorand |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. 'Get' implies a read-only operation and the second sentence usefully discloses what is returned (on-chain reserves, fee configuration, LP supply, API metadata), but there is no mention of permissions, rate limits, or behavior for an unknown/invalid appId.
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 tight sentences with the action and scope front-loaded and the return contents following; no wasted words.
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?
With no output schema, the description helpfully enumerates the returned fields, which is the main compensating value. A read-only single-pool fetch needs little else, though it could note behavior on a nonexistent appId.
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% with a single documented appId parameter, so the schema already explains the input. The description only echoes 'by application ID' and adds no format or lookup nuance, making the baseline 3 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 states a specific verb and resource (Get ... PactFi pool information) scoped by application ID, and the singular 'pool' plus 'detailed' implicitly contrasts with the get_pools list tool. It stops short of explicitly naming that sibling, so it is clear but not fully differentiated.
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: fetch details for one pool when you already have its appId. There is no explicit when-to-use or when-not-to-use guidance and no mention of the get_pools alternative for listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List PactFi AMM liquidity pools on Algorand with optional filters. Returns pool metadata, TVL, volume, and APR.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 20) | |
| symbol | No | Filter pools containing this token symbol (e.g. ALGO, USDC, goBTC) | |
| pool_type | No | Filter by pool type: CONST (constant product) or STABLE (stableswap) | |
| is_verified | No | Filter for verified pools only |
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 discloses the return fields (metadata, TVL, volume, APR), which is useful, but omits pagination behavior, default ordering, rate limits, and that limit defaults to 20. Adequate but with clear gaps for a read tool.
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, front-loaded with the action and resource, then the return payload. No waste, no redundancy.
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 no-required-param list tool with a fully described schema, the description covers purpose and returns. It lacks only pagination/ordering detail, but with no output schema and a rich input schema, this is nearly complete.
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 all four parameters (limit, symbol, pool_type, is_verified) are already fully documented in the schema. The description adds only that filters are optional, which the schema mostly implies via required=0. 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?
States a specific verb (List) and resource (PactFi AMM liquidity pools on Algorand) and distinguishes this from the singular sibling get_pool. An agent can identify it as the discovery/browse tool immediately.
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 mentions optional filters, implying a search/browse use case, but does not explicitly say when to use this versus get_pool or get_quote. Usage is inferred but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a swap quote from PactFi using constant-product AMM math. Computes expected output, fee, price impact, and minimum received after slippage. Provide either a poolAppId or fromToken+toToken symbols to auto-discover the best pool.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to swap in human-readable units (e.g. '100' for 100 ALGO) | |
| toToken | Yes | Token symbol to swap to (e.g. USDC, ALGO) | |
| slippage | No | Slippage tolerance in percent (default 0.5) | |
| fromToken | Yes | Token symbol to swap from (e.g. ALGO, USDC) | |
| poolAppId | No | Pool application ID (optional if fromToken and toToken are provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the AMM math, computed fields (fee, price impact, minimum received after slippage), which is genuinely useful, but never states explicitly that this is a non-mutating read with no on-chain side effects, and says nothing about auth needs or freshness/staleness of the quote.
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?
Three tight sentences, front-loaded with purpose and outputs, then the conditional parameter guidance. No filler or restated boilerplate.
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?
With 100% schema coverage but no output schema, the description usefully enumerates the return values (expected output, fee, price impact, minimum received), compensating for the missing structured output. It stops short of noting the quote's non-mutating nature, which is the one residual gap.
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%, so the schema already documents all five parameters with examples and defaults. The description adds only the pool-discovery nuance ('auto-discover the best pool') beyond the schema's own note that poolAppId is optional, so 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?
States a specific verb+resource ('Get a swap quote from PactFi') and names the exact outputs computed, distinguishing it from the sibling transaction tools swap_txn/add_liquidity_txn which mutate state. An agent can tell this is the read-only preview step.
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?
Gives clear routing guidance for pool selection: 'Provide either a poolAppId or fromToken+toToken symbols to auto-discover the best pool.' It does not explicitly say when to prefer this over swap_txn (i.e., quote before executing), but the context is strong and the parameter choice is disambiguated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build unsigned transactions to remove liquidity from a PactFi pool. Returns base64-encoded transaction group for signing via UluWalletMCP.
| Name | Required | Description | Default |
|---|---|---|---|
| sender | Yes | Sender wallet address | |
| lpAmount | Yes | Amount of LP tokens to burn in human-readable units | |
| slippage | No | Slippage tolerance in percent (default 0.5) | |
| poolAppId | Yes | Pool application ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does disclose key traits: it builds an *unsigned* transaction group (no execution/mutation occurs) and returns base64 encoding, plus the external signing dependency. It omits failure behavior and any auth/permission requirements.
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, zero filler, with the core action front-loaded and the return/signing detail second. Nothing is repeated from the schema.
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?
No output schema exists, and the description compensates by naming the return value (base64 tx group) and the next step (signing via UluWalletMCP), which is what an agent needs to chain calls. Slippage default and units are left to the schema, which is reasonable.
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%, so all four parameters (sender, lpAmount, slippage, poolAppId) are already documented in the schema. The description adds no parameter-level meaning, which makes the baseline 3 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?
States a specific verb and resource: 'Build unsigned transactions to remove liquidity from a PactFi pool.' The 'remove liquidity' scope is inherently distinct from the sibling add_liquidity_txn and swap_txn, so an agent can route correctly without opening any schema.
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 a workflow step by noting the result is 'for signing via UluWalletMCP,' which tells the agent this is a build-only precursor, but it never states when to prefer this over siblings or what preconditions must hold (pool must exist, LP balance sufficient).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build unsigned transactions to swap tokens on PactFi. Returns base64-encoded transaction group for signing via UluWalletMCP. Finds the best pool automatically if poolAppId is not specified.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to swap in human-readable units | |
| sender | Yes | Sender wallet address | |
| toToken | Yes | Token symbol to swap to | |
| slippage | No | Slippage tolerance in percent (default 0.5) | |
| fromToken | Yes | Token symbol to swap from (e.g. ALGO, USDC) | |
| poolAppId | No | Pool application ID (optional — auto-discovered from token symbols) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key traits: the transaction is unsigned, no signing occurs here, the output is a base64-encoded transaction group, and signing is delegated to UluWalletMCP. It omits failure modes (no route found, insufficient liquidity) and whether slippage tolerance is enforced by this call.
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?
Three short sentences with zero padding, front-loaded with the action and followed by the output contract and the pool-discovery behavior.
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 six-parameter mutation-adjacent tool with no annotations and no output schema, the description covers the return shape (base64 transaction group) and the downstream signing step, which is the critical integration detail. It stops short of stating error behavior or that a quote should be obtained first.
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%, so all six parameters including slippage default and poolAppId are already documented in the schema. The description's pool auto-discovery note largely restates the schema's own poolAppId description, adding no new syntax or constraint detail, so the baseline 3 applies.
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?
States a specific verb and resource ('Build unsigned transactions to swap tokens') plus the protocol (PactFi), which cleanly separates it from add_liquidity_txn, remove_liquidity_txn, and the read-only get_quote/get_pool tools.
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 rather than stated: the description says the output is for signing via UluWalletMCP and that poolAppId is optional, but it never says when to call this versus get_quote first or what prerequisites (funded wallet, valid pool) must hold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_liquidity_txnget_poolget_poolsget_quoteremove_liquidity_txnswap_txnScored across 6 tools
Each tool has a clearly distinct purpose: get_pools vs. get_pool differentiate list vs. detail, get_quote is a read-only calculation, swap_txn builds a swap transaction, and add/remove_liquidity_txn are separate liquidity actions. Descriptions reinforce these boundaries, leaving no realistic chance of misselection.
All tools follow a consistent snake_case verb_noun convention (get_pools, get_pool, get_quote, swap_txn, add_liquidity_txn, remove_liquidity_txn). The '_txn' suffix consistently marks transaction-building tools, and the singular/plural distinction in get_pool vs. get_pools is natural.
Six tools cleanly cover the core AMM operations: pool discovery, pool detail, quoting, swapping, and adding/removing liquidity. There is no redundancy or filler; each tool earns its place.
The surface covers the essential swap and liquidity lifecycle, but there are minor gaps such as querying a user's existing LP positions or accrued fees. These are plausible additions that agents could lack, though core workflows are fully supported.
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
Cross-network DeFi API data, AMM analytics, and SDK docs for 17+ networks.
Official Aave MCP for V3 and V4 markets, positions, governance, and transaction preparation.
Agent MCP for DeFi: cross-chain LINQ fan-out, AMM quotes/swaps, bridge, AI. Solana+EVM. Free+x402.
