CodexPro Runtime

Overview Schema Source Related Servers Discussions Admin

Git Finalize

git_finalize

Finalize Git changes safely by merging selected and expected paths, blocking missing or extra files, and creating a verified security receipt before commit or push.

Instructions

Precisely finalize Git changes after a scoped release safety check: merge selected_paths with authoritative expected_paths so omitted task outputs are still eligible, include explicitly named untracked files without a second hidden switch, exclude unrelated untracked files, block missing or extra paths before creating a local commit, create and validate a content-bound security receipt, block sensitive paths or unsafe/incomplete scans, verify the committed path set again, and optionally push the exact commit. Build, tests, browser validation, Acceptance, and formal certification are not rerun.

Input Schema

Name	Required	Description
`user_intent`	Yes	Original user wording that explicitly requests commit, and push when include_push=true.
`include_push`	No	Push after commit. Defaults to whether user_intent explicitly includes push.
`workspace_id`	No	Optional workspace id. When omitted, CodexPro binds the authoritative conversation workspace automatically; an explicit unknown or mismatched id is rejected.
`security_mode`	No	Security evidence mode for push. Local commits always use a bounded candidate-path scan. Default push mode: incremental; a missing baseline defers push instead of running a synchronous full scan. Explicit full mode retains the release-grade gate.
`commit_message`	No	Optional commit subject. When provided, it is passed to Git unchanged.
`expected_paths`	No	Authoritative exact paths expected in the new commit. These paths are merged into the eligible scope even when selected_paths omitted them. Missing or extra candidates block before a local commit and committed paths are checked again afterward.
`selected_paths`	No	Workspace-relative candidate paths eligible for this commit. Explicitly selected untracked paths are eligible automatically. When expected_paths is also provided, both lists are merged so expected task outputs omitted here can still be included.
`conversation_id`	No	Connector conversation id bound to this workspace. Modern MCP injects it automatically; side-effecting tools require it to match the authoritative binding.
`include_untracked`	No	Legacy compatibility flag. Explicitly named untracked paths in selected_paths or expected_paths are eligible without this flag; unrelated untracked paths are never selected implicitly.
`workspace_generation`	No	Optional authoritative workspace generation. When omitted, CodexPro injects the conversation-bound generation; an explicit stale generation is rejected.

Output Schema

Name	Required	Description	Default
`tool_result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 3, 2026

TDQS

A4.2/5.0

Behavior5/5

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

The description is rich in behavioral disclosure beyond annotations: it explains the merge of selected/expected paths, the blocking behavior for missing/extra paths, content-bound security receipt creation, sensitive-path blocking, rejection of mismatched workspace ids/generations, and the explicit statement that build/tests/validation are not rerun. Annotation openWorldHint=true is consistent with the description's scope-expanding merge behavior. This fully compensates for the sparse annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense run-on paragraph covering ~10 distinct behaviors with colons chaining multiple clauses. While information-dense and largely front-loaded with the primary purpose, the lack of sentence breaks or structural separation reduces scannability. It is arguably over-specified for a description, though each clause does add genuine behavioral information rather than padding.

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 complex tool with 10 parameters, an output schema, and 100% schema coverage, the description comprehensively covers the full behavioral surface: path merging/eligibility, exclusion rules, blocking conditions, security receipt validation, push modes, workspace binding, and explicit non-re-run operations. With an output schema present and rich schema descriptions, the description need not enumerate return values. The state-machine-like flow (scan, verify, receipt, commit, re-verify, push) is fully disclosed without excess.

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 description coverage is 100%, so parameters are already well-documented in the schema. The description adds value by clarifying the interaction semantics between selected_paths and expected_paths (merge behavior), the include_untracked legacy flag's reduced role, and the workspace binding/defaults for workspace_id and workspace_generation. The description complements rather than merely repeats the schema. Slight overlap remains since schema already documents much of this, so a strong 4 rather than 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a clear verb+resource ('finalize Git changes') with substantial detail about the operation: merging paths, blocking missing/extra paths, creating a security receipt, verifying committed paths, and optionally pushing. It distinguishes from siblings by covering the full finalize workflow (combining commit+push with safety checks) rather than just committing or pushing alone. However, the purpose is stated as one long run-on sentence listing many sub-steps, making it somewhat harder to parse as a single tool intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is the integrated finalize step (commit + optional push with security checks), distinguishing it operationally from sibling tools like git_commit and git_push_only. It notes explicitly what is NOT rerun (build, tests, browser validation, Acceptance, formal certification), giving exclusion guidance. However, it does not explicitly name alternative sibling tools for when-to-use vs when-not-to-use the standalone tools.

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