Provides tools for browsing, quoting, and optionally transacting with FlashBank P2P term-loan escrow and flash-loan router contracts on Ethereum and its testnets.
A Model Context Protocol server that lets AI agents browse, quote and (optionally) transact with the FlashBank contracts — the P2P term-loan escrow and the flash-loan router — on Ethereum, Base, Arbitrum and the Sepolia playground.
Self-contained: inline minimal ABIs, public RPCs, no Hardhat compilation needed. Read tools work
with zero configuration; write tools are opt-in and safety-gated. Beyond the 15 tools it
serves resources (flashbank://guide, flashbank://chains, flashbank://cooling-off,
flashbank://safety), guided prompts (play_on_sepolia, lend_assets,
borrow_against_collateral) and connect-time instructions, and every tool carries MCP safety
annotations (readOnlyHint / destructiveHint / idempotentHint) so agent clients can reason
about risk before calling anything.
cd mcp && npm install && npm test # 16 tests incl. a full MCP stdio handshake — no network/key needed
npm run smoke # live read-only check against the deployed contracts
npm run drill # LIVE two-agent lifecycle drill on Sepolia (needs a funded key)The drill spawns two real MCP server instances (lender agent + a throwaway borrower agent) and walks faucet → create → browse → take (pinned) → early repay (cooling-off rebate verified) → withdraw-unclaimed probe → cancel, with real transactions on the Sepolia playground.
Mode | Requirement | What it allows |
Read-only (default) | nothing | browse offers, quotes, pool stats, wallet lookups |
Playground writes |
| create/take/repay/claim/cancel + faucet on Sepolia |
Mainnet writes | …and | the same on Ethereum/Base — real assets, real risk |
Use a dedicated throwaway key for agents; never a key holding meaningful funds. Mainnet writes are deliberately double-gated and the contracts carry no external audit.
Related MCP server: agentfi-mcp-server
Read (always available)
Tool | Purpose |
| Plain-English primer on both products — agents should call this first |
| Chains, contract addresses, registry tokens, current write permissions |
| Signer address + native/token balances on a chain |
| Open offers, boosted first, with human-readable terms |
| Full detail: terms, take quote, repayment quote, default split, terms pin |
| Loans created by an address (or the signing wallet) |
| Flash-loan liquidity, fee bps, caps and provider count per token |
| Fee + fundability quote for a flash-borrow amount |
Write (gated as above)
Tool | Purpose |
| Post a lend offer / borrow request (escrows your side; handles the approval; optional |
| Accept an offer, pinning the exact reviewed terms on-chain (terms hash, or version pin on older builds — feature-detected) |
| Repay and redeem collateral; on v2 chains reports the vested fee and any cooling-off rebate |
| Lender claims collateral after the repay window closes |
| Cancel your untaken offer and reclaim escrow |
| v2: withdraw a payout that queued because it couldn't be delivered to you |
| Mint 10,000 fpUSD/fpETH play-money (Sepolia only) |
Flash loans are quote/read only by design: executing one requires a smart contract implementing the borrower callback, which is not something an MCP tool should improvise.
Resource | Content |
| The product primer (same text as |
| Chain/contract/token registry as JSON, incl. per-chain contract versions |
| The v2 fee-vesting model with the exact formula |
| The write-gating model and agent rules of thumb |
Prompt | Workflow |
| Safe first session: faucet → post → inspect → cancel, narrated |
| Compose a sensible lend offer (cushion, fee, term, surplus-return) and place it |
| Shortlist offers, compare true cost + default risk, take with pinned terms |
Via npm (recommended — published as @flashbank/mcp):
{
"mcpServers": {
"flashbank": {
"command": "npx",
"args": ["-y", "@flashbank/mcp"]
}
}
}Add "env": { "FLASHBANK_MCP_PRIVATE_KEY": "0x<throwaway-key>" } to enable writes. Claude Desktop
uses the same JSON shape in claude_desktop_config.json; Claude Code:
claude mcp add flashbank -- npx -y @flashbank/mcp. The server is also listed in the
official MCP Registry as
io.github.Rotwang9000/flashbank, so registry-aware clients can discover and install it by name.
From this repo:
{
"mcpServers": {
"flashbank": {
"command": "node",
"args": ["mcp/src/server.js"]
}
}
}The repo ships a project-level .cursor/mcp.json that registers it for Cursor in read-only
mode (no env block = read-only).
Via Docker:
cd mcp && docker build -t flashbank-mcp .
docker run -i --rm flashbank-mcp # read-onlyAny other MCP client works the same way — stdio transport, command node src/server.js.
Variable | Default | Meaning |
| unset | Signing key; unset = read-only |
| unset |
|
| public RPC | Override the RPC per chain, e.g. |
src/chains.js chain registry (addresses, tokens, RPCs, p2pVersion) — update on redeploys
src/abi.js inline minimal ABIs, version-aware (v1 mainnets, v2 Sepolia playground)
src/clients.js providers, signer, write gate, token resolution, allowances
src/format.js pure formatting helpers (unit-tested)
src/server.js the MCP server: tools, resources, prompts, annotations
scripts/mcp-client.js minimal stdio client shared by the protocol test and the drill
scripts/smoke.js live read-only smoke against the real deployments
scripts/drill.js live two-agent lifecycle drill on Sepolia
test/ node:test suites incl. a full MCP stdio protocol test
Dockerfile container build (stdio entrypoint), used by hosts like GlamaThe listing on Glama is maintained via
the repo-root glama.json.
The Sepolia playground runs FlashBankP2PLoanV2 (0x536f…1E76): cooling-off rebate, token
validation and pull-payouts (see docs/design/P2P_V2_COOLING_OFF.md). Mainnets stay on v1 until
v2 graduates.
Plain-English primer on both FlashBank products, the loan lifecycle, fees and safety rules. Call this first if you are unsure how anything works.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds context that the tool is a 'Plain-English primer' covering specific content areas, which enriches behavioral understanding 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 consists of two sentences: the first defines content, the second provides usage advice. It is front-loaded, every word earns its place, and 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?
Given no parameters and no output schema, the description covers the tool's purpose and content thoroughly, mentioning products, lifecycle, fees, and safety rules. There is no missing essential information.
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?
There are zero parameters and schema coverage is 100%, so the description does not need to add parameter meaning. The description is clear and sufficient without parameter details.
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 'Plain-English primer' covering FlashBank products, loan lifecycle, fees, and safety rules. This distinguishes it from sibling tools that perform specific operations (e.g., p2p_create_offer, faucet_mint). The verb 'explain' and resource 'FlashBank' are explicit.
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 advises 'Call this first if you are unsure how anything works,' providing clear context for when to use it. It does not explicitly state when not to use or list alternatives, but the guidance is strong and implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mint a free batch of 10,000 fpUSD or fpETH (valueless playground tokens) to the signing wallet on Sepolia. The safe way for agents to get funds to experiment with.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Which playground token to mint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show non-readonly, non-idempotent, non-destructive. Description adds key behaviors: mints 10,000 free tokens, sends to signing wallet, tokens are valueless playground tokens. No contradictions.
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 action and details, no unnecessary words. 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?
For a simple one-parameter tool with full schema coverage and no output schema, the description fully covers purpose, behavior, and parameter. No gaps.
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% with enum, so the schema already documents the parameter. Description echoes the enum values without adding new semantics beyond 'fpUSD or fpETH'.
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 verb 'Mint', resource '10,000 fpUSD or fpETH', destination 'signing wallet on Sepolia', and notes they are valueless playground tokens. Distinguishes from sibling tools as the only faucet.
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 'safe way for agents to get funds to experiment with', providing context for when to use. No explicit alternatives or exclusions listed, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-token flash-loan liquidity on a chain: committed amount, live available liquidity, fee, per-loan cap and provider count.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and dynamic nature are covered. The description adds value by listing the returned fields (committed amount, live available liquidity, fee, per-loan cap, provider count), giving insight into the output. However, it does not describe pagination, result format, or potential authorization 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 core purpose and lists key output attributes. There is no extraneous information; every part is relevant and 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 the simplicity (one parameter, no output schema) and annotations covering safety, the description provides essential return fields. However, it is ambiguous whether the output is a list of pools per token or a single pool, and it does not specify that it returns multiple tokens' data. Some operational detail is missing for full completeness.
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?
With schema description coverage at 0%, the description should explain the 'chain' parameter, but it only implies its necessity by mentioning 'on a chain.' It does not elaborate on the enum values or their effect. The description adds minimal semantic value beyond what the schema already shows.
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 per-token flash-loan liquidity details on a chain, listing specific fields. This distinguishes it from siblings like flash_quote, which likely provides a quote. However, it lacks an explicit verb like 'Retrieve' or 'List,' slightly reducing clarity.
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 provides no guidance on when to use this tool versus alternatives like flash_quote. It does not mention context, prerequisites, or whether it is for overview before executing a flash loan. This leaves the agent without operational direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fee quote for flash-borrowing a given amount of a token (symbol or address) on a chain.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| token | Yes | Token symbol (e.g. "WETH") or 0x address | |
| amount | Yes | Human amount to borrow, e.g. "250" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, read-only operation that may fetch external data. The description adds no additional behavioral context, such as what happens if the token or chain is unsupported, response format, or potential errors. It merely restates the tool's purpose.
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, well-structured sentence that immediately communicates the tool's purpose. It is front-loaded with 'Fee quote' and contains no redundant or 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?
Given the absence of an output schema and three required parameters, the description is incomplete. It does not explain what the tool returns (e.g., a fee percentage, total cost, or estimated interest), nor does it mention that the tool queries external data (implied by openWorldHint). A complete description would include the return format or example output.
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 67% (chain lacks a description). The tool description does not add any parameter semantics beyond what the schema provides; it merely repeats 'token (symbol or address)' which is already in the token parameter's description. It fails to clarify the chain parameter's permissible values (though the enum covers that) or add constraints like decimal precision for amount.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: providing a fee quote for flash-borrowing a specific token amount on a chain. The verb 'quote' is specific to the resource 'flash loan', and the mention of 'Fee quote' distinguishes it from sibling tools like flash_pools (which list pools) and faucet_mint (which mints 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?
The description does not provide any guidance on when to use this tool versus alternatives. For instance, it does not mention that users might first use flash_pools to find available pools or that this tool is a prerequisite for executing a flash loan. There is no mention of when not to use it or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Supported chains with contract addresses, registry tokens and whether writes are currently permitted for each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true. The description adds behavioral context about the specific data returned (contract addresses, registry tokens, write permissions), which is valuable 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 concise sentence that conveys all necessary information without redundancy, earning its place efficiently.
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 parameters, no output schema, and rich annotations, the description adequately specifies what the tool returns, though it could optionally note that no arguments are 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?
With zero parameters and 100% schema coverage, the description adds meaning about the output contents, which is sufficient since the schema provides no additional constraints.
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 supported chains with contract addresses, registry tokens, and write permission status, using specific nouns and verbs that distinguish it from sibling tools like explain, flash_pools, etc.
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 usage for obtaining chain configuration but provides no explicit guidance on when to use this tool versus alternatives or any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel an offer you created that has not been taken, reclaiming your escrow (any boost spend is not refunded). Mainnet gated.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| chain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: 'reclaiming your escrow' (side effect), 'any boost spend is not refunded' (cost), and 'Mainnet gated' (restriction). Annotations already state idempotent and non-destructive; description is consistent and adds value.
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 action and key constraints (reclaim, non-refundable boost, mainnet). 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?
Covers essential context for a simple tool: what it does, side effects, restrictions. Could briefly mention error cases (e.g., offer not found), but adequate for 2-param tool with no output 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?
Schema has 2 parameters (id, chain) with 0% description coverage. Description does not elaborate on their meaning. While names are somewhat self-explanatory, description fails to compensate for missing schema documentation.
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 verb 'Cancel', resource 'offer you created that has not been taken', and key constraints ('reclaiming your escrow', 'Mainnet gated'). It distinguishes from sibling tools like p2p_take_offer or p2p_repay.
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?
Provides specific context: cancel only unsold offers, escrow reclaim but boost non-refundable, mainnet-only. Implicitly excludes taken offers but doesn't name alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
After the repay window closes unpaid, the lender claims the collateral (any agreed surplus returns to the borrower). Irreversibly settles the loan. Requires the signing wallet to be the lender (mainnet gated).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| chain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint (true) and readOnlyHint (false); the description adds value by specifying what gets destroyed ('irreversibly settles the loan') and the collateral mechanics (surplus returns to borrower). 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?
Two sentences that are front-loaded with the core action, no filler, 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?
The tool has no output schema, so the description should explain the return value (e.g., transaction hash) and potential errors. It only describes the effect. Annotations cover safety, but output and failure modes are missing. Adequate for simple tools, but could be more 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?
With 0% schema description coverage, the description should compensate by explaining the parameters 'id' (likely loan ID) and 'chain' (enum for blockchain). It does not mention either, leaving the agent to infer from context. This is a significant gap.
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 that this tool is for claiming collateral after default, specifying the action ('claims the collateral'), the context ('after the repay window closes unpaid'), and the irreversibility ('irreversibly settles the loan'). It effectively distinguishes from sibling tools like p2p_repay (repayment) and p2p_cancel (cancellation).
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 gives context on when to use ('after the repay window closes unpaid') and a prerequisite ('requires the signing wallet to be the lender, mainnet gated'). It lacks explicit when-not-to-use or direct comparison to alternatives, but the provided guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a loan offer (you lend) or borrow request (you borrow) on-chain. Escrows your side immediately: lenders escrow the principal, borrowers escrow the collateral. Reversible via p2p_cancel while untaken. Requires a signing key; mainnet additionally requires FLASHBANK_MCP_ALLOW_MAINNET=true.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | "lend" = you provide the principal; "borrow" = you provide the collateral | |
| chain | Yes | ||
| flatFee | Yes | Flat repayment fee in principal-token units (e.g. "30" = repay principal + 30). NOT a percentage. | |
| graceDays | No | Grace period after maturity (days, default 1) | |
| principal | Yes | Principal amount (human units, e.g. "1000") | |
| collateral | Yes | Collateral amount (human units) | |
| allowedTaker | No | Restrict who may take (address). Omit for open market. | |
| durationDays | Yes | Loan term in days | |
| principalToken | Yes | Token being lent — symbol or address | |
| collateralToken | Yes | Token pledged as collateral — symbol or address | |
| coolingOffHours | No | v2 chains (Sepolia) only: cooling-off window in hours over which the fee vests. Omit or 0 = the protocol minimum for the term; longer is allowed, shorter rejects. | |
| settlementValue | No | Agreed value of ALL the collateral in principal-token units; surplus above the debt returns to the borrower on default. Omit for full forfeit. | |
| offerExpiryHours | No | Hours until the un-taken offer expires (default: never) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-idempotent, non-destructive. Description adds immediate escrow behavior and reversibility, providing useful 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?
Three sentences, front-loaded with purpose, efficient 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?
High schema coverage and description cover creation process and side behavior. Lacks output specification (e.g., offer ID), but acceptable for creation tool without output 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?
Schema coverage is 92%, so baseline is 3. Description reinforces side behavior with escrow explanation and adds mainnet requirement context, adding value beyond 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?
Clearly states the verb 'Post' and the resource 'loan offer or borrow request'. Distinguishes from sibling tools like p2p_cancel by mentioning reversibility.
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?
Tells when to use (to post an offer/request) and mentions reversibility via p2p_cancel. Includes prerequisites (signing key, mainnet config). Does not explicitly say when not to use, but siblings provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one loan id: terms, parties, status, what a taker must provide, repayment quote, default deadline/split and the on-chain terms hash.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Loan id | |
| chain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds value by listing the specific details returned (terms, parties, status, etc.) and mentions 'on-chain terms hash', confirming blockchain interaction without contradicting 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, 23 words, front-loaded with key functionality. Every part is informative with no redundant 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?
For a simple read-only operation with two parameters, the description covers the returned fields adequately. No output schema exists, but the listed fields give sufficient context. Could mention output format but not essential.
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 only 50% (only 'id' has a description). Description does not explain 'chain' enum options or 'id' constraints beyond what schema provides. It adds minimal semantic value for 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?
Description clearly states it returns full detail for one loan id, listing specific fields like terms, parties, status, etc. It distinguishes from sibling tools like p2p_list_offers or p2p_my_loans which are for listing multiple items.
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?
Implicitly indicates use when you have a specific loan id. Does not explicitly state when not to use or compare to alternatives, but context clarifies that this is for single-loan detail retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open, takeable loan offers/requests on a chain, newest first with boosted (featured) offers ranked on top. Returns human-readable terms plus the raw ids for follow-up calls.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain to browse | |
| limit | No | Max offers to return (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and openWorld hints. The description adds ordering details and return format (human-readable terms plus raw IDs), which is helpful 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, no wasted words. Front-loaded with key information: what, where, order, return format.
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 list tool with no output schema, the description explains return content. It could mention pagination or explain 'boosted' offers, but it is largely complete given the 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 baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides (e.g., chain and limit).
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 lists open loan offers/requests on a chain, with specific ordering (newest first, boosted on top). It distinguishes from siblings like p2p_create_offer or p2p_take_offer by focusing on browsing.
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 context implies use when you want to see available offers, but it does not explicitly state when not to use it or mention alternatives. However, the sibling tool names provide enough differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every loan created by or assigned to an address (defaults to the configured wallet), with current status.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| address | No | Address to look up (defaults to the signing wallet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, establishing the tool is safe and state-agnostic. The description adds that the address defaults to the configured wallet and returns current status. No contradictions, but no additional behavioral traits (e.g., pagination, rate limits) are disclosed 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?
A single concise sentence that front-loads the core purpose. It is efficient but could benefit from structuring (e.g., bullet points) to highlight key details like default behavior and status reporting. Nonetheless, it earns its place without 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?
The tool has no output schema, and the description omits what fields constitute 'current status' or how results are ordered/filtered. Given the complexity of loan states and many sibling tools, the description is under-specified for an agent to fully understand the return value and make optimal decisions.
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 50%: only 'address' has a description. The description repeats that address defaults to the configured wallet but adds no meaning for 'chain' parameter (which has enum values). With half the parameters undocumented, the description fails to compensate, leaving ambiguity about chain values.
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 every loan created by or assigned to an address, with current status. This distinguishes it from siblings like p2p_get_loan (single loan) and p2p_list_offers (offers), providing a specific verb-resource combination.
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 usage for querying loans related to an address, defaulting to the configured wallet. However, it does not explicitly state when to use this over alternative listing tools (e.g., p2p_get_loan for a specific loan), nor provides exclusion criteria. With multiple sibling tools, explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repay an active loan you borrowed, redeeming your collateral. On v2 chains (Sepolia) the fee is the VESTED amount — repaying inside the cooling-off window is rebated down to a 10% floor. Requires the signing wallet to be the borrower (mainnet gated).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| chain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by mentioning collateral redemption, fee specifics (vested amount, cooling-off rebate), and borrower restriction. No contradiction with annotations (destructiveHint=true, readOnlyHint=false).
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 cover the main purpose and key nuances (fee, borrower requirement) without any 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?
The description covers the action and key constraints but lacks parameter descriptions and does not specify output or error conditions. For a simple repay tool, it is adequate but has gaps.
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?
With 0% schema description coverage, the description must compensate but does not explain the meaning of 'id' (loan identifier) or 'chain' beyond what is in the schema. No parameter details are provided.
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 'repay' and the resource 'active P2P loan', and distinguishes from siblings like p2p_cancel or p2p_create_offer by focusing on borrower repayment.
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?
It provides clear context by stating the borrower requirement and mainnet gating, and explains fee behavior on Sepolia. However, it does not explicitly compare to alternative tools or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accept an open offer, pinning the EXACT terms currently on-chain (takeWithTerms) so a last-second re-price reverts instead of surprising you. Approves and escrows your side, which activates the loan — a BINDING commitment until repaid or defaulted. Requires a signing key (mainnet gated).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Loan id to take | |
| chain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it explains the on-chain mechanism (pinning exact terms), the binding nature of the commitment, and the requirement for a signing key. Annotations already indicate non-read-only, open-world, idempotent, and destructive hints, but the description enriches these with practical implications.
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, both impactful. The first front-loads the mechanism and benefit, the second adds consequences and requirements. 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?
Given the complexity of an on-chain loan activation tool with no output schema and two parameters, the description covers purpose, behavioral traits, and a key requirement (signing key). It could mention failure modes or return values, but overall it is sufficiently complete for an agent.
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 covers 50% of parameters (id has description, chain lacks description). The description does not elaborate on parameter meaning or provide usage details for the parameters, so it does not compensate for the missing schema description. 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 tool accepts an open offer and activates a loan, using specific verbs ('Accept', 'pinning', 'Approves and escrows'). It distinguishes itself from sibling tools like p2p_create_offer and p2p_cancel by focusing on taking an existing offer.
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 use when accepting an open offer and mentions a signing key requirement, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like p2p_repay or p2p_cancel. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
v2 chains (Sepolia) only: if a settlement payout to you could not be delivered (e.g. a blocklisting token), it queues on-chain — this checks your queued balance for a token and withdraws it.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| token | Yes | Token symbol or 0x address the payout was in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate not read-only and not destructive. The description adds context: why payouts are queued (e.g., blocklisting token) and that it withdraws the queued balance. This goes beyond annotations, though it does not detail side effects like reversibility or fees.
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, moderately long sentence that front-loads the action. It contains no fluff and earns its place, but splitting could improve readability.
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 and two simple parameters, the description explains the scenario adequately. However, it omits details like idempotency (though in annotations), error conditions, and the exact process. The scope limitation to Sepolia is not reflected in the schema, which could lead to incorrect usage.
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 50% (token has a description). The description adds meaning to the chain parameter by restricting to Sepolia, but this contradicts the schema enum. For token, it adds little beyond the schema. Overall, it provides some value but with inconsistency.
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 checks a queued balance and withdraws it, with a specific scenario (settlement payout could not be delivered). It distinguishes from siblings like p2p_claim_default by focusing on unclaimed payouts. However, it says 'v2 chains (Sepolia) only' while the schema accepts other chains, creating potential confusion.
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 explains when to use (when a settlement payout could not be delivered) and limits to v2 chains (Sepolia). It does not explicitly mention alternatives or when not to use, though context implies it's for queued payouts only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Address, native balance and registry-token balances of the configured signing wallet on one chain. Reports read-only mode when no key is set.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value by noting that it reports read-only mode when no key is set. This extra context about behavior beyond what annotations provide is helpful.
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 with zero wasted words. The first sentence clearly states the outputs, and the second adds a behavioral note. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key outputs (address, balances, read-only mode) without an output schema. It is sufficient for a simple tool, though it could optionally detail the format of balances. Still, it provides adequate 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%, with the 'chain' parameter described as 'Chain to inspect'. The description mentions 'on one chain', aligning with the schema but adding no new meaning. 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 it reports address, native balance, and registry-token balances for the configured signing wallet on one chain. This provides a specific verb and resource, and it distinguishes itself from sibling tools like p2p or faucet 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?
No guidance on when to use this tool versus alternatives. While the purpose is clear, there is no explicit when-to-use or when-not-to-use information, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: explain, faucet, flash loans, P2P lifecycle actions, wallet status. No two tools appear to do the same thing; even similar P2P tools are clearly separated by action (create, take, cancel, repay, claim).
Most tools follow a verb_noun pattern (e.g., list_chains, p2p_create_offer, p2p_repay), but a few start with a noun (faucet_mint, flash_pools, wallet_status) and one uses an adjective (p2p_my_loans). Minor inconsistency but still predictable.
15 tools is appropriate for the domain covering flash loan overview, test tokens, chain info, and full P2P lending lifecycle. Each tool serves a needed function without being excessive.
The tool set covers explanation, test funding, flash loan info, P2P offers, actions, and wallet status. A minor gap is the inability to modify an offer (only cancel), but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Complete financial infrastructure for AI agents — payments, lending, escrow & more.
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
Agent credit issuance and scoring — programmable credit lines on Base L2
Agent-to-agent escrow on Base. Post quests with ETH/USDC bounties and settle on-chain.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rotwang9000/flashbank-net'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
