Skip to main content
Glama
pavelpikta

lampa-mcp-server

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LAMPA_REPO_PATHYesThe absolute path to the local Lampa source repository checkout

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

CapabilityDetails
tools
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
summarize_repoA

Summarize the Lampa snapshot — commit metadata, top-level folders, plugins, entrypoints, and npm scripts — for first-session orientation. Do not use it to read bytes (read_source), search contents (search_code), or list files by name (find_files). Omit subfolder for the compact overview; subfolder='src/components' adds a recursive JS/TS-only listing under that prefix (an empty result is a valid 'no JS/TS files here' answer, not an error) on top of the same overview; unknown folder or missing repo → error; stdio needs LAMPA_REPO_PATH and Worker PAT is transport-only (no extra scopes or rate limits beyond GitHub's).

search_codeA

Search Lampa source contents for a literal or regex and return path:line plus a preview. Use this when you know a symbol or pattern; do not use it to list files by name (find_files), dump catalogs (list_catalog), or read one known path (read_source). Defaults: literal, case-sensitive match (regex=true compiles RegExp exactly as written — no implicit i); extensions .js/.ts/.css/.scss/.html/.json unless globs is set. prefix narrows which folder is walked and globs still filters extensions within it — the two combine rather than override each other. Limits: 100 hits total, 5 per file, 200-char preview per line (fixed, to keep results small enough for one call); invalid regex → error naming the bad pattern; no matches → empty markdown, not an error.

find_filesA

Locate repo-relative paths by filename, Lampa feature, UI component, stylesheet, or spec — a path finder, not content grep. Unlike search_code, this matches names/paths (except mode=ui/styles, which also attach up to 20/15 content hits); unlike read_source, it does not return file bytes. Example: mode=feature query='player' uses the built-in feature map; mode=name query='full' ext='.js' filters by extension (ext ignored unless mode=name); empty matches → list, not an error.

read_sourceA

Read bytes from one known path: a repo file, a src/core module, or a src/templates template. Unlike search_code/find_files, this returns contents of a single target — do not dump catalogs (list_catalog). Full files truncate at max_lines (default 300); pass start_line+end_line (1-based, inclusive) for a range (ignores max_lines); kind=file requires file; omit file with kind=core/template to list; missing path → error.

resolve_edit_pathA

Map a change kind (lang, sass, template, component, plugin, core, interaction, settings) to the authoritative src/ or plugins/ path and list generated public/build copies to avoid. Call this before plan_change or draft_patch; unlike find_files, this is a fixed landmark table look-up (no filesystem walk, no content search), not a search. Example: kind=plugin name='tracks' returns plugins/tracks specifically, vs kind=lang name='en' returns src/lang/en.js; an unrecognized name does not fail — it falls back to the kind's default authoritative/avoid paths so the call always returns something actionable.

list_catalogA

Dump one static catalog from the Lampa snapshot per call. Not a query (search_code), not a single-symbol walk (trace_symbol), not written docs (explain_docs), and not a live CUB client (guide_cub). scope applies only to api_surface/events/storage (default all); detail=true only affects events; query filters within the chosen topic — never a repo-wide search. Example: topic=events query='player' detail=true. Empty catalog → markdown, not an error; on R2, full-tree events/storage need a prebuilt index — pass query or a narrower topic (e.g. maker, socket, flags, content_rows, favorites, mirrors) if the index is missing.

analyze_pluginA

Single-call report for one plugins/<name> folder: files, Lampa.* usage, Listener follow/send, settings, CSS, and an entry preview truncated to ~30 lines, plus how Lampa loads plugins (src/core/plugins.js). Unlike list_catalog this is scoped to one plugin, unlike trace_symbol it does not follow a single event/file across the repo, unlike validate_code it does not score conventions. Entry file is chosen as main.js, else <plugin>.js, else the first .js file found — plugin itself must be the case-sensitive directory name (e.g. online, iptv), not a manifest id; omit it for load-path-only output; an unknown folder errors and lists available folders instead of guessing.

trace_symbolA

Follow one event, component, file, or provider through the snapshot graph — not a full catalog (list_catalog) and not raw grep (search_code). Examples: mode=event target=app; lifecycle target=src/components/full.js; deps a file path; upgrade a repo-relative file path (not an API name); omit target only for api_calls (optional target is a provider keyword). Missing target otherwise → error; unknown event → markdown note (not a crash); deps reverse-refs cap at 20.

plan_changeA

Generate a step-by-step implementation plan with inferred targets, a reverse-ref sample, and coupling risks for a Lampa change. Call this before draft_patch; unlike draft_patch it does not invent diffs, unlike trace_symbol it covers a whole request rather than one file/event, unlike scaffold_plugin it plans edits to existing code. request='add a sleep timer' + scope_hint='player' concatenates into feature inference; empty inference still returns a plan (not an error). Snapshot-only — does not execute or write; heuristic — not a guarantee; affected-surface list caps at ~12 files.

draft_patchA

Returns TODO unified diffs as text only — does not write the repository. Best with plan_context pasted from plan_change; unlike plan_change, this invents concrete diff hunks; unlike scaffold_plugin, it patches existing files rather than emitting new-plugin boilerplate. target_files, when given, fully overrides inference (the two are never combined); without it, up to 5 files are inferred from request alone, which is weaker than passing plan_context's target list explicitly. Missing files get a 'File not found' note instead of aborting the whole call; the @@ hunks are suggested, not guaranteed to apply — always re-check against read_source before applying by hand.

scaffold_pluginA

Returns markdown only; does not write the repository — not a patch against existing files (draft_patch). kind=plugin emits a full main.js scaffold: requires plugin_name + description; plugin_kind (screen default | player | context-menu | settings-only) applies only here. kind=setting emits a SettingsApi registration snippet: requires key + label + type (type=toggle aliases trigger). kind=hook emits the best-matching Listener/Player hook: requires trigger. A missing required combo for the chosen kind errors instead of returning a partial scaffold. Follow up with validate_code mode=plugin on the result.

validate_codeA

Run checks and hints, not catalogs (list_catalog) and not edit plans (plan_change). mode=plugin scores a plugin against official pitfalls; grep scans the snapshot for TODOs/console.log/undefined/lang/hardcoded HTML (not a shell); i18n looks up key or, if omitted, coverage vs en.js; build returns the npm/gulp command for a goal — it does not run it. checks only for mode=grep (default all); show_missing only for i18n coverage (ignored when key is set); goal only for mode=build; target is required for mode=plugin (folder or JS path); missing plugin → error listing folders.

explain_docsA

Read written Lampa guides: official plugin chapters (mode=plugin_docs), a core development pattern with live snippets (mode=pattern), or gulp/npm packaging targets (mode=packaging). Not a live API catalog (list_catalog) and not grep (search_code). Example: chapter=pitfalls vs query='SettingsApi' when chapter is omitted; omit both for the TOC; lang is en (default) or ru; pattern requires the pattern enum; unknown chapter → error listing known ids. Snapshot-only; packaging reads gulpfile.js / package scripts — it does not execute gulp or npm.

guide_cubA

Document how Lampa talks to CUB from source — this makes no network calls of its own (pure snapshot read), and is not a substitute for cub.rip/developer. Unlike list_catalog topic=mirrors/socket, this is CUB-specific. topic=catalog lists REST paths (category/search filter the catalog only, no effect on other topics); endpoint requires path (e.g. bookmarks/dump) and ignores category/search; auth reads auth_focus only (device/add, headers, Permit, Premium, mirrors); models reads model only (bookmark/timeline/favorite shapes); sync takes no parameters and maps dump/changelog/WebSocket; timeline_hash reads example only and explains Utils.hash.

guide_external_apiA

Document the real-world content/ratings/torrent-indexer/media-server APIs that Lampa plugins call — TMDB, KinoPoisk (PoiskKino + Unofficial), Alloha, MDBList, Jackett/Prowlarr/JacRed, TorrServer, Jellyfin, TheIntroDB, and the CORS-proxy pattern that fronts them. This is curated from the separate lampa-plugins repository, not the Lampa app source — unlike guide_cub (Lampa→CUB backend only) and unlike list_catalog (Lampa's own API/event/storage surface).\nNever returns secret values (API keys, tokens, passwords) — only provider identity, auth mechanism, and the Lampa.Storage key names a plugin reads credentials from.\ntopic=providers lists all providers (search filters by id/name/category/description); provider_detail requires provider; proxy_pattern takes no parameters and explains the shared Worker-proxy design once for all providers.

guide_plugin_catalogA

Document how the separate lampa-plugins repository turns plugin source files into the live catalog agents install into Lampa: the extension.json/plugin-manifest.json schema, the obfuscation presets, Cloudflare Pages Functions routing, and a step-by-step publishing checklist. Curated from that repo's scripts/ and functions/, not from the Lampa app source — unlike validate_code (lints one plugin's code against Lampa conventions) and scaffold_plugin (emits new-plugin boilerplate text), this tool covers packaging and distribution once the plugin already works.\nEach topic takes no other parameters and returns a fixed reference document — it does not read this repo's snapshot and never writes files.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
repo-overviewHigh-level repo structure and entrypoints.
repo-scriptsNPM scripts from package.json.
docs-indexOfficial Lampa plugin-guide table of contents (docs/en). Falls back to generated JSDoc if plugin docs are missing.
settings-catalogAll settings registrations found in the repo.
api-integrationsAll external API call sites found in the repo.
cub-lampa-apiCUB API endpoints catalog extracted from Lampa source.
lampa-landmarksOrdered landmark files agents should read first when working on Lampa (roles included).
lampa-edit-rulesWhat to edit vs avoid (src/plugins vs public/build). Prevents agents from changing generated copies.
lampa-api-surfaceKeys exported on window.Lampa from src/app.js initClass (plugin-visible API).
lampa-plugin-guideOfficial Lampa plugin development guide TOC, bootstrap snippet, and window.Lampa cheatsheet (docs/en).
lampa-pitfallsOfficial plugin pitfalls (docs/en/11-pitfalls.md) — anti-patterns not to emit.
lampa-eventsCondensed plugin event catalog (Listener, Player, PlayerVideo, Storage, Favorite, Keypad).

TDQS

A4.8/5.0

Scored across 16 tools

Disambiguation5/5

Every tool has a clearly distinct role: overview, content search, path lookup, file read, edit-path resolution, catalog dump, plugin analysis, symbol tracing, planning, patching, scaffolding, validation, or a specific documentation guide. The descriptions actively cross-reference what each tool should not be used for, making misselection unlikely.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern, such as summarize_repo, search_code, find_files, draft_patch, and validate_code. The guide_* and explain_* prefixes create recognizable subfamilies without breaking the overall naming convention.

Tool Count4/5

At 16 tools, the surface is slightly above the ideal 3–15 range, but each tool contributes to the snapshot-inspection and plugin-development workflow. The documentation guides could theoretically be consolidated, but their distinct topics make the count acceptable.

Completeness5/5

The tool set covers the full inspection-to-planning lifecycle: orient, search, read, locate, trace, catalog, plan, patch, scaffold, validate, and consult documentation. Write and execute operations are intentionally excluded as snapshot-only behavior, so the surface has no dead ends for its stated purpose.

Maintenance

ActivityActive
ResponsivenessNo issues