Skip to main content
Glama
Sign In
litewrite-mcp-server

litewrite-mcp-server

by KevinKwank
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Push Local Changes to Litewrite

litewrite_push
DestructiveIdempotent

Upload local working-copy changes back to Litewrite in git-push style, syncing new, changed, and deleted text files and refreshing the manifest.

Instructions

Upload local working-copy changes back to Litewrite (git-push style).

Compares the local mirror (~/.litewrite-mcp/) against the last manifest: new/changed text files are uploaded, removed local files are deleted on the server, and the manifest is refreshed.

Use litewrite_status first to see what will change.

Args:

  • projectId (string, required): The project id.

Returns what was uploaded and deleted.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>"
    },
    "name": "litewrite_push"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectIdYesThe Litewrite project id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is covered. The description adds real value beyond them by spelling out the mechanism: new/changed files uploaded, removed local files deleted server-side, and the manifest refreshed — an agent learns precisely what gets destroyed and why the operation is idempotent.

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-loads the core action and mechanism, then the prerequisite, then args and return. Every sentence earns its place, though the args block restates the 100%-covered schema field and is slightly redundant.

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?

For a single-parameter mutation with no output schema, the description covers the mechanism, the deletion side effect, the prerequisite tool, and a rough outline of the return value. Missing only edge-case behavior such as conflict resolution, which is a minor gap given the annotations.

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

Parameters3/5

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

Schema description coverage is 100% for the single projectId parameter, so the schema already carries its meaning. The description merely restates 'projectId (string, required): The project id', adding no format or source detail beyond it, which pins this at the baseline of 3.

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 — upload local working-copy changes back to Litewrite — and the 'git-push style' analogy plus the explicit mirror-vs-manifest comparison distinguish it from siblings like litewrite_pull and litewrite_write_file. An agent can tell what this does 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?

Explicitly routes the agent to litewrite_status first to preview changes, which is a concrete prerequisite. It stops short of naming when NOT to use it (e.g. versus litewrite_upload_file for single-file uploads), so it is clear context without full alternative coverage.

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