tmaker_writeSaves Template Maker projects. Builds a ZIP archive of skeleton HTML with its stylesheet and images, downloading external ones from the addresses in the HTML and CSS, and puts it in the public root of the site. Site templates are not changed.
| Name | Required | Description | Default |
|---|---|---|---|
| tmpl | Yes | Skeleton HTML. | |
| action | Yes | Operation to run. Each oneOf entry describes one action and lists its parameters. |
Changes observed during successful MCP inspections.
Input schema / requiredPrevious value: -[
- "action"
-]New value: +[
+ "action",
+ "tmpl"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructive=true, openWorld=true, and readOnly=false. The description adds useful behavioral context beyond annotations: it downloads external stylesheet and image resources from URLs embedded in HTML/CSS, writes a ZIP archive to the public root, and does not alter site templates. It stops short of explaining overwrite behavior or active-project semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded, three sentences, and every sentence contributes: the primary purpose, the archive-building behavior, and the scope exclusion. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with full schema coverage and rich annotations, the description covers the main behavioral traits: saving, ZIP creation, external downloads, public-root placement, and unchanged site templates. It does not clarify the return value for skeleton_archive or overwrite behavior for project_save, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the action enum includes detailed oneOf descriptions for each operation. The description adds no parameter-specific guidance beyond what the schema already provides, so it meets the baseline but does not enrich parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool saves Template Maker projects and builds a ZIP archive of skeleton HTML with assets. It also clarifies that site templates are not changed, which distinguishes it from template-editing tools. However, it does not explicitly distinguish its three actions from siblings like tmaker_publish or tmaker_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by describing save and archive behavior, and 'Site templates are not changed' provides a limited exclusion. However, it does not name alternatives such as tmaker_publish or explain when to choose project_save versus skeleton_archive beyond what the schema already says.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.