Gemmein

Add a file to a site draft

site_put_file

DestructiveIdempotent

Puts one file into a site draft (draftId from site_draft): path is relative to the site's root (index.html, assets/app.js); no leading "/"; no empty, "." or ".." parts; letters, digits and . _ - ~ only (also ! $ & ' ( ) * + , ; = : @) — no spaces, ?, #, % or backslashes; at most 300 characters; not under __gemmein/ (Gemmein's own); a secret-shaped file or a dot-file (.env .env.* *.env *.pem .key .p12 .pfx id_rsa id_ed25519 .npmrc .git/ .) is refused; content is the file's text, or base64 with encoding "base64" for an image or a font. A file already in the draft at that path is replaced; site_read returns the current contents of a file to change before it is put back. One file per call, and one call carries up to 1 MB (a base64 file up to about 750 KB); a bigger file goes through npx gemmein publish from a computer. A site holds up to 2,000 files and 50 MiB. Nothing is served until site_publish.

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": {
      "draftId": "<draftId>",
      "path": "<path>",
      "content": "<content>"
    },
    "name": "site_put_file"
  }
}

Input Schema

Name	Required	Description
`path`	Yes	relative to the site's root, like index.html or assets/app.js
`content`	Yes	the file's text, or base64 with encoding "base64"
`draftId`	Yes
`encoding`	No	default text
`contentType`	No	optional — read from the extension when left out

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare destructiveHint/idempotentHint, and the description adds substantial context beyond them: secret-shaped and dot-file refusal, the __gemmein/ exclusion, per-call and per-site size/count caps (1 MB, ~750 KB base64, 2,000 files, 50 MiB), and that nothing is served until site_publish. These are real behavioral facts an agent must know before writing.

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?

It is dense but front-loaded, with the action and path rules first and limits/alternatives after. Every clause carries information, though the single run-on paragraph with long parenthetical rule lists would read better broken into a few sentences or bullets.

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 write tool with no output schema, the description covers everything needed to call it correctly: path validity, content encoding, overwrite semantics, size/count limits, blocked filenames, and the fact that publishing is a separate step.

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 already 80%, yet the description still adds hard meaning for path (relative to root, no leading slash, no empty/'.'/'..' parts, allowed character set, 300-char cap, not under __gemmein/) and for content (text vs base64 tied to the encoding value, plus font/image cases). This goes well beyond the schema's short field blurbs.

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?

Opens with a specific verb+resource+scope: 'Puts one file into a site draft (draftId from site_draft).' It clearly distinguishes itself from siblings like site_read (read a file back) and site_publish (serve the draft), so an agent can route 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?

Gives explicit alternatives and conditions: use site_read to fetch a file's current contents before putting it back, and route files over 1 MB through `npx gemmein publish`. It also states the replacement behavior when a path already exists, removing ambiguity about create-vs-update.

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

All Gemmein tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.