open-mcp-apps

Overview Schema Source Related Servers Discussions Admin

Edit app source

edit_app

Idempotent

Apply atomic range or exact-string edits to an existing app, avoiding full-source rewrites while preserving its manifest and skill slots.

Instructions

Surgical edits to an app WITHOUT round-tripping the whole source. Two edit forms, mixable: RANGE {offset, length, expect_hash, new_string} replaces a span you read with get_app (cheapest — echo the window's offset/returned/hash, no anchor text travels); STRING {old_string, new_string} replaces an exact-once match (or set replace_all). Range offsets always address the expected_version document and must not overlap; string edits apply after ranges, in order. All edits apply together, or nothing applies. The manifest and skill slots are kept.

Input Schema

TableJSON Schema

Name	Required	Description
`app`	Yes	app name (this tool says `app`; save_app and get_app say `name`)
`actor`	No
`edits`	Yes	each item is RANGE (offset+length+expect_hash) or STRING (old_string)
`command_id`	Yes	idempotency key — generate a fresh uuid per action
`expected_version`	Yes	REQUIRED — the version the edits were authored against (from get_app)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`eot`	No
`name`	No
`note`	No
`size`	No
`reason`	No
`applied`	No
`created`	No
`version`	No
`prev_size`	No
`manifest_action`	No
`expected_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.0Sep 5, 2026
- removedOutput schema / properties / prev_size / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / prev_size / type
```
Added value: +[
+  "number",
+  "null"
+]
```
First observedv0.5.7Aug 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds real behavior beyond annotations: atomic apply ('All edits apply together, or nothing applies'), non-overlap and ordering constraints, version-pinned offsets, and that manifest/skill slots are preserved. This complements the idempotentHint/non-destructive annotations with mutation-specific rules an agent needs.

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 purpose and the two forms, then constraints, with each sentence carrying information. It is dense and slightly packed, but nothing is redundant or wasteful.

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?

For a non-obvious multi-form edit tool, it covers atomicity, ordering, version pinning, and preserved slots, and an output schema exists so return values need not be described. Nothing an agent needs to call it correctly is missing.

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?

Goes well beyond the 80%-covered schema by defining the RANGE vs STRING form semantics, what offset/length/expect_hash are read from (get_app's window), that offsets address the expected_version document, and that string edits apply after ranges in order. That is substantive meaning 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?

States a specific verb (edit) and resource (app source) plus the mechanism ('surgical edits ... WITHOUT round-tripping the whole source'), which distinguishes it from a full-save sibling like save_app. An agent can tell what this does and what it avoids without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains when each edit form applies: RANGE is 'cheapest' and echoes get_app's offset/returned/hash, STRING is for an exact-once match with optional replace_all. It also notes mixing and ordering. It stops short of explicitly contrasting with save_app for whole-file rewrites, so it is clear context rather than full when/when-not guidance.

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