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

Locate repo-relative file paths by filename, Lampa feature, UI component, stylesheet, or test spec. This path finder matches names and paths, not 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 is honored only when mode=name; passing it with mode=feature/ui/styles/tests is silently ignored rather than erroring, so those modes always return every matching extension. Empty matches → list, not an error.

Input 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

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.5/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the bar is lower, yet the description still adds real behavioral detail: `mode=ui`/`styles` attach up to 20/15 content hits, `ext` is silently ignored rather than erroring in non-name modes, and empty matches return an empty list rather than an error. These are non-obvious behaviors an agent would otherwise discover by failure.

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

Conciseness4/5

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

Front-loaded with the purpose and sibling contrast, then examples, then edge cases; every sentence contributes. It loses a point for mild overlap with the schema, which already states that `ext` applies only to `mode=name`.

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

Completeness4/5

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

An output schema exists so return values need no explanation, and the description covers mode semantics and failure behavior. Minor gap: it does not say whether `mode=name` results are capped or ordered the way `ui`/`styles` content hits are, so the agent cannot predict result volume in the default mode.

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?

Schema coverage is 100%, so a 3 is the baseline, but the description goes beyond the schema by giving concrete `query` examples per mode, noting the built-in feature map, and explaining the silent-ignore semantics of `ext` (the schema says 'ignored otherwise' but not that it will not error). That is meaningful added semantics rather than restatement.

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?

States a specific verb and resource ('Locate repo-relative paths') plus the dimensions it searches (filename, feature, UI component, stylesheet, spec) and immediately frames itself as 'a path finder, not content grep.' It explicitly contrasts with the siblings `search_code` and `read_source`, so an agent can discriminate without opening a schema.

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?

Names alternatives and the conditions that select them: use `search_code` for content grep, `read_source` for file bytes, this tool for name/path lookup. It also supplies per-mode usage examples (`mode=feature query='player'`, `mode=name query='full' ext='.js'`), leaving little to inference.

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