This server provides tools to interact with Lighter, a zk-rollup perpetual DEX, enabling market data queries, account monitoring, and trade execution via the Model Context Protocol.
Market Data
List all tradeable perpetual markets and fetch metadata for a specific market
Retrieve OHLCV candlestick data with configurable intervals (1m, 5m, 15m, 1h, 4h, 1d)
Get real-time ticker data (bid/ask/last price), order book depth, and current funding rates
Account Management (requires account index)
Check balance details (collateral, margin-in-use, available, asset value)
View open positions and specific position details
Trading (requires private key)
Place USDC-notional market orders and base-amount limit orders
Set on-chain stop-loss and take-profit orders
Close open positions, cancel individual orders by ID, or cancel all open orders
Adjust leverage per market
Security & Safety
Three-tiered access levels (Public, Read, Trade) with sub-account isolation (API key cannot withdraw funds)
Configurable server-side safety caps for max trade size, slippage, and allowed symbols
Diagnostics & Info
Check server mode, active safety limits, and integrator fee configuration
Get Lighter sign-up info (includes a referral code for a 5% bonus for new users)
View instructions to opt into or revoke the transparent integrator fee (1 bp maker / 2 bps taker, requires on-chain approval, expires after 90 days)
Enables trading on Lighter, a zero-fee zk-rollup perpetual DEX on Ethereum, including market data queries, account management, and order placement with on-chain stop-loss/take-profit.
A Model Context Protocol server for Lighter — a zero-fee zk-rollup perpetual DEX on Ethereum.
Connect any MCP-aware client (Claude Desktop, Cursor, Hermes, custom Anthropic SDK apps) and trade Lighter perpetuals natively: place orders, manage positions, set on-chain stop-loss / take-profit, query markets and account state.
Sign up here for a 5% bonus on your first trades:
The bonus is applied automatically at account creation — the referral code only works during signup, not after. If you already have a Lighter account, skip this section.
Related MCP server: hyperliquid-mcp
This MCP is free and open-source. You can install it, run it, and trade through it without paying anyone.
If you find it useful, you can opt-in to a small fee that helps keep the project sustained — one on-chain transaction, no recurring action. The fee is 1 bp maker (0.01%) / 2 bps taker (0.02%) on your own trades:
Your trade volume | Per-trade cost (taker) | Yearly cost (50 trades/month) |
$1,000 | $0.20 | ~$120 |
$100 | $0.02 | ~$12 |
$50 (lighter sub-account default) | $0.01 | ~$6 |
The fee routes via Lighter's permissionless partner-integrator program to the maintainer's account 725426. No fees flow until you sign an on-chain ApproveIntegrator once. It's strictly opt-in: you can install + trade without ever approving.
Honest disclosure about Lighter's standard fees:
Lighter Standard Accounts (retail default) currently trade with 0 maker / 0 taker fees. Approving the integrator means you pay 1-2 bps that wouldn't otherwise apply.
Lighter Premium Accounts trade with 2/20 bps. Approving the integrator gives you 1/2 bps instead — you save money.
For Standard Accounts the approve is a small "thanks" contribution. For Premium Accounts it's a clear win-win.
Opt in (one-time, ~60 seconds, recommended browser flow):
lighter-mcp-approveA localhost web page opens; connect Metamask/Rabby; click Approve; sign the EIP-191 message in your wallet. Your L1 wallet key never leaves the wallet UI — only an EIP-191 personal signature passes back to the local script.
Revoke at any time:
lighter-mcp-approve --revokeSets the approval to zero fees. Or simpler — disable client-side without an on-chain change:
# In your MCP server env:
LIGHTER_NO_INTEGRATOR=trueWhen set, integrator params aren't even attached to your orders. Zero attribution, zero potential fee flow.
Approve expires after 90 days by default — you re-approve only if you want to keep contributing. No silent lock-in.
17 trading tools + get_status, get_signup_info, and how_to_approve_integrator diagnostics
Three credential tiers — install + try with no credentials, opt in to more as you go
Native on-chain SL/TP — survives client restarts
USDC-notional market orders for simple sizing; base-amount limit orders for precision
Multi-market — symbols auto-discovered from the order-book API
Sub-account-first design — API key signs for a sub-account; your main wallet stays cold
Server-side safety caps — max trade size, slippage limit, symbol allowlist
Per-market price/size encoding — handles all listed perpetuals correctly (BTC 1-decimal, NEAR 5-decimal, etc.)
The server picks one of three modes at startup based on which env vars are set. Higher modes are strictly opt-in.
Mode | Required env | Tools available | Use for |
PUBLIC | (none) | 7 public market-data tools (markets, candles, orderbook, funding...) | Trying it out, exploring Lighter data, building analytics |
READ |
| + 3 account-state tools (balance, positions) | Monitoring your account from Claude/Cursor |
TRADE | + | + 8 trading tools | Autonomous / assisted trading |
In TRADE mode you can demote to read-only at any time with LIGHTER_READ_ONLY=true — order-placement tools are then not even registered.
pip install 0xdegenmo-lighter-mcp
# For live trading you also need the git version of the Lighter SDK:
pip install --upgrade git+https://github.com/elliottech/lighter-python.git@main~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or
%APPDATA%\Claude\claude_desktop_config.json (Windows):
Minimal — PUBLIC mode (no Lighter account needed):
{
"mcpServers": {
"lighter": {
"command": "python",
"args": ["-m", "lighter_mcp"]
}
}
}Full — TRADE mode (sub-account API key required):
{
"mcpServers": {
"lighter": {
"command": "python",
"args": ["-m", "lighter_mcp"],
"env": {
"LIGHTER_URL": "https://mainnet.zklighter.elliot.ai",
"LIGHTER_ACCOUNT_INDEX": "<your-sub-account-index>",
"LIGHTER_PRIVATE_KEY": "<api-key-private-key>",
"LIGHTER_API_KEY_INDEX": "2",
"LIGHTER_MAX_QUOTE_USD": "100"
}
}
}
}Restart Claude Desktop. Try: "List my Lighter markets" (PUBLIC works) or "What's my balance?" (needs READ+).
Same command and args. Check your client's MCP server config for the exact format.
mcp_servers:
lighter:
command: "python"
args: ["-m", "lighter_mcp"]
env:
LIGHTER_URL: "https://mainnet.zklighter.elliot.ai"
LIGHTER_ACCOUNT_INDEX: "<sub>"
LIGHTER_PRIVATE_KEY: "<api-key-priv>"
LIGHTER_API_KEY_INDEX: "2"get_status — current mode, safety policy, integrator config (no secrets)
get_signup_info — Lighter signup URL + referral code (5% bonus for new users)
how_to_approve_integrator — instructions for opt-in / opt-out
list_markets, get_market(symbol) — market discovery
get_candles, get_ticker, get_orderbook, get_funding_rate — market data
LIGHTER_ACCOUNT_INDEX (Tier 2 — READ)get_balance — collateral / margin-in-use / available / asset_value
get_positions, get_position(symbol) — open positions
LIGHTER_PRIVATE_KEY (Tier 3 — TRADE)set_leverage(symbol, leverage, cross)
place_market_order(symbol, side, quote_amount_usd, reduce_only)
place_limit_order(symbol, side, base_amount, price)
place_stop_loss(symbol, side, base_amount, trigger_price) — on-chain, reduce-only
place_take_profit(symbol, side, base_amount, trigger_price) — on-chain, reduce-only
close_position(symbol)
cancel_order(order_id, symbol)
cancel_all_orders
This server signs transactions with whatever key you put in LIGHTER_PRIVATE_KEY. Treat that as the most sensitive value in the whole config.
Why you can trust this MCP (or audit it):
Fully open-source — every line of code lives at github.com/0xDegenMo/lighter-mcp. ~800 lines of Python total, readable in under 30 minutes.
Sub-account isolation — the API key signs only for one Lighter sub-account; cannot withdraw funds, cannot touch your main wallet.
Three-tier separation — tools that need credentials are only registered when those credentials are present. A PUBLIC-mode server cannot place trades even if asked.
Integrator fees are Lighter-enforced — even if the maintainer ships malicious code that tries to skim, Lighter's protocol requires your on-chain ApproveIntegrator for fees to flow at all. Without your signature, integrator params are inert.
Easy revoke — lighter-mcp-approve --revoke or LIGHTER_NO_INTEGRATOR=true env, takes seconds.
Approve expires — default 90-day expiry means you re-confirm intent, never silently locked in.
Wallet hygiene
Use a Lighter sub-account, not your main wallet. Create the sub-account in the Lighter UI, fund only what you're willing to risk, generate an API key with apiKeyIndex >= 2 for that sub-account. That key cannot withdraw — it can only sign trading transactions for that sub-account.
Never put your main wallet seed or main signing key in env vars. This MCP doesn't need it.
Treat LIGHTER_PRIVATE_KEY as a secret. Don't commit .env; don't paste into shared chats.
Server-side caps (enforced before the order leaves the process)
LIGHTER_MAX_QUOTE_USD (default 100) — opening trade size cap in USDC. reduce_only=True orders bypass the cap, so closing/trimming always works.
LIGHTER_MAX_SLIPPAGE (default 0.005 = 0.5%) — applied to market orders.
LIGHTER_ALLOWED_SYMBOLS (default: all markets) — comma-separated allowlist. If set, trades on any other symbol are refused server-side.
LIGHTER_API_KEY_INDEX < 2 — logged as a warning at startup. Indices 0/1 are typically reserved for the main account.
Operational notes
Logs (stderr) include the active mode and integrator config but never the private key (only first/last few chars in the rare case keys appear in error paths).
cancel_all_orders cancels across all markets in the sub-account. Use intentionally.
Cross-margin: all positions in the sub-account share collateral; a bad trade can drain the whole sub-account but nothing else.
If you fork this project, you can route fees to your own account:
LIGHTER_INTEGRATOR_ACCOUNT_INDEX=<your-account-index>
LIGHTER_INTEGRATOR_MAKER_FEE=<raw> # 100 = 1 bp
LIGHTER_INTEGRATOR_TAKER_FEE=<raw> # 200 = 2 bpsThen each install needs its own ApproveIntegrator for your account before fees flow.
Var | Tier | Default | Description |
| all | mainnet | API base URL |
| READ+ | (unset) | Sub-account index |
| TRADE | (unset) | API-key private key (sub-account, not main wallet) |
| TRADE |
| Index of the API key |
| any | (unset) | If |
| TRADE |
| Cap on opening trade size in USDC |
| TRADE |
| Max slippage fraction on market orders |
| TRADE | (unset) | Comma-separated symbol allowlist |
| any | (unset) | If |
| any |
| Override integrator account (forks) |
| any |
| Override maker fee (raw int) |
| any |
| Override taker fee (raw int) |
| any |
| Log level on stderr |
MIT
OHLCV candles for a market.
Args: symbol: e.g. 'HYPE', 'ETH' interval: minutes per candle — 1, 5, 15, 60, 240, or 1440 (1d) limit: number of candles back from now (max ~500)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| interval | No | 60 | |
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses max limit value and interval options, but does not mention rate limits, auth requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with no extraneous text. Uses a clean list structure for parameters, making it easy to parse.
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?
Has output schema so return format need not be described. Covers required parameters and gives usage examples. Lacks edge-case handling but adequate for a data retrieval 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?
Schema has 0% description coverage; description fully compensates by explaining each parameter: symbol examples, interval values and meaning, limit meaning with max constraint.
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 returns 'OHLCV candles for a market', and provides parameter details (symbol, interval, limit) that distinguish it from sibling tools like get_ticker or get_orderbook.
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?
Explains parameters with examples and constraints (max ~500 candles), but does not explicitly state when to use vs alternatives or when not to use. Implicit from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current funding rate and next funding timestamp for a perp market.
Funding occurs every 8h. Positive rate = longs pay shorts.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but the description discloses funding frequency (every 8h) and explains the meaning of positive rate. This provides useful behavioral context beyond a simple tool name.
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, both informative and concise. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return values (rate and timestamp) and basic mechanics, but lacks parameter explanation and error handling details. Adequate for a simple query tool but not fully 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?
Input schema has one required string parameter 'symbol' with no description. The tool description does not explain what symbol means, expected format, or examples. Schema coverage is 0%, and the description fails to compensate.
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 returns current funding rate and next funding timestamp for a perp market. It distinguishes from sibling tools like get_candles or get_orderbook, which serve different purposes.
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 versus alternatives. The description implies it's for funding rate queries, but lacks exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a single market by symbol (e.g. 'HYPE', 'ETH').
Returns None if the symbol is not listed.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it returns metadata and None on miss, but does not disclose read-only nature, permissions, or rate limits. Adequate for a simple lookup.
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. First states core purpose, second handles edge case. 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?
For a simple one-parameter tool with an output schema, the description covers purpose, usage, and error case. No need for additional details.
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?
Only one parameter (symbol) with 0% schema description coverage. Description adds examples ('e.g. HYPE, ETH'), providing some meaning beyond the schema's type-only definition, but could specify expected format.
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 'get', resource 'metadata for a single market', and the key parameter 'symbol'. Distinguishes from siblings like list_markets by focusing on a single market.
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 mentions behavior when symbol not found ('Returns None'). Lacks comparison to siblings (e.g., get_ticker), but context from sibling names provides some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top-N order book levels.
Returns {"bids": [[price, size], ...], "asks": [[price, size], ...]}.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| depth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only describes the output format. It does not disclose rate limits, authentication requirements, data freshness, or any side effects. The return structure alone is insufficient for behavioral 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?
The description is very short and to the point, but it sacrifices completeness. Every sentence earns its place, but the structure lacks a clear separation of purpose, parameters, and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description should cover symbol format, depth meaning, and usage context. It fails to do so, leaving significant gaps for an agent to make correct calls.
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 0%, and the description only implies the 'depth' parameter via 'Top-N'. The 'symbol' parameter is not explained at all (e.g., expected format, supported values). The output format illustration adds minimal context 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?
The description clearly states it returns top-N order book levels with a specific output format, distinguishing it from siblings like get_ticker or get_candles. However, it could be more explicit about the verb (e.g., 'retrieve' vs 'get') and the scope (e.g., 'current' or 'snapshot').
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 over others, such as get_ticker or get_candles. No mention of prerequisites, limitations, or alternatives, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Server diagnostics: current mode, safety policy, and integrator attribution.
Reveals no secrets — safe to call from any client. Use this to verify:
which tier the server is running in (PUBLIC / READ / TRADE)
active safety limits (max_quote_usd, max_slippage, allowed_symbols)
whether integrator/partner attribution is active and at what fee rates
Anyone curious about fees should call this tool — it's the authoritative answer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description proactively discloses that the tool 'reveals no secrets' and is 'safe to call from any client,' which is valuable behavioral transparency for a read-only diagnostic tool. It does not cover potential rate limits or response size, but these are minor given the tool's simplicity.
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 concise and well-structured, using bullet points to list the specific information returned. Every sentence serves a purpose, with no wasted words. It is front-loaded with the core 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?
Given the absence of annotations and an output schema, the description completely covers what the tool returns and why it should be used. It is fully adequate for an agent to understand what the tool does and when to invoke it.
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 tool has no parameters, so the input schema provides full coverage (100%). The description adds value by detailing what the response contains (tier, limits, fees), going beyond the schema to set expectations for the agent.
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 provides server diagnostics including current mode, safety policy, and integrator attribution. It uses specific verbs and resources, and implicitly distinguishes itself from sibling tools like get_market or get_ticker by focusing on server state rather than market data.
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 tells when to use the tool: to verify tier, safety limits, and integrator attribution. It also directly states 'Anyone curious about fees should call this tool — it's the authoritative answer,' providing clear guidance and an alternative to other fee-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current best bid / best ask / last price for a market.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states what data is returned, but does not disclose if the tool is read-only, requires authentication, handles invalid symbols, or any potential side effects.
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 front-loads the key information. It is appropriately sized for a simple tool, though a small amount of additional context could be added without harm.
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 and no annotations, the description should explain the return structure (e.g., data types, object format) and possible errors. It only vaguely states the fields without any structural details, leaving agents unsure of how to parse the result.
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 schema has 0% description coverage for the symbol parameter. The description only says 'for a market', which implies symbol is a market identifier but lacks format specifics or examples, adding minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'Current best bid / best ask / last price' for a market, which is specific and distinguishes it from siblings like get_orderbook (full order book) or get_candles (historical data).
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 when current market prices are needed, but does not explicitly state when to use this tool versus alternatives like get_orderbook or get_market, nor does it mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to opt in to sending integrator fees to the lighter-mcp maintainer.
Use this if a user asks how to support the project, how integrator attribution works in practice, or how to make fees actually flow.
Returns instructions for both the browser-based flow (recommended — wallet UI handles the L1 signature, no private key exposure) and the CLI fallback for power users. No call is made to Lighter from this tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: 'No call is made to Lighter' (safe, no side effects) and 'Returns instructions for both the browser-based flow... and CLI fallback.' This fully informs the agent.
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?
Concise three-sentence description that is front-loaded with purpose and usage. Every sentence adds value with 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?
For a zero-parameter, no-annotation, no-output-schema tool, the description covers purpose, usage scenarios, behavioral traits, and output nature completely. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% automatically. The description adds no parameter info because none exist. Baseline score of 4 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's purpose: providing instructions for opting into sending integrator fees to the maintainer. It distinguishes itself from sibling market tools by focusing on support/attribution queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Use this if a user asks how to support the project, how integrator attribution works in practice, or how to make fees actually flow.' Provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tradeable perpetual markets on Lighter.
Returns symbol, market_index, min_base_amount, min_quote_amount, price_tick, size_tick, max_leverage for each market.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the read-only nature and lists the exact return fields (symbol, market_index, etc.). It does not mention pagination or rate limits, but for a simple list with no parameters, the behavioral description is adequate.
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 extremely concise: two sentences. The first sentence states the purpose, the second lists return fields. 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?
Given the tool's simplicity (0 parameters, no required input) and the presence of an output schema (fields listed in description), the description fully covers what an agent needs to know: what it does and what it returns. Sibling context is provided by the environment.
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 no parameters (0 params, 100% schema coverage). The description adds no parameter info since none exist, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tradeable perpetual markets on Lighter' with a specific verb and resource. It distinguishes itself from siblings like 'get_market' (singular) by indicating it returns all markets.
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 when needing a list of all markets, but does not explicitly state when to use it vs alternatives like 'get_market' for a single market. No exclusions or when-not-to-use guidance is provided.
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.
v0.1.1get_candlesget_funding_rateget_marketget_orderbookget_statusget_tickerhow_to_approve_integratorlist_marketsEach tool targets a distinct piece of information or action: candles, funding rate, market metadata, order book, server status, ticker, integrator instructions, and market listing. No two tools have overlapping responsibilities.
Most tools follow a 'get_' prefix, but 'list_markets' uses 'list_' and 'how_to_approve_integrator' is a descriptive phrase rather than a standard verb-noun pattern. This mix of conventions reduces consistency.
With 8 tools, the set feels appropriately scoped for a market data and server information provider. It is neither too sparse nor bloated for its apparent purpose.
The server covers market data retrieval well (candles, orderbook, ticker, funding rate) and adds list/meta tools, but lacks any trading or account management tools. Given the 'TRADE' tier mentioned in get_status, this gap is notable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Real-time & historical Hyperliquid/Lighter: L4/L2/L3, fills, funding, OI, liquidations, candles
No-KYC managed MCP for AI agents: sandboxed TypeScript trading SDK, isolated sub-accounts, futures.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xDegenMo/lighter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
