ccc-mcp

Overview Schema Source Related Servers Discussions Admin

write_task_file

Writes a complete file to an authorized project via a running ChatGPT execution, using an expected SHA256 check to prevent overwriting others' changes and returning before/after receipts.

Instructions

Write one whole file in the authorized project through your running ChatGPT execution. SA and REVIEW executions are read-only and are refused, as are content that looks like a secret, a stale Context version and a change that would drop original Python comments. Returns before/after SHA256 receipts. Read the file with read_workspace first to get expected_sha256; finish the role with submit_agent_report.

Input Schema

Name	Required	Description
`path`	Yes	File path relative to the project root, for example 'src/app.py'.
`content`	Yes	The complete new file text (UTF-8, at most 200 KB); it replaces the file.
`project_id`	Yes	Registered project id, as returned by list_projects.
`execution_id`	Yes	Your running ChatGPT execution, taken from the dispatched handoff. The task must have an approved plan.
`expected_sha256`	No	SHA256 of the file as you last read it with read_workspace. Omit it only to create a file that does not exist yet; a mismatch is rejected so you never overwrite someone else's change.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.3Nov 7, 2026

addedInput schema / properties / content / description

Added value: +"The complete new file text (UTF-8, at most 200 KB); it replaces the file."

addedInput schema / properties / execution_id / description

Added value: +"Your running ChatGPT execution, taken from the dispatched handoff. The task must have an approved plan."

addedInput schema / properties / expected_sha256 / description

Added value: +"SHA256 of the file as you last read it with read_workspace. Omit it only to create a file that does not exist yet; a mismatch is rejected so you never overwrite someone else's change."

addedInput schema / properties / path / description

Added value: +"File path relative to the project root, for example 'src/app.py'."

addedInput schema / properties / project_id / description

Added value: +"Registered project id, as returned by list_projects."

First observedv0.1.0Nov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the annotations by naming concrete rejection modes: secret-like content, a stale Context version, and a change that would drop original Python comments, plus before/after SHA256 receipts. The only soft spot is that 'replaces the file' sits slightly against destructiveHint=false, but the expected_sha256 guard and comment-preservation rule explain the non-destructive framing rather than contradicting 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?

Four dense sentences, front-loaded with the action and refusals before the workflow pointers; nothing is filler. Minor deduction for the awkward line-wrapped formatting and the slightly compressed listing of rejection reasons, which reads as a run-on.

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?

Covers the preconditions (approved plan, authorized execution), the failure modes, the concurrency contract, and the follow-up step, while an output schema exists so return values need not be spelled out. Nothing an agent needs to call this mutation safely is missing.

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%, so every parameter including expected_sha256 and its omit-to-create rule is already documented in the schema. The description's mention of reading with read_workspace to get expected_sha256 restates the schema rather than adding new meaning, so the baseline 3 applies.

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 with scope: 'Write one whole file in the authorized project through your running ChatGPT execution.' The whole-file (not patch) framing plus the explicit tie to an authorized execution cleanly separates it from read_workspace, propose_context_patch, and submit_agent_report.

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 when-not conditions ('SA and REVIEW executions are read-only and are refused') and the required surrounding workflow: read first via read_workspace to obtain expected_sha256, finish the role with submit_agent_report. An agent knows both the preconditions and the next step without inference.

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

Deploy Server