PartForge

Edit a forge's code

apply_part_changes

Destructive

Apply an atomic batch of exact edits to a forge's tree, then build it. Every entry in changes names its kind in op — str_replace, create, write, or delete. Prefer str_replace with an old_str that matches exactly once (or set count for more); use create for new files, delete to remove files, write only as a whole-file fallback. expectedTreeHash must be the hash from the latest get_forge or read_part_files call — a stale hash comes back as {conflict:true, manifest} instead of applying. A forge with no code yet (treeHash null) has nothing to be stale against: its first call creates part.js (the entrypoint) and every file the part needs, with an empty expectedTreeHash, and nothing is saved until that build succeeds. On success you get a build screenshot plus measure/verify/lint/match data; on failure, the build error and any lint findings.

Input Schema

TableJSON Schema

Name	Required	Description
`checks`	No	How thorough the check after this build should be. Omit it (or "full") for the complete geometric report. "quick" skips the two slowest passes — minimum wall thickness and sub-part gap distances — and is dramatically faster on a large part, so prefer it while iterating toward a shape. A quick check never returns a verdict: `verify.ok` comes back null and `verify.unevaluated` names each gate that went unchecked. Run a full check on the last edit of a turn, and any time you are about to tell the user the part is finished. A check rides an edit — there is no check-only call, so decide on "full" when you make the edit you expect to be the last. A FULL check can also return `verify.ok: null`, for one of two reasons. When the full check lists entries in `verify.unevaluated`, those declared checks could not be measured — a sheet part's 2-D checks ran out of their time budget, or a reading failed — and each entry's `hint` says why and what to do; re-running the same check will not produce a verdict, so act on the hint and tell the user which check could not run. With `verify.evaluated: 0` and a `no expectations declared` warning, the part verified nothing: declare expectations in the part's `verify` block rather than checking again.
`changes`	Yes
`forgeId`	Yes	The forge's id or its slug, exactly as list_forges or get_forge returned it.
`message`	Yes	One line describing the change
`expectedTreeHash`	Yes	Tree hash this batch was authored against

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 9, 2026

changedInput schema / properties / checks / description

Previous value: -"How thorough the check after this build should be. Omit it (or \"full\") for the complete geometric report. \"quick\" skips the two slowest passes — minimum wall thickness and sub-part gap distances — and is dramatically faster on a large part, so prefer it while iterating toward a shape. A quick check never returns a verdict: `verify.ok` comes back null and `verify.unevaluated` names each gate that went unchecked. Run a full check on the last edit of a turn, and any time you are about to tell the user the part is finished. A FULL check can also return `verify.ok: null`, for one of two reasons. When the full check lists entries in `verify.unevaluated`, those declared checks could not be measured — a sheet part's 2-D checks ran out of their time budget, or a reading failed — and each entry's `hint` says why and what to do; re-running the same check will not produce a verdict, so act on the hint and tell the user which check could not run. With `verify.evaluated: 0` and a `no expectations declared` warning, the part verified nothing: declare expectations in the part's `verify` block rather than checking again."New value: +"How thorough the check after this build should be. Omit it (or \"full\") for the complete geometric report. \"quick\" skips the two slowest passes — minimum wall thickness and sub-part gap distances — and is dramatically faster on a large part, so prefer it while iterating toward a shape. A quick check never returns a verdict: `verify.ok` comes back null and `verify.unevaluated` names each gate that went unchecked. Run a full check on the last edit of a turn, and any time you are about to tell the user the part is finished. A check rides an edit — there is no check-only call, so decide on \"full\" when you make the edit you expect to be the last. A FULL check can also return `verify.ok: null`, for one of two reasons. When the full check lists entries in `verify.unevaluated`, those declared checks could not be measured — a sheet part's 2-D checks ran out of their time budget, or a reading failed — and each entry's `hint` says why and what to do; re-running the same check will not produce a verdict, so act on the hint and tell the user which check could not run. With `verify.evaluated: 0` and a `no expectations declared` warning, the part verified nothing: declare expectations in the part's `verify` block rather than checking again."

First observedOct 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations establish the safety profile (readOnlyHint=false, destructiveHint=true), and the description layers on genuinely non-derivable behavior: batch atomicity, the stale-hash conflict return shape ({conflict:true, manifest}), that nothing is persisted until the build succeeds, and the success/failure payload split (screenshot plus measure/verify/lint/match vs. build error plus lint findings). No contradiction with the destructive hint; the disclosure sharpens it.

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, then ops, then hash contract, then return shapes — a logical progression with no filler sentences. It is dense and long, but nearly every clause carries operational information; the only mild cost is that the conflict and empty-tree rules are packed into the same paragraph.

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?

With no output schema, the description carries the return-value burden and does so for both success and failure paths, including the null-verdict cases that the annotations cannot express. For a destructive, 5-parameter mutation tool, nothing an agent needs before invoking it is missing.

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 80% and the schema already documents checks, count, old_str and forgeId in detail, so the baseline is 3. The description still adds real value by stating the preference ordering among ops, the exact-once-by-default semantics of old_str, and the required provenance of expectedTreeHash.

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+side effect: 'Apply an atomic batch of exact edits to a forge's tree, then build it.' It also differentiates itself from siblings by naming get_forge and read_part_files as the source of expectedTreeHash, so an agent knows exactly which tool this is and where its inputs come from.

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 selection rules across the four ops (prefer str_replace with a unique old_str, use create for new files, delete to remove, write only as a whole-file fallback) and states the no-code case (treeHash null → first call creates part.js with an empty expectedTreeHash). It also routes the agent to the right sibling for obtaining the hash.

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

All PartForge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?