lampa-mcp-server

Overview Schema Source Related Servers Discussions Admin

Draft a Lampa unified diff

draft_patch

Read-onlyIdempotent

Generates suggested unified diffs for requested changes to existing files, returning them as text without writing the repository. Use it to review patch hunks before applying edits manually.

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) and is capped at the first 5 entries for diff generation even if more are passed (the 'Target files' summary section still lists up to 6); 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

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

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

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds critical operational details: output is text-only, `target_files` fully overrides inference and is never combined with it, inference is capped at 5 files even if more are passed, missing files produce a note rather than aborting, and hunks are suggestions that should be re-checked before applying.

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?

The description is dense but front-loaded with the key constraint ('text only — does not write the repository') and then layers useful caveats. Most sentences carry operational value, though the parenthetical cap details and the 'TODO' phrasing are slightly awkward and could be tightened.

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?

An output schema exists, so return format explanation is unnecessary, and the description covers the remaining decision-critical behavior: non-writing nature, precedence of `target_files`, inference limits, missing-file handling, and non-guaranteed patch applicability. Nothing substantial is missing for correct invocation.

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 the schema already documents each parameter. The description still adds meaningful semantics beyond the schema: `target_files` fully overrides inference rather than supplementing it, is capped at the first 5 entries for diff generation even if more are passed, and the summary section lists up to 6. It also explicitly characterizes inference without `plan_context` as weaker.

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 ('Returns ... unified diffs as text only') and immediately clarifies it does not write the repository. It explicitly distinguishes itself from plan_change and scaffold_plugin, so an agent can select it without opening sibling schemas.

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 (`plan_change`, `scaffold_plugin`) and explains the selection conditions: plan_change produces plans, scaffold_plugin emits new-plugin boilerplate, and draft_patch patches existing files with concrete hunks. It also recommends pasting `plan_context` from `plan_change` and explains when `target_files` should be supplied.

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

Deploy Server