This server enables AI agents to interact with the AKKA Finance DEX aggregator for token swaps, price quotes, and transaction building across multiple EVM blockchains. It generates unsigned transaction data only — it does not hold private keys or execute transactions directly.
Get swap quotes (akka_get_quote): Fetch the best swap quote across 25+ DEXes for a token pair, including expected output amounts and gas estimates.
Build swap transactions (akka_get_swap): Generate a complete unsigned swap transaction with routing data, gas estimates, and slippage tolerance settings.
Compare DEX prices (akka_dex_compare): Compare AKKA's aggregated route against the top 3 individual DEX pool quotes.
Get router/spender address (akka_get_spender): Retrieve the AKKA Router contract address that requires ERC-20 approval before swapping.
Build approve transactions (akka_get_approve_tx): Generate an unsigned ERC-20 approval transaction for the AKKA Router, with optional unlimited approval.
Check token allowance (akka_check_allowance): Query how many tokens the AKKA Router is authorized to spend from a given wallet.
List tradeable tokens (akka_list_tokens): Browse available tokens on a chain, including symbols, addresses, decimals, USD prices, and verification status (with pagination and filtering).
Get token details (akka_get_token): Look up detailed information for a specific token by its contract address.
List supported chains (akka_list_chains): Discover all supported networks — HyperEVM (999), Ethereum (1), Base (8453), Arbitrum (42161), and BNB Chain (56) — along with their chain IDs and native token symbols.
MCP server for the AKKA Finance DEX aggregator — swap quotes, routes, and execution across EVM chains.
An AKKA API key is required. Get one at docs.akka.finance/authentication.
Related MCP server: web3agent
Add to claude_desktop_config.json:
{
"mcpServers": {
"akka-dex": {
"command": "npx",
"args": ["-y", "@akka-finance/mcp-server"],
"env": {
"AKKA_API_KEY": "your-api-key"
}
}
}
}claude mcp add akka-dex -e AKKA_API_KEY=your-api-key -- npx -y @akka-finance/mcp-serverAdd to .cursor/mcp.json:
{
"mcpServers": {
"akka-dex": {
"command": "npx",
"args": ["-y", "@akka-finance/mcp-server"],
"env": {
"AKKA_API_KEY": "your-api-key"
}
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"akka-dex": {
"command": "npx",
"args": ["-y", "@akka-finance/mcp-server"],
"env": {
"AKKA_API_KEY": "your-api-key"
}
}
}
}Tool | Description |
| Get the best swap quote across 25+ DEXes |
| Build an unsigned swap transaction |
| Compare quotes across individual DEX pools |
| Get the router contract address for token approval |
| Build an ERC-20 approve transaction |
| Check current token spending allowance |
| List tradeable tokens on a chain |
| Get token details by address |
| List all supported chains |
Chain ID | Network | Native Token |
999 | HyperEVM (Hyperliquid) | HYPE |
1 | Ethereum | ETH |
8453 | Base | ETH |
42161 | Arbitrum | ETH |
56 | BNB Chain | BNB |
Configuration via environment variables or CLI arguments:
Env Variable | CLI Arg | Default | Description |
|
|
| AKKA API base URL |
|
| required | API key for AKKA Finance API |
|
|
| Transport: |
|
|
| Port for HTTP transport |
|
|
| Request timeout in ms |
For remote/web-based agents:
npx @akka-finance/mcp-server --transport=http --port=3100Exposes a Streamable HTTP endpoint at http://localhost:3100/mcp.
A Base MCP skill plugin for token swaps on Base is included at skills/akka-swap.md. Drop it into your Base MCP skills directory to enable AKKA-powered swaps through Base's smart wallet flow.
git clone https://github.com/Akka-Finance/akka-mcp-server.git
cd akka-mcp-server
npm install
npm run dev # Run with tsx (hot reload)
npm run build # Compile TypeScript
npm start # Run compiled outputnpx @modelcontextprotocol/inspector node dist/index.jsThis MCP server is a thin client that calls the AKKA Finance REST API. It does not hold private keys or execute transactions. All swap/approve tools return unsigned transaction data that the user must sign and broadcast separately.
AI Agent (Claude, Cursor, etc.)
↕ MCP Protocol (stdio or HTTP)
AKKA MCP Server (this package)
↕ HTTP REST
AKKA Finance API
↕ On-chain
25+ DEXes across 7 EVM chainsMIT
Check how many tokens the AKKA Router is currently allowed to spend from a wallet. Use this to determine if an approval transaction is needed before swapping. Returns "0" if no approval has been granted. Native token swaps (src = 0xeee...eee) never need approval.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID | |
| tokenAddress | Yes | ERC-20 token address to check | |
| walletAddress | Yes | Wallet address to check allowance for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by stating the return value '0' for no approval and the native token exception, which are 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?
The description is three sentences with no fluff. First sentence states purpose, second gives usage, third provides a special case. Perfectly 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?
For a simple read-only check tool, the description covers the return value, a special case (native token), and the usage context. No output schema needed; the description is 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 the baseline is 3. The description does not add additional meaning to the parameters beyond what the schema provides; the mention of 'src' is not a parameter of this tool.
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 verb 'Check', the resource 'allowance', and the context 'AKKA Router'. It distinguishes from sibling tools by mentioning 'before swapping' and the native token exception.
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 'Use this to determine if an approval transaction is needed before swapping.' Also provides a clear when-not case: 'Native token swaps never need approval.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare swap quotes across individual DEX pools for a token pair. Returns AKKA's aggregated quote alongside the top 3 individual pool quotes, showing how the aggregated route outperforms single-pool swaps. Useful for explaining the routing advantage to users.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID | |
| src | Yes | Source token address | |
| dst | Yes | Destination token address | |
| amount | Yes | Amount in wei |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds that the tool returns top 3 pool quotes and how aggregated route outperforms, providing extra behavioral context 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?
The description is two sentences, front-loaded with the action, and contains no unnecessary words. Every sentence adds value.
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 annotations cover safety and idempotency, and the schema covers parameters, the description is sufficient. It states what is returned, though no output schema exists. Could mention the number of quotes more explicitly, but overall 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%, with each parameter described in the schema. The description mentions token pair and amount but adds no new semantic meaning beyond the schema's existing descriptions.
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 compares swap quotes across individual DEX pools for a token pair, returning AKKA's aggregated quote and top 3 pool quotes. This distinguishes it from siblings like akka_get_quote, which likely provides a single quote.
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 it's useful for explaining the routing advantage, giving clear use context. However, it doesn't explicitly state when not to use it or list alternatives, though the sibling list provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an ERC-20 approve transaction for the AKKA Router. Returns unsigned transaction data (to, data, value) to be signed and sent. Required before swapping ERC-20 tokens (not needed for native tokens). If amount is omitted, grants unlimited approval.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID | |
| tokenAddress | Yes | ERC-20 token address to approve | |
| amount | No | Approval amount in wei (omit for unlimited) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable beyond that: it returns unsigned transaction data to be signed and sent, and specifies the output fields (to, data, value). No contradictions 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?
Three concise sentences with zero waste. First sentence states purpose, second describes output, third provides usage context. Every sentence adds essential information.
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?
Despite no output schema, the description fully explains the return format (to, data, value). It covers when to use, parameter nuances, and the follow-up action (sign and send). Complete for a tool of this complexity.
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 descriptions for all three parameters. The description adds incremental value by clarifying that omitting the amount grants unlimited approval, reinforcing the schema's note. It also connects tokenAddress to ERC-20 context.
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 generates an ERC-20 approve transaction for the AKKA Router, distinguishing it from sibling tools like akka_check_allowance (which checks allowance) and akka_get_swap (which performs swap). It specifies the resource (approve transaction) and the verb (generate), with additional details about output format.
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 ('Required before swapping ERC-20 tokens') and when not ('not needed for native tokens'). It also explains optional behavior for amount omission. However, it does not explicitly list alternative tools (e.g., akka_check_allowance) for cases where only checking allowance is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the best swap quote from AKKA DEX aggregator. Returns the expected output amount for swapping tokens on supported EVM chains. Use this to check prices before executing a swap. Amounts are in wei (the token's smallest unit). Use akka_list_chains to find valid chain IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID (999=HyperEVM, 1=Ethereum, 8453=Base, 42161=Arbitrum, 56=BNB Chain) | |
| src | Yes | Source token address (use 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee for native token) | |
| dst | Yes | Destination token address | |
| amount | Yes | Amount in wei (smallest unit of the source token) | |
| includeTokensInfo | No | Include token symbol/name/decimals in response | |
| includeGas | No | Include estimated gas cost |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds that amounts are in wei, which is consistent and helpful but not beyond what schema provides. No contradiction.
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 concise sentences: purpose, usage, unit detail. Front-loaded and no unnecessary 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?
No output schema, so description could describe response structure more fully. Only mentions 'expected output amount'. Adequate but leaves agent guessing about other fields.
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 schema already documents parameters. Description mentions 'wei' units but repeats schema info. No additional semantic value.
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?
Clearly states it gets the best swap quote from AKKA DEX aggregator. Distinguishes from siblings like akka_get_swap (executes) and akka_dex_compare (compares).
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 use this to check prices before executing a swap, and directs to akka_list_chains for valid chain IDs. Does not explicitly state when not to use, but implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the AKKA Router contract address that needs token approval before swapping ERC-20 tokens. Users must approve this address to spend their tokens. Not needed for native token swaps.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent behavior. Description adds context about token approval purpose but doesn't reveal additional behavioral traits beyond what annotations convey.
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 concise sentences with no wasted words. Core purpose and exception are front-loaded and 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 tool with one parameter, the description adequately explains what it does and when not to use it. Could explicitly mention the return value (contract address) but it's implied.
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 already describes chainId with 100% coverage. Description adds no extra meaning for the parameter, so baseline score of 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?
Description clearly states it retrieves the AKKA Router contract address for token approval, distinguishing it from siblings like akka_get_approve_tx and akka_check_allowance by explicitly mentioning the approval context.
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?
Includes 'Not needed for native token swaps,' providing a when-not-to-use condition. However, lacks explicit comparison to sibling tools like akka_check_allowance or akka_get_approve_tx.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a ready-to-sign swap transaction via AKKA DEX aggregator. Returns complete unsigned transaction data (to, data, value, gas) that the user must sign and broadcast. IMPORTANT: This does NOT execute the swap — it only builds the transaction. Use akka_get_quote first to check the expected output amount.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID (999=HyperEVM, 1=Ethereum, 8453=Base, 42161=Arbitrum, 56=BNB Chain) | |
| src | Yes | Source token address (0xeee...eee for native token) | |
| dst | Yes | Destination token address | |
| amount | Yes | Amount in wei | |
| from | Yes | Wallet address that will execute the swap | |
| slippage | No | Slippage tolerance as percentage (0-50, default 1) | |
| includeTokensInfo | No | Include token info in response | |
| includeGas | No | Include gas estimate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent; the description adds that it returns unsigned transaction data and requires user signing/broadcasting, which is valuable 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?
Two sentences and a crucial warning, front-loaded with purpose. Every sentence earns its place with 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 8 parameters and no output schema, the description gives an overview but lacks details on response format beyond basic fields, error conditions, or prerequisites other than get_quote.
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 detailed descriptions for each parameter. The description does not add new semantics beyond what the schema already provides.
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 generates a ready-to-sign swap transaction via AKKA DEX aggregator, specifying the output includes to, data, value, gas. It also distinguishes from sibling tool akka_get_quote by instructing to use that first.
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 akka_get_quote first and warns that this tool does not execute the swap, providing clear context for when to use. Could be stronger with explicit 'don't use if' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific token by its contract address, including symbol, name, decimals, logo, verification status, and USD price.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID | |
| address | Yes | Token contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the returned fields (symbol, name, decimals, logo, verification status, USD price). It does not cover error behavior or rate limits, but overall it provides useful behavioral context 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?
The description is a single sentence that front-loads the main action and includes a list of returned fields. No unnecessary words; it is concise and structured effectively.
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 has two required parameters, no output schema, but robust annotations, the description adequately explains the tool's purpose and the data it returns. It could be improved by mentioning the response structure or error handling, but for its simplicity it is quite 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 the schema already documents both parameters. The description mentions 'contract address' for the address param but does not add meaning for chainId beyond the schema description. Baseline score of 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 clearly states the tool retrieves detailed information about a specific token using its contract address, listing specific fields (symbol, name, decimals, logo, verification status, USD price). It is distinct from sibling tools like akka_list_tokens which list tokens, and others.
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 when to use (when you have a contract address and need details), but does not explicitly state when not to use or how it differs from alternatives like akka_list_tokens or akka_dex_compare. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all blockchain networks supported by AKKA DEX aggregator, including chain IDs, network names, and native token symbols. Use this when a user asks about supported chains or needs to find the right chain ID.
| Name | Required | Description | Default |
|---|---|---|---|
| _ | No | No parameters needed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context about the content of the output (chain IDs, names, symbols) without contradicting annotations. It does not discuss pagination or rate limits, but for a likely static list, this is acceptable.
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 concise sentences front-loaded with the action and result. Every word serves a purpose; no redundancy or fluff.
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 output schema, zero required parameters, and clear annotations), the description fully explains what it returns and when to use it. No gaps remain.
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 100% description coverage with a single dummy parameter '_' described as 'No parameters needed'. The description does not add further parameter semantics beyond what the schema already states. Baseline score of 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 uses a specific verb 'List' and clearly identifies the resource: 'all blockchain networks supported by AKKA DEX aggregator'. It also specifies the output includes chain IDs, network names, and native token symbols. This distinguishes it from sibling tools like akka_list_tokens which lists tokens.
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 states 'Use this when a user asks about supported chains or needs to find the right chain ID.' This provides clear context for when to invoke the tool. It does not mention when not to use it or alternatives, but for a simple list tool, this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available tokens for swapping on a given chain. Returns token symbols, names, addresses, decimals, USD prices, and verification status. Use this to discover tradeable tokens or look up a token's contract address by symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| chainId | Yes | Chain ID | |
| page | No | Page number (0-based) | |
| limit | No | Tokens per page (default 50, max 1000) | |
| verified | No | Filter to verified tokens only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds details about the return data (prices, verification status) and implies pagination via parameters, but does not contradict annotations or introduce unexpected behavior.
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 two sentences long, front-loading the purpose and return information, with no redundant or extraneous content.
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 rich schema and annotations, the description covers the essential context: what the tool does, what it returns, and its use cases. Pagination is implied by schema parameters but not needed explicitly in the description.
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 parameters are already well-documented. The description adds little extra meaning beyond stating 'given chain' for chainId and mentioning contract addresses in the return, not directly 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?
The description clearly states the tool lists tokens for swapping on a given chain, and details the returned fields (symbols, names, addresses, etc.). It differentiates from siblings by specifying discovery and look-up use cases.
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 mentions two use cases: discovering tradeable tokens and looking up contract addresses. However, it does not contrast with alternative tools like akka_get_token, which might be more appropriate for single-token lookup.
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. Dates show when Glama detected each change.
v1.0.1akka_check_allowanceakka_dex_compareakka_get_approve_txakka_get_quoteakka_get_spenderakka_get_swapakka_get_tokenakka_list_chainsakka_list_tokensScored across 9 tools
Each tool targets a distinct operation: checking allowances, comparing DEX pools, generating approvals, getting quotes, retrieving spender address, building swap transactions, and querying tokens/chains. There is no overlap in functionality.
All tool names follow the consistent pattern 'akka_<verb>_<noun>' with verbs like check, compare, get, list, and descriptive nouns. No naming style variations.
With 9 tools, the server covers essential operations for a DEX aggregator: listing chains/tokens, querying quotes, handling approvals, and building swap transactions. The count is balanced and not excessive.
The tool set covers the full workflow from discovering supported chains and tokens, checking allowances, obtaining quotes, generating approval transactions, to building swap transactions. The only missing piece (broadcasting) is intentionally left to the user.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Delora MCP server for cross-chain quotes, supported chains, tokens, and tools.
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Multi-aggregator swap router for AI agents on Base. 10 bps fee. MCP-native, non-custodial.
MCP server for Fuse Network: balances, tokens, staking, DeFi data, swaps and on-chain transactions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Akka-Finance/akka-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
