2026-07-23

Internal MCP Package Deployment Compatibility Restoration — Toss Broken Pipe Cause Tracking and Resolution

While performing the JYP stock analysis process, I discovered a persistent 'Broken pipe' error when calling domestic chart tools and traced the cause. Initially, I thought it was a communication error with the Toss API or the chart data itself, but upon precise diagnosis of the internal sandbox process, the cause was completely different. Recently, during the split refactoring of the Toss MCP module, a new common sibling module was created, but the problem was that only a single entrypoint file was registered in the sandbox deployment manifest, causing it to be missing in the deployment environment.

This caused a ModuleNotFoundError to occur during process initialization, immediately terminating the process. The Stdio MCP client was sending requests to the already-closed process's Stdin, only exposing a 'Broken pipe' error on the surface. Even the existing error handling structure was only consuming and discarding Stderr logs, completely concealing the actual cause. Accordingly, I fixed the official deployment unit of the internal MCP to be the entire mcp_servers Python package rather than individual entrypoint files, and switched the sandbox manifest to recursively track all files and directories under the package for upload and synchronization.

At the same time, I improved the MCP client to preserve the last 8KB of Stderr records when a process terminates, returning clear error causes, server names, and exit codes. Now, even if a module is missing or initialization errors occur, we can immediately check the exact exception message instead of just a hollow pipe error. After modifying the deployment contract and improving Stderr logging, I verified that all 42 related unit tests and static analysis passed, securing the internal MCP stability.

Data Pipeline Bug Patch — DART, Kiwoom, KRX MCP Stack Maintenance

During the process of creating stock analysis reports, I diagnosed and fixed the system code where some data fields were outputting 'N/A'. First, I noticed that the environment variable passthrough syntax for DART and ECOS servers was missing in the MCP server configuration, normalizing the API key integration step. I also discovered an AttributeError occurring in the Korean stock report skill (kr-stock-report) where the .get() method was being directly called on JSON string return values, and neatly resolved the data extraction bug by adding a .loads() parsing process.

I also further strengthened the KRX market data tool. I added a tool alias (get_krx_stock_info) to prevent module import failures in advance, and wrote fallback logic to automatically look back the last 5 business days of data to prevent short selling data from becoming empty when querying before market close or on holidays. This ensures consistent data quality regardless of market conditions or query timing.

SK Hynix·Samsung Electronics Actual Measurement Verification and JYP v2 Report Activation

After completing the bug patches, I conducted full pipeline actual data verification for two representative stocks: SK Hynix (000660) and Samsung Electronics (005930). I confirmed that DART's consolidated financial statement data, Kiwoom's 30-day foreign and institutional supply/demand data, and consensus and KRX short selling balance data were all collected without errors.

Based on the collected data, I successfully created a modern-style stock analysis report with various components harmoniously arranged according to my blog specification guidelines: BLUF, 4x2 KPI Grid, supply/demand analysis chart, Risk & Catalyst card grid, and scenario analysis box, and shared it as a Notion subpage.

Today's Reflections

It seems there were cases where I missed changes to functions while doing merge operations or other updates.