lampa-mcp-server

Overview Schema Source Related Servers Discussions Admin

Draft a Lampa unified diff

draft_patch

Read-onlyIdempotent

Generate unified diff hunks as text-only TODO patches for existing files, using a plan to target files. Reports missing files instead of aborting, allowing review before applying.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`request`	Yes	The change to implement.
`plan_context`	No	Optional paste of plan_change output. Recommended; the tool still runs without it.
`target_files`	No	Repo-relative files to patch. If omitted, up to 5 files are inferred from request (weaker than plan_context).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`markdown`	Yes	Human-readable markdown report. Always present, including empty-result cases. Does not write files.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.7.0Sep 4, 2026

changedInput schema / properties / plan_context / description

Previous value: -"Paste the output of plan_change here for best results."New value: +"Optional paste of plan_change output. Recommended; the tool still runs without it."

changedInput schema / properties / target_files / description

Previous value: -"Files to focus on (repo-relative paths). Inferred from request if omitted."New value: +"Repo-relative files to patch. If omitted, up to 5 files are inferred from request (weaker than plan_context)."

Changed4 schema fields changedv1.6.0Sep 4, 2026

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 / plan_context / description

Previous value: -"Paste the output of plan_feature_change here for best results."New value: +"Paste the output of plan_change here for best results."

changedInput schema / properties / target_files / description

Previous value: -"Files to focus on (repo-relative paths)."New value: +"Files to focus on (repo-relative paths). Inferred from request if omitted."

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"
+}

First observedv1.0.0Jun 23, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare the tool non-destructive and idempotent, but the description adds essential behavioral context: it does not write the repo, missing files produce a 'File not found' note rather than aborting, and hunks are suggested not guaranteed to apply. No contradiction with annotations exists.

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?

The description is information-dense but every sentence carries unique value: core behavior, sibling contrasts, parameter override semantics, error behavior, and a safety caution. The most important fact (no repo writes) is 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 an output schema, the description need not explain return values; it covers error handling, inference behavior, application risk, and proper usage with plan_context. The calls to read_source for verification complete the decision context for the agent.

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 adds significant meaning beyond the schema: target_files fully overrides inference and the two are never combined, inference is limited to up to 5 files, and plan_context strengthens results from request alone. This clearly explains parameter interplay and trade-offs.

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 opens with a precise verb and object: 'Returns TODO unified diffs as text only — does not write the repository.' This clearly identifies the tool's function and scope while explicitly contrasting it with plan_change and scaffold_plugin, so an agent can distinguish it from siblings without opening them.

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 gives concrete when-to-use guidance: 'Best with plan_context pasted from plan_change' and differentiates behavior from plan_change (invents concrete diff hunks) and scaffold_plugin (patches existing files rather than emitting boilerplate). It also warns to re-check against read_source before applying, which clarifies post-call workflow.

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

Deploy Server