Skip to main content
Glama

Crank Protocol

by ing.crank

set_liquidation_alert

Arm a liquidation alert: notify when a lending obligation's health factor falls to or below threshold.

protocol: kamino | marginfi (marginfi_account required for marginfi). threshold is the HF level (e.g. 1.2 warns before the <1.0 liquidation point). Evaluated every 30s by Celery beat; webhook_url is POSTed on trip.

Workflow: MONITOR step -- arm after opening a leveraged/borrow position so a deteriorating obligation loops you back to repay/de-risk. Pairs with get_health_factor. See get_trading_workflow.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketNo
protocolYes
caller_idNo
thresholdYes
webhook_urlNo
wallet_addressYes
marginfi_accountNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=false, etc.), the description adds that alert is evaluated every 30 seconds by Celery beat and POSTs to webhook_url on trip. It explains threshold semantics and protocol constraints, providing rich 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized and front-loaded with purpose, then details, then workflow. Every sentence adds value, but there is slight redundancy (e.g., 'protocol: kamino | marginfi' could be integrated). Overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given parameter count (7) and output schema present, the description covers core functionality, workflow, and constraints. It lacks explicit handling of optional parameters (market, caller_id), but the essential behavior and context are well-addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description compensates well for core parameters (protocol, threshold, wallet_address, marginfi_account). It explains threshold meaning and protocol-specific requirements. However, it does not explicitly describe market, caller_id, or webhook_url beyond mentioning webhook_url is POSTed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool arms a liquidation alert with a specific condition (health factor falls to or below threshold), protocol choices, and evaluation mechanism. It distinguishes itself from siblings by specifying the exact use case and protocol.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool: after opening a leveraged/borrow position in a MONITOR step. It pairs with get_health_factor and references get_trading_workflow. It also notes protocol-specific requirements (e.g., marginfi_account for marginfi).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Crank Protocol toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

Multiple tools overlap significantly: close_perp_position vs perp_close, get_leaderboard vs get_score_leaderboard vs get_strategy_leaderboard, get_venue_status vs get_all_venues_status, send_token_social vs bulk_send_social, and get_crank_score vs get_score. Several read-only tools have nearly identical purposes, and the descriptions do not always clarify boundaries.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (get_balances, create_strategy, set_alert, list_webhooks). However, there are deviations like 'lst_swap', 'jupiter_swap', 'flash_loan', 'sr_backtest', and the use of both 'get_' and 'list_' for reads, plus category prefixes like 'perp_' and 'strategy_' that vary in order. Overall still readable and predictable.

Tool Count1/5

177 tools is an extreme count for any server, far exceeding the 25+ threshold for 'too many'. Even a full DeFi platform does not need this many separate operations; the surface is overwhelming and clearly not well-scoped.

Completeness3/5

The domain (Solana DeFi trading) is covered extensively across swaps, perps, lending, staking, strategies, signals, and support. However, there are notable gaps: no lend_withdraw, no direct way to close a lending position, no spot order cancellation (though aggregator-based swaps may not need it), and a general lack of tiered account management. The huge number of tools makes it hard to identify missing lifecycle steps.

Resources