Skip to main content
Glama
pavelpikta

lampa-mcp-server

by pavelpikta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Validate Lampa plugin, grep, i18n, or build

validate_code
Read-onlyIdempotent

Runs lint, convention, grep, i18n, and build-command checks on Lampa plugins or snapshots to surface pitfalls, TODOs, missing keys, and command hints without executing code.

Instructions

Run checks and hints, not catalogs (list_catalog) and not edit plans (plan_change); prefer analyze_plugin for a descriptive report and trace_symbol for dependency graphs — this tool only scores/lints/hints, it never describes structure. mode=plugin scores a plugin against official pitfalls (target required); grep scans the snapshot for TODOs/console.log/undefined/lang/hardcoded HTML (not a shell, no code execution); i18n looks up key or, if omitted, coverage vs en.js; build returns the npm/gulp command for a goal as text — it never runs it. Example: mode=grep checks=['todos','console_logs']; mode=i18n key='player_playlist' or omit key for a full coverage table. checks only applies to mode=grep (default: all five checks); show_missing only applies to i18n coverage and is ignored once key is set; goal only applies to mode=build; target is required only for mode=plugin (folder or JS path) — missing plugin → error listing folders, missing target for mode=plugin → error naming the requirement.

Input Schema

NameRequiredDescriptionDefault
keyNoFor mode=i18n: specific translation key. Omit for coverage report.
goalNoFor mode=build: which command to hint (does not execute). Default build.
modeYesplugin=convention score; grep=snapshot quality scans (not a shell); i18n=keys/coverage; build=command hint (does not run npm/gulp).
checksNoFor mode=grep: which checks. Defaults to all.
targetNoRequired for mode=plugin: plugin folder name or repo-relative JS path. Missing plugin → error listing folders.
show_missingNoFor mode=i18n coverage: include missing/extra key lists. Default true.

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 / goal / description
      Previous value: -"For mode=build: which command to hint. Default build."New value: +"For mode=build: which command to hint (does not execute). Default build."
    • changedInput schema / properties / mode / description
      Previous value: -"plugin=convention score; grep=quality scans; i18n=keys/coverage; build=command hint."New value: +"plugin=convention score; grep=snapshot quality scans (not a shell); i18n=keys/coverage; build=command hint (does not run npm/gulp)."
    • changedInput schema / properties / target / description
      Previous value: -"For mode=plugin: plugin folder or repo-relative JS path."New value: +"Required for mode=plugin: plugin folder name or repo-relative JS path. Missing plugin → error listing folders."
  2. Addedv1.6.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: no shell and no code execution in `grep`, `build` never runs npm/gulp, and specific error semantics (missing plugin lists folders; missing `target` errors naming the requirement). These are exactly the side-effect and failure details annotations cannot express.

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?

Content is front-loaded with purpose and sibling routing before mode details, and every clause carries information. However the em-dash run-ons and stacked parentheticals make some sentences dense enough to require re-reading.

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?

With an output schema present, annotations covering the safety profile, and 100% schema coverage, the description supplies the remaining missing layer: mode selection, parameter conditionality, and error behavior. Nothing an agent needs to invoke any of the four modes correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond per-field docs by stating cross-parameter conditionality: `checks` applies only to grep (default all five), `show_missing` only to i18n coverage and is ignored once `key` is set, `goal` only to build, `target` required only for plugin. That conditional logic is not derivable from the schema alone.

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 opening sentence states a specific verb and resource ("Run checks and hints") and explicitly negates the two most confusable siblings (`list_catalog`, `plan_change`) while naming the better alternatives `analyze_plugin` and `trace_symbol`. An agent can pick this tool over any sibling 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?

It gives explicit when-to-use for each of the four modes (`plugin` scores pitfalls, `grep` scans snapshot, `i18n` looks up key/coverage, `build` returns a command) plus explicit when-not-to-use by routing descriptive/graph work to `analyze_plugin` and `trace_symbol`. Two concrete invocation examples are supplied.

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