lightning-fm-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LFM_BLOSSOM_URL | No | Blossom server audio/image hashes resolve against. | https://media.lightning.fm |
| LFM_CACHE_TTL_MS | No | How long a fetched snapshot is reused before the next tool call re-queries the relays. | 60000 |
| LFM_NOSTR_RELAYS | No | Comma-separated relay URLs to query. Only add a relay here if it gates writes the way relay.lightning.fm does. | wss://relay.lightning.fm |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_catalogA | Search or browse Lightning FM's Nostr-native music catalog (kind 31337 track events, fetched live from wss://relay.lightning.fm). Every result is signed by the artist's own Nostr key — this is the canonical catalog, not a curated subset. Leave all filters empty to browse the whole catalog, newest first. |
| get_artistA | Look up an artist by display name or Nostr pubkey (hex or npub) and return their profile plus every track they have published to Lightning FM. |
| get_now_playingA | Read the current live activity (NIP-53, kind 30311) Lightning FM publishes on every track change: the track currently on air, the stream URL, and station status. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a distinct purpose: searching the catalog, looking up an artist, and reading live now-playing data. There is no practical overlap in what an agent would select them for.
All three tools follow a clear verb_noun convention: search_catalog, get_artist, get_now_playing. The naming pattern is predictable and consistent.
Three tools is a tight, well-scoped set for a read-only music catalog API. Each tool covers a distinct high-level user need without unnecessary bloat.
The core domain is covered: catalog browsing/search, artist lookup with tracks, and live playback status. A direct track-by-ID detail lookup is a minor gap, but the other tools can work around it through search or artist queries.