The MCP-BAMM server enables AI agents to interact with Borrow Automated Market Maker (BAMM) contracts on the Fraxtal blockchain for DeFi lending and borrowing operations.
Core Capabilities:
View Positions - Retrieve active BAMM positions across all pools using GET_POSITIONS
Pool Analytics - Access statistics and metrics for all BAMM pools with POOL_STATS
Lend - Deposit Fraxswap LP tokens to BAMM contracts to earn yield using LEND
Borrow - Borrow tokens against collateral from BAMM positions using BORROW
Repay - Repay borrowed tokens to BAMM positions using REPAY
Add Collateral - Increase collateral in positions with ADD_COLLATERAL to maintain healthy loan-to-value ratios
Remove Collateral - Withdraw excess collateral from positions with REMOVE_COLLATERAL
Withdraw - Redeem BAMM tokens to withdraw LP tokens using WITHDRAW
Technical Features:
Validates Ethereum addresses using regex pattern matching (0x + 40 hex characters)
Requires wallet private key for transaction signing
Built on the Model Context Protocol (MCP) for LLM integration
Used for linting and formatting the codebase, with dedicated commands for these operations during development.
Supports storing private keys and configuration in .env files for secure management of sensitive credentials.
Runs on Node.js runtime (v18 or newer recommended) for server execution.
Used as the package manager for installation, dependency management, and running the server.
Built using TypeScript to implement the MCP server functionality with type safety.
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., "@MCP-BAMM show me my active BAMM positions"
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.
The BAMM MCP Server enables AI agents to interact with Borrow Automated Market Maker (BAMM) contracts on the Fraxtal blockchain. This server provides comprehensive access to BAMM positions, lending, borrowing, and collateral management operations.
By implementing the Model Context Protocol (MCP), this server allows Large Language Models (LLMs) to manage BAMM positions, borrow against LP tokens, and perform other operations related to the BAMM protocol directly through their context window.
Related MCP server: MantraChain MCP Server
Position Management: View and manage your active BAMM positions across all pools.
Lending Operations: Lend Fraxswap LP tokens to BAMM contracts to earn yield.
Borrowing: Borrow tokens against your collateral from BAMM positions.
Collateral Management: Add or remove collateral from your BAMM positions.
Pool Analytics: Access statistics for all BAMM pools.
To use this server without installing it globally:
npx @iqai/mcp-bammgit clone https://github.com/IQAIcom/mcp-bamm.git
cd mcp-bamm
pnpm install
pnpm run buildAdd the following configuration to your MCP client settings (e.g., claude_desktop_config.json).
{
"mcpServers": {
"bamm": {
"command": "npx",
"args": ["-y", "@iqai/mcp-bamm"],
"env": {
"WALLET_PRIVATE_KEY": "your_wallet_private_key_here"
}
}
}
}{
"mcpServers": {
"bamm": {
"command": "node",
"args": ["/absolute/path/to/mcp-bamm/dist/index.js"],
"env": {
"WALLET_PRIVATE_KEY": "your_wallet_private_key_here"
}
}
}
}Variable | Required | Description | Default |
| Yes | Private key of the wallet for signing transactions | - |
Security Note: Handle your private key with extreme care. Ensure it is stored securely and only provided to trusted MCP client configurations.
"What are my current BAMM positions?"
"Show me the stats for all BAMM pools."
"Lend 100 LP tokens to the BAMM at address 0x..."
"Borrow 50 FRAX from my BAMM position."
"Repay 25 FRAX to my BAMM position."
"Add 100 FRAX as collateral to my BAMM position."
"Remove 50 USDC collateral from my position."
"Withdraw my LP tokens from the BAMM."
ADD_COLLATERALAdd collateral to your BAMM position
Parameter | Type | Required | Description |
| string | Yes | The address of the BAMM contract |
| string | Yes | The amount of collateral to add |
| string | The address of the collateral token | |
| string | The symbol of the collateral token (e.g., 'IQT') |
BORROWBorrow tokens from a BAMM position
Parameter | Type | Required | Description |
| string | Yes | The address of the BAMM contract |
| string | Yes | The amount to borrow |
| string | The address of the token to borrow | |
| string | The symbol of the token to borrow (e.g., 'IQT') |
LENDLend Fraxswap LP tokens to a BAMM contract
Parameter | Type | Required | Description |
| string | Yes | The address of the BAMM contract |
| string | Yes | The amount of LP tokens to lend |
REMOVE_COLLATERALRemove collateral from your BAMM position
Parameter | Type | Required | Description |
| string | Yes | The address of the BAMM contract |
| string | Yes | The amount of collateral to remove |
| string | The address of the collateral token | |
| string | The symbol of the collateral token (e.g., 'IQT') |
REPAYRepay borrowed tokens to a BAMM position
Parameter | Type | Required | Description |
| string | Yes | The address of the BAMM contract |
| string | Yes | The amount to repay |
| string | The address of the token to repay | |
| string | The symbol of the token to repay (e.g., 'IQT') |
WITHDRAWWithdraw LP tokens from a BAMM contract by redeeming BAMM tokens
Parameter | Type | Required | Description |
| string | Yes | The address of the BAMM contract |
| string | Yes | The amount of BAMM tokens to withdraw |
pnpm run buildpnpm run watchpnpm run lint
pnpm run formatsrc/tools/: Individual tool definitions
src/services/: API client and business logic
src/lib/: Shared utilities
src/index.ts: Server entry point
This project interacts with blockchain smart contracts and handles cryptocurrency transactions. Users should exercise caution, verify all data independently, and understand the risks involved in DeFi operations.
Add collateral to your BAMM position
| Name | Required | Description | Default |
|---|---|---|---|
| bammAddress | Yes | The address of the BAMM contract | |
| amount | Yes | The amount of collateral to add | |
| collateralToken | No | The address of the collateral token | |
| collateralTokenSymbol | No | The symbol of the collateral token (e.g., 'IQT') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It merely states 'add collateral' without explaining if it's a write operation, requires prior approvals, or has irreversible effects. Critical safety information is missing.
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, non-redundant sentence. It is concise but lacks structure; front-loading is effective, but it omits necessary detail.
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 complexity of the tool (4 parameters, two optional, no output schema) and absence of annotations, the description is insufficient. It does not cover prerequisites, return values, or typical usage context.
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 itself documents each parameter. The tool description adds no additional meaning beyond the schema's descriptions. 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 clearly states the action (add) and the resource (collateral to BAMM position), distinguishing it from siblings like REMOVE_COLLATERAL. However, it assumes familiarity with the term 'BAMM position', which may be unclear to new users.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., LEND or REPAY). There are no prerequisites, use cases, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Borrow tokens from a BAMM position
| Name | Required | Description | Default |
|---|---|---|---|
| bammAddress | Yes | The address of the BAMM contract | |
| amount | Yes | The amount to borrow | |
| borrowToken | No | The address of the token to borrow | |
| borrowTokenSymbol | No | The symbol of the token to borrow (e.g., 'IQT') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'borrow tokens' without explaining consequences (e.g., debt creation, collateral requirements, or mutability). This is insufficient for a transactional 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?
The description is a single concise sentence. However, it is possibly too minimal, sacrificing valuable context for brevity.
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 complexity of a borrowing operation and the lack of output schema or annotations, the description fails to provide essential behavioral and contextual details, such as what happens upon execution.
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?
Input schema has 100% coverage with descriptions for each parameter, so the baseline is 3. The tool description does not add additional semantic context beyond the schema.
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 action (borrow) and target (tokens from a BAMM position), but does not differentiate from sibling tools like LEND. It is specific enough for a general understanding.
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?
No guidance on when to use this tool versus alternatives like LEND, or any prerequisites. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all your active BAMM positions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description does not disclose behavioral traits such as data freshness, permissions, or side effects; agent has no additional behavioral context.
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 with no waste; efficiently conveys purpose without extraneous 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?
Minimal description covers basic function but lacks definition of 'BAMM', output details, and relation to siblings; adequate for such a simple tool but could be improved.
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?
Zero parameters mean schema coverage is complete; baseline score of 4 as per rules, though description does not elaborate on 'active BAMM positions'.
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 retrieval of user's active BAMM positions with specific verb and scope, implicitly distinguishing from mutation siblings but not from POOL_STATS.
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?
No guidance on when to use this tool versus alternatives like POOL_STATS or when not to use; agent must infer from name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lend Fraxswap LP tokens to a BAMM contract
| Name | Required | Description | Default |
|---|---|---|---|
| bammAddress | Yes | The address of the BAMM contract | |
| amount | Yes | The amount of LP tokens to lend |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states the action but omits critical details like required approvals, side effects (e.g., token transfer), reversibility, or success/failure conditions.
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?
A single, front-loaded sentence with no redundant words. Every piece of information earns its place.
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 financial lending action, the description is too brief. It lacks details about LP token type, approval steps, response behavior, and potential risks. Given no output schema, more context is needed.
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 baseline is 3. The description adds no extra meaning beyond the schema descriptions, which already define bammAddress and amount adequately.
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 action (Lend), the resource (Fraxswap LP tokens), and the target (BAMM contract), making it distinct from sibling tools like BORROW or ADD_COLLATERAL.
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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics for all BAMM pools
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation ('Get statistics'), which is consistent with the tool's nature. However, no additional behavioral details (e.g., data freshness, rate limits) are disclosed.
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, no extraneous words. Front-loaded with action and resource.
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 no output schema, the description could elaborate on what statistics are returned (e.g., TVL, rates). Currently vague, but functional. Not fully complete for a read tool with no schema.
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?
No parameters exist in the input schema, and schema coverage is 100% (empty). Description does not need to add parameter info. Baseline score of 4 for zero parameters 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 verb 'Get' and the resource 'statistics for all BAMM pools', distinguishing it from sibling tools which focus on individual actions like ADD_COLLATERAL or BORROW.
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?
No explicit guidance on when to use this tool vs siblings, but the purpose is clear and distinct from the transactional nature of other tools. Implied usage for retrieving pool-level data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove collateral from your BAMM position
| Name | Required | Description | Default |
|---|---|---|---|
| bammAddress | Yes | The address of the BAMM contract | |
| amount | Yes | The amount of collateral to remove | |
| collateralToken | No | The address of the collateral token | |
| collateralTokenSymbol | No | The symbol of the collateral token (e.g., 'IQT') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as effects on position state, authentication requirements, or reversibility, leaving the agent to infer from the name alone.
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, concise sentence that efficiently states the tool's purpose, though it omits necessary details.
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 lack of output schema and annotations, the description is incomplete; it does not explain return values, prerequisites, or the impact on the BAMM position, which is critical for a mutation tool.
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 for all 4 parameters, so the description adds no extra meaning beyond the schema. 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 verb 'Remove' and the resource 'collateral from your BAMM position', which distinguishes it from the sibling tool ADD_COLLATERAL.
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?
No guidance is provided on when to use this tool versus alternatives like REPAY or how to ensure the position has sufficient collateral to remove.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repay borrowed tokens to a BAMM position
| Name | Required | Description | Default |
|---|---|---|---|
| bammAddress | Yes | The address of the BAMM contract | |
| amount | Yes | The amount to repay | |
| borrowToken | No | The address of the token to repay | |
| borrowTokenSymbol | No | The symbol of the token to repay (e.g., 'IQT') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only implies mutation via 'Repay' but does not specify effects on position, required tokens, authorization needs, or return values. Minimal transparency.
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?
Definition is a single, front-loaded sentence with no redundant information. Every word serves a 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?
Despite no output schema and no annotations, the description is too sparse. For a financial tool with 4 parameters, it should explain side effects (e.g., reduction of debt), return values, and auth requirements. Both conciseness and completeness are insufficient.
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%, and descriptions exist for all parameters. However, most descriptions are tautological (e.g., 'The amount to repay') and add little beyond parameter names. The borrowTokenSymbol description provides an example, adding slight value. Baseline 3 is appropriate, but no significant enrichment.
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 'Repay borrowed tokens to a BAMM position' uses a specific verb (repay) and resource (borrowed tokens to a BAMM position). It clearly distinguishes from sibling tools like BORROW and REMOVE_COLLATERAL, indicating its unique action.
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?
No guidance on when to use this tool versus alternatives, no prerequisites (e.g., must have an active borrow), and no when-not-to-use conditions. The description provides no context for appropriate invocation.
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.
v1.0.0ADD_COLLATERALBORROWGET_POSITIONSLENDPOOL_STATSREMOVE_COLLATERALREPAYScored across 7 tools
Each tool has a clear, distinct purpose: adding/removing collateral, borrowing, repaying, lending, viewing positions, and pool statistics. No ambiguity or overlap.
All tool names follow a consistent UPPER_SNAKE_CASE pattern with action-first verbs (ADD, REMOVE, BORROW, REPAY, LEND, GET, POOL). Highly predictable.
7 tools is an appropriate scope for a DeFi protocol covering core operations—collateral management, borrowing, lending, and status queries—without being bloated.
The tool surface covers essential BAMM interactions: adding/removing collateral, borrowing, repaying, lending LP tokens, and querying positions and pool stats. No obvious gaps for typical usage.
A Model Context Protocol server for Wix AI tools
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Official Aave MCP for V3 and V4 markets, positions, governance, and transaction preparation.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
