The RiskState MCP server provides a single get_risk_policy tool for real-time risk governance, designed for autonomous crypto trading agents to query before executing trades.
Get risk policy decisions: Receive a structured policy including one of 5 levels — BLOCK_SURVIVAL, BLOCK_DEFENSIVE, CAUTIOUS, GREEN_SELECTIVE, or GREEN_EXPANSION — along with max_size_pct, leverage_max, and lists of allowed/blocked actions
Support BTC and ETH: Currently performs risk analysis for Bitcoin and Ethereum
Assess market conditions: Responses include cycle_phase, market_regime, macro_regime, and direction classifications
Receive confidence and auditability metrics: Get confidence_score (0–1), composite_score, policy_hash, and ttl_seconds for cache management and auditability
Integrate DeFi on-chain data: Optionally provide a wallet_address and lending protocol (spark or aave) to factor in on-chain position data (LTV, health factor)
Request detailed breakdowns: Use include_details to get composite subscores, macro data, risk flags, and data sources
Handle errors gracefully: Specific error messages for authentication issues, rate limits, and timeouts aid agent recovery
Integrate with Claude ecosystem: Works with Claude Desktop and Claude Code via MCP protocol with stdio transport, with input validation via Zod schemas
MCP server for RiskState — pre-trade risk permissions for BTC/USD and ETH/USD. Spot, perpetual futures (perps), and DeFi borrowing aware.
Your system asks: "How much can I risk right now?" RiskState answers with: policy level, max exposure, leverage limits, blocked actions — computed from 30+ real-time signals.
Wraps the RiskState /v1/risk-state API as an MCP tool. One tool: get_risk_policy.
Field | Description |
| 5 levels: BLOCK_SURVIVAL, BLOCK_DEFENSIVE, CAUTIOUS, GREEN_SELECTIVE, GREEN_EXPANSION |
| Maximum position size as % of portfolio (0-100) |
| Maximum allowed leverage multiplier |
| What the agent CAN do at this policy level |
| What the agent CANNOT do |
| Signal agreement x data quality (0-1) |
The API aggregates 9+ real-time data sources server-side. See API docs for details.
This is a thin wrapper — it translates MCP tool calls into REST API requests to POST /v1/risk-state and returns the response. All computation (scoring, policy engine, data ingestion) happens server-side.
This wrapper adds:
MCP protocol compliance (stdio transport for Claude Desktop/Code)
Input validation via Zod schemas
Human-readable policy summary prepended to responses
Specific error messages (auth, rate limit, timeout) for agent recovery
This wrapper does NOT:
Cache responses (the API has 60s server-side cache)
Perform any scoring or computation locally
Guarantee response schema stability (follows API versioning)
npm install @riskstate/mcp-serverVariable | Required | Description |
| Yes | API key from riskstate.ai (free during beta) |
| No | Custom API base URL (default: |
Add to ~/.config/Claude/claude_desktop_config.json:
{
"mcpServers": {
"riskstate": {
"command": "npx",
"args": ["-p", "@riskstate/mcp-server", "riskstate-mcp"],
"env": {
"RISKSTATE_API_KEY": "your-api-key"
}
}
}
}claude mcp add riskstate -- npx -p @riskstate/mcp-server riskstate-mcpSet the API key in your environment:
export RISKSTATE_API_KEY=your-api-keynpm install -g @riskstate/mcp-server
riskstate-mcp # starts MCP server on stdioThe server exposes one tool: get_risk_policy
Parameter | Type | Required | Description |
|
| Yes | Asset to analyze |
| string | No | DeFi wallet for on-chain position data |
|
| No | Lending protocol (default: spark) |
| boolean | No | Include full breakdown (subscores, macro, risk flags) |
{
"exposure_policy": {
"policy_level": "CAUTIOUS",
"max_size_pct": 35,
"leverage_max": 1.5,
"allowed_actions": ["DCA", "WAIT", "SPOT_LONG_CONFIRMED"],
"blocked_actions": ["LEVERAGE_GT_2X", "NEW_POSITIONS_UNCONFIRMED"]
},
"classification": {
"cycle_phase": "MID",
"market_regime": "RANGE",
"macro_regime": "NEUTRAL",
"direction": "SIDEWAYS"
},
"auditability": {
"composite_score": 52,
"confidence_score": 0.72,
"policy_hash": "a3f8c2...",
"ttl_seconds": 60
}
}Call get_risk_policy before every trade:
If policy_level starts with BLOCK → do not open new positions
Use max_size_pct to cap position sizing
Check blocked_actions before executing
Re-query after ttl_seconds (60s cache)
v1 scope: BTC/USD and ETH/USD only (USD-denominated assessment). More assets planned.
Markets: Spot, perpetual futures, and DeFi borrowing. Same response — interpretation differs by market (see API docs).
Protocols: Spark and Aave V3 only for DeFi position data.
Rate limit: 60 requests/minute per API key.
Latency: ~1-3s per request (9+ upstream data source aggregation).
Tested with: Claude Desktop, Claude Code. Should work with any MCP-compatible client.
Landing page: riskstate.ai
API docs: riskstate.ai/docs/api
SKILL.md: agentskills.io
MIT
Get the current risk governance policy for a crypto asset. Returns policy level (BLOCK/CAUTIOUS/GREEN), max position size, leverage limits, allowed and blocked actions, and confidence score. Call this BEFORE every trade to determine how much risk is allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Asset to get risk policy for | |
| wallet_address | No | DeFi wallet address for on-chain position data (LTV, health factor) | |
| protocol | No | DeFi lending protocol (default: spark) | |
| include_details | No | Include detailed breakdown: composite subscores, macro data, risk flags, data sources |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description implies a read-only operation ('Get'). Discloses what is returned. Does not hide any destructive behavior. Lacks detail on authentication or rate limits, but adequate for a policy retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and output details, followed by usage guideline. No unnecessary words. Excellent conciseness.
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 or sibling tools, description provides clear purpose, return fields, and usage context. Could mention output format (JSON) but not essential. Sufficient for agent to select and invoke.
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 4 parameters. Description does not add significant new semantics beyond the schema; it focuses on return values. Baseline 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?
Clearly states 'Get the current risk governance policy for a crypto asset' with specific verb and resource. Lists returned fields including policy level, position size, leverage limits, etc. Purpose is unambiguous.
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 'Call this BEFORE every trade to determine how much risk is allowed.' Provides clear usage context. No alternative tools or when-not-to-use mentioned, but for a standalone tool, this is sufficient.
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.
get_risk_policy1 field changedInput schema / properties / wallet_address / patternAdded value: +"^0x[a-fA-F0-9]{40}$"v1.0.0get_risk_policyWith only one tool, there is no possibility of ambiguity or overlap with other tools. The tool's purpose is clearly defined and distinct by default.
The single tool name follows a clear verb_noun pattern (get_risk_policy), and with no other tools to compare, consistency is inherently perfect.
One tool is too few for a server focused on risk governance, as it lacks essential operations like updating policies, checking compliance, or managing assets, making the surface incomplete for the domain.
The tool set is severely incomplete for risk governance; it only provides read access to policies without any create, update, delete, or monitoring capabilities, leaving significant gaps for agent workflows.
Live BTC/ETH risk state: risk policy, market structure and trading playbooks. Keyless free tier.
Treasury and risk controls for agent wallets: policies, quotes, prediction-market orders.
Live crypto market signals for AI agents: perp liquidations, funding, OI positioning, yield, FX.
Risk regime + treasury for AI agents on Base: free regime reads, signed attestations, idle USDC.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/likidodefi/riskstate-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
