feat(mcp): add MCP-029, TypeScript tool writes to the filesystem

[bradAGI]

MCP-005 covers the Python path-safety case; the TypeScript half was missing. Mirrors CSDK-012 — the TS half of the Claude SDK pair — including its coarse-signal caveat, stated in the explanation so the finding is honest about itself: it flags any filesystem write, not only unnormalized paths, because TS path-normalization analysis isn't wired yet. Confidence 0.5 to match.

Deployment is what sharpens this for MCP, and it's the part worth having in the finding text. A stdio server is launched as a subprocess by whatever client the user is running, so it inherits that user's own filesystem permissions, not a service account's. A write escaping its intended directory doesn't hit a sandbox — it reaches the user's home directory, dotfiles, and SSH keys.

The second half is that the server cannot see the injection. It receives a well-formed tools/call for a path it has no way to distinguish from a legitimate one, so there's no server-side signal to alert on. Containment has to be structural.

The fix names the stronger remedy for the common case: derive the filename server-side from an id rather than accepting a path over the protocol at all.

Verification — engine built at main:

$ trustabl rules validate .
OK: 85 rule pack(s), 207 rule(s) valid under rule schema version 14

Fire (writeFileSync(notePath, body) with notePath from the tool schema): MCP-029
Silent (server-derived id, no caller-supplied path): no findings

No new predicates, so no schema_version bump.

[jhumel-code]

Thanks @bradAGI, this is a careful pair. The rule is schema-clean (scope: tool, applies_to: [mcp_tool], language: typescript stated explicitly, severity and confidence matched to CSDK-012), and has_write_call already exists on main with a TypeScript path backed by the writes_fs handler fact, so you are right that no schema_version bump is needed. The explanation is honest about the coarse signal rather than burying it, and the deployment framing (a stdio server inheriting the invoking user's own filesystem permissions) is what earns this a place next to MCP-005. The YAML also matches the fixture copy in trustabl/trustabl#172 byte for byte, which is exactly what I want to see from a cross-repo pair.

The thing to sort out is the ID. MCP-029 is claimed by two other open pairs for completely different rules: #80 with trustabl/trustabl#124, and #100 with trustabl/trustabl#135. Whichever lands first, the others will need to renumber and rebase. Main stops at MCP-022, so MCP-023 onward is free and there is no reason for three PRs to be sitting on 029.

One more note: every shipped rule needs a rationale doc in trustabl-rulebook. That is not a demand on you, we can handle it or pair on it.

Happy to take this once the numbering is settled.