Skip to main content
Glama
pavelpikta

lampa-mcp-server

by pavelpikta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Find Lampa files by name or feature

find_files
Read-onlyIdempotent

Find repository file paths by filename, feature, UI component, stylesheet, or spec. Pick a mode to narrow results to the relevant Lampa source files without searching file contents.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
extNoFor mode=name only: extension filter, e.g. '.js' or '.scss'. Ignored otherwise.
modeNoname (default)=filename substring; feature=built-in Lampa feature map + filename; ui=templates/components (+ up to 20 content hits); styles=css/scss (+ up to 15 content hits); tests=spec files.
queryYesFilename substring (mode=name), feature name (mode=feature, e.g. player/catalog/iptv), UI component, style module, or spec keyword.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
markdownYesHuman-readable markdown report. Always present, including empty-result cases. Does not write files.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.0
    • changedInput schema / properties / ext / description
      Previous value: -"For mode=name only: extension filter, e.g. '.js' or '.scss'."New value: +"For mode=name only: extension filter, e.g. '.js' or '.scss'. Ignored otherwise."
    • changedInput schema / properties / mode / description
      Previous value: -"name (default)=filename; feature=Lampa feature map; ui=templates/components; styles=css/scss; tests=spec files."New value: +"name (default)=filename substring; feature=built-in Lampa feature map + filename; ui=templates/components (+ up to 20 content hits); styles=css/scss (+ up to 15 content hits); tests=spec files."
    • changedInput schema / properties / query / description
      Previous value: -"Filename substring, feature name, UI component, style module, or spec keyword depending on mode."New value: +"Filename substring (mode=name), feature name (mode=feature, e.g. player/catalog/iptv), UI component, style module, or spec keyword."
  2. Changed7 schema fields changedv1.6.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / ext / description
      Previous value: -"File extension filter, e.g. '.js', '.scss'."New value: +"For mode=name only: extension filter, e.g. '.js' or '.scss'."
    • addedInput schema / properties / mode
      Added value: +{
+  "description": "name (default)=filename; feature=Lampa feature map; ui=templates/components; styles=css/scss; tests=spec files.",
+  "enum": [
+    "name",
+    "feature",
+    "ui",
+    "styles",
+    "tests"
+  ],
+  "type": "string"
+}
    • removedInput schema / properties / pattern
      Removed value: -{
-  "description": "Substring or glob pattern to match against file names.",
-  "type": "string"
-}
    • addedInput schema / properties / query
      Added value: +{
+  "description": "Filename substring, feature name, UI component, style module, or spec keyword depending on mode.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "pattern"
-]New value: +[
+  "query"
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "markdown": {
+      "description": "Human-readable markdown report. Always present, including empty-result cases. Does not write files.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "markdown"
+  ],
+  "type": "object"
+}
  3. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already signal read-only, idempotent, non-destructive behavior, and the description adds meaningful runtime behavior beyond them: content-hit limits for ui/styles modes, no file bytes returned, ext being ignored outside mode=name, and empty-match handling. This gives an accurate model of what the tool will actually do.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Every sentence earns its place: the first defines scope, the second differentiates from siblings, the third gives two concrete usage examples and a failure-mode note. Dense but highly informative, with the most important scoping information front-loaded.

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

Completeness5/5

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

Given rich annotations, a complete input schema, an output schema, and explicit sibling differentiation, the description covers everything needed for correct selection and invocation. It explains edge cases, mode-specific behavior, and return expectations sufficiently.

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?

Input schema coverage is 100%, so the baseline is 3. The description adds value with concrete examples tying query/mode/ext together and clarifies the built-in feature map for mode=feature. The schema already documents the per-mode behavior, but the examples and constraints improve usability.

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 states a clear, specific verb ('Locate') and resource ('repo-relative paths') and immediately distinguishes the tool from search_code and read_source by saying what it matches and what it does not return. The modal examples make each mode's purpose explicit.

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 contrasts the tool with search_code ('matches names/paths... not content grep') and read_source ('does not return file bytes'), giving an agent clear routing criteria. It also explains when ext applies, how mode=feature behaves, and notes that empty matches return a list rather than an error.

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

Deploy Server

Other Tools