Skip to main content
Glama
WhoSia
by WhoSia

ChatGPT Web HWPX MCP

Create, understand, edit, and deliver Korean Hangul documents from ChatGPT.

Product authority · Architecture · Feature catalog · Tests · CI

A remote, authenticated Model Context Protocol server for native .hwpx documents. It combines structured document authoring, format-aware inspection, revision-safe editing, explicit human approval for protected changes, and secure HWPX delivery.

Current release status (2026-10-14): GitHub PRs #13, #14, #15, and P4.21 #16 are merged. The P4.21 source merge SHA is dc946b73aaa33a7e1606c701647709653e8c5a6a, followed by WhoSia documentation-only commits. Last directly verified Render LIVE commit: 065922057645abc9ae2b27c9c18a5cca2bce84a2, P4.20, with production MCP reporting 0.43.0-p4.18. The public production-boundary CI for later main correctly reports PRODUCTION_VERSION_STALE; this is not a successful P4.21 deployment. Main release-health image builds also encountered public ECR HTTP 429; the original failures are not erased by successful PR-only tests. Independent Hancom-native visual evidence and full consumer-delivery certification remain pending. See product authority and operations runbook.

What you can do

Goal

Current product surface

Important boundary

Create a document

Natural-language plans, generate_document, run_p418_document_task

Validate generated HWPX before delivery

Understand an HWPX

Inspect, semantic graph, document map, document workspace overview

Structural inference is not proof of Hancom rendering

Prepare a change

prepare_document_title_change (merged P4.19 code; production admission pending)

One tool call compiles, previews and stages a title edit; never executes it

Approve an edit

Separate authenticated browser review (P4.18-P3)

Only the human approves; ChatGPT tool payload cannot self-authorize

Continue / deliver

Revision history, durable commit receipts, revision-bound export

Download/read-back is verified separately; 429 or expiry must not trigger mutation replay

Typical workflow

  1. Ask ChatGPT to create a report or inspect an existing HWPX.

  2. Review its structure, requested scope and suggested changes.

  3. For an approved editing capability, open the independent browser review when a mutation is staged.

  4. After explicit approval, inspect the new revision and request its download.

  5. Verify downloaded bytes and openability before relying on the final document.

The newer get_document_workspace view consolidates revision, history, expiry and receipt information. No one has to pass three intermediate JSON payloads merely to understand document status. These P4.19 conveniences are present on main; production availability and actual consumer behavior require independent live deployment verification.

Related MCP server: WebGPT Codex Bridge

Start the server

Requirements: Python 3.12 recommended, a supported PostgreSQL database, and valid server-side authentication/encryption configuration. The public hosted endpoint is https://chatgpt-web-hwpx-mcp-p0.onrender.com/mcp; its Render hostname is historical and does not guarantee the latest main code is deployed.

python -m pip install -r requirements.txt
python server_p2.py

The local command requires the deployment configuration documented by the runtime; do not hardcode OAuth passwords, signing keys, state encryption secrets or PostgreSQL credentials in code, tests, tool arguments or GitHub Actions logs. To connect ChatGPT, use the MCP endpoint with the configured OAuth flow; the browser-based human edit approval uses a separate authenticated host boundary.

Repository architecture

ChatGPT-Web-HWPX-MCP/
├── server.py, server_p2.py           # Protocol / production entrypoints
├── hwpx_mcp/security/auth_store.py    # Durable OAuth custody\n├── hwpx_mcp/storage/document_store.py # Durable document custody
├── hwpx_mcp/
│   ├── orchestration/               # Agent workflows, preview, staging
│   ├── interfaces/                  # MCP tool registration facades
│   ├── corpus/                      # Reusable corpus & style intelligence
│   ├── document/                    # Native document parsing primitives
│   ├── custody/                     # Capture, replay and evidence custody
│   └── probes/                      # Bounded external world-contact test CLIs
├── tests/                            # Regression and boundary tests
├── scripts/                          # Operational / compatibility tools
├── benchmarks/, corpus/, fixtures/   # Evaluation and materialization inputs
├── docs/                             # Architecture and extended catalog
└── .github/workflows/                # Human-authored CI; no bot commits

P4.19 migration is merged: the Python root now contains 89 modules (previously 263). Legacy feature names remain intentionally supported. Keep moving modules only when it improves domain ownership and runtime operability; do not combine unrelated engines just to optimize a file-count metric. See Architecture and migration policy.

Development and verification

python -m pytest -q
python scripts/p419_layout_audit.py
python -m py_compile server.py server_p2.py

The layout audit checks test location, module relocation, import backlinks and workflow test paths. Product/kernel, PostgreSQL, exact-head Docker, Windows, full lifecycle and live Render checks are separate gates. Linux tests do not establish Hancom-native visual fidelity; renderer evidence requires controlled Windows/Hancom capture.

  • Source of truth: PRODUCT_AUTHORITY.md, with phase evidence archived in the project Drive.

  • Full feature inventory: docs/FEATURE_CATALOG.md.

  • Branch policy: small bounded fixes go directly to main after appropriate validation; large cross-layer refactors use a short-lived branch and PR, then can be deleted after preserving required history. P4.20 PR #14 and PR #15 are already merged; P4.21 PR #16 is merged as GitHub source; complete independent native quality, release-health CI, exact deployed SHA, rollback and live-prod gates before claiming product certification. Do not mistake source merge for production. Never rewrite unrelated history or delete protected/historical refs implicitly.

  • Commit policy: GitHub Actions tests and builds only; commits are authored by the human-connected WhoSia GitHub identity, never github-actions[bot].

  • Release policy: merge, native certification and production deployment are separate explicit decisions. No automatic promotion of HOLD evidence.

Current priorities

Product quality means users can request a useful document, make understandable changes and get an actually openable .hwpx file. P4.20 PR #14/#15 are merged as source revisions; P4.21 PR #16 is merged source (2026-10-13), with Docker release-health CI failures caused by public ECR HTTP 429 and native/live verification still held. Priorities are current-main/PR reconciliation, native Hancom visual evidence, owner-approved formatting and revision-safe live API editing, exact deployed SHA and real consumer acquisition. Preserve earlier COM 0x80070005 failures and native manual-GUI results as separate evidence: test-only success does not certify the production service. Independent Hancom native fidelity remains an explicit gate; byte counts are diagnostic signals, not the product goal.

Open-source license, security, and releases

License: MIT for original source/documentation that the maintainer has rights to license. See third-party notices for package licenses, external test corpora, HWPX data and trademarks. The root license never overrides third-party restrictions.

Security: Report sensitive issues privately using SECURITY.md; never paste passwords, tokens, confidential HWPX content or database URLs into GitHub issues.

Release qualification: Follow production release operations, including exact source SHA/Render LIVE SHA, health, authenticated create→edit→deliver→consumer-open roundtrip, dependency license/SBOM checks, and a confirmed rollback path. Source CI, operational API success, native-render fidelity and independent consumer evidence are separate claims. Do not call a merged PR a published stable release.

Reproducible deployment: Render uses the main branch and a Dockerfile, but service auto-deploy settings do not prove a new version was deployed. Inspect Render's actual deploy SHA. If the latest GitHub SHA has not deployed, the service owner may explicitly choose Deploy → Deploy latest commit in the Render dashboard after checking there is no pending deploy. GitHub Actions tests/builds only and never commits; development and safety branches are deleted manually by the owner.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables continuing a local coding task from your own web ChatGPT account by exposing project-scoped read and apply tools over MCP, with no inference API dependency.
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables exposing product capabilities to ChatGPT, Claude, and other MCP clients via a stateless Streamable HTTP endpoint with OAuth resource binding and structured-output helpers.
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables ChatGPT and other MCP clients to securely read Health Connect-derived health and training history, retrieve daily readiness and workout briefs, save schema-validated coach reports, and trigger email delivery through OAuth-protected tools.
    1
    MIT