Catching Numerical Errors in AI Finance Articles with an MCP Server Architecture Using a ‘Narrow Validation Function’

When polishing financial drafts written by AI, practitioners often focus on sentence structure and tone. However, hs85-newbie, who runs the disclosure commentary blog macromalt.com, recalls an incident where they skipped the crucial step of checking key figures during the final review, even after instructing the prompt to "verify accurately," resulting in the publication of amounts that differed from the actual disclosures ¹. Text with smooth sentences but incorrect numbers is difficult for both the writer and the reader to detect.

How should a 'fact-check MCP server' be configured to automatically perform number verification between AI and original data? The structure of the published korea-finance-factcheck server provides an answer to that question. The core concept is not a "massive engine that verifies anything," but defining inspection functions with scopes narrowed to the types of errors that actually occurred. Each function directly calls official APIs to identify discrepancies between AI output and the original source, and items that cannot be verified must be clearly processed as 'unverified.' A design that narrows the boundaries to reduce alert fatigue is the prerequisite for its operation.

Why Verify 'Numbers' Rather Than Sentences

In financial reporting, numerical errors distort facts themselves, unlike typos. While collaborating with AI to write content, hs85-newbie actually encountered three types of errors ².

The first is ratio direction inversion. The disclosure stated "0.2521056 shares of Woori Financial per 1 share of Dongyang Life," but the AI reversed the numerator and denominator, writing "0.2521056 shares of Dongyang Life per 1 share of Woori Financial." The second is unit confusion. Amounts recorded in won were tagged with a label of 'million won,' inflating revenue and operating profits by factors of 10 and 100; this mistake was replicated in eight published posts. The third is offset misreading. While reading the U.S. Treasury interest rate table, the row and column positions shifted, resulting in the 7-year bond yield being recorded in place of the 10-year bond yield ².

It is worth noting that these errors did not arise from linguistic limitations of the model. hs85-newbie wrote, "In all three cases, the model wrote exactly what it received" ². The causes were human misreading of the ratio direction and adding unit labels, along with gaps in the revision process; the model simply transferred the input faithfully. Even if accuracy is emphasized in the prompt, errors remain unless source comparison is structurally included in the pipeline. The quality of AI reporting is not just a matter of model performance, but of how well the verification infrastructure is connected.

How the MCP Server Sits Between AI and Original Data

To automate fact-checking, a standardized pathway is needed for AI to call original data. This is where the Model Context Protocol (MCP) is utilized.

MCP standardizes how AI applications connect with external data sources or tools. The basic structure is a three-party setup consisting of a host (AI application) → client (connector) → server (program exposing functionality), and the server exposes tools, resources, and prompts ³. If a company has N internal AI apps and M data sources, creating individual connectors without a standard would require N×M connections. MCP reduces this to a single standard protocol ³.

The korea-finance-factcheck server utilizes the 'tools' primitive of this structure to provide LLMs with a "function to compare numbers in the manuscript with official data." When Claude or an internal AI agent submits a manuscript, the server receives a tools/call request, directly queries sources such as DART disclosures, the Bank of Korea ECOS, the U.S. Treasury, and the Korea Exchange (KRX), and returns the comparison results in JSON format. Note that the MCP specification revised on July 28, 2026, transitioned the protocol layer to stateless. With each request now including its own version and metadata, horizontal scaling via round-robin load balancing became possible without sharing state between server instances ³.

Designing Four Inspection Functions with Narrowed Scopes

The korea-finance-factcheck is noteworthy because it does not claim to "check all numbers." hs85-newbie intentionally narrowed the inspection scope to prevent alert fatigue ².

1. check_ratio_direction: Direction Errors

This function compares merger and stock swap ratio sentences with the original disclosure text. If the body contains "n shares of Y per 1 share of X," it detects sentences where the paying and receiving entities have been reversed in the disclosure ². If the body contains a submission number, the disclosure is fetched from DART; otherwise, it is compared against the notation transcribed in the body.

2. check_unit_errors: Unit Errors

Revenue, operating profit, and net income recorded alongside stock codes (e.g., Samsung Electronics 005930) are compared with DART business reports. However, only discrepancies off by factors of 10, 100, or 1000 are selectively reported. hs85-newbie explicitly stated that they narrowed the scope to avoid excessive warnings, as catching numbers that legitimately differ from disclosures, such as securities firm forecasts, would be counterproductive ².

3. check_market_numbers: Market Indicator Offset Errors

This function queries 2-, 5-, 10-, and 30-year U.S. Treasury bond yields from U.S. Treasury data, along with KOSPI closing prices, base rates, and exchange rates from the Bank of Korea ECOS. Particularly for exchange rate verification, considering the structural difference between weekly closing prices and the ECOS exchange benchmark rate, alerts are triggered only when the difference exceeds 15 won ². This mechanism prevents flagging trivial notation differences as errors.

4. check_stock_closes: Closing Price Misreads

Numbers in won that are explicitly labeled as 'closing price' or 'close' are compared with official KRX closing prices. Strict conditions based on the word 'closing price' are applied to prevent misreading target prices as closing prices. Notably, percentage change verification is excluded. hs85-newbie noted, "I have previously misread period returns, such as 'a 18.8% decline since September 30,' as daily fluctuations," so percentage changes are not checked ².

The commonality of these four checks is that they are functions narrowly defined around the specific causes of errors. hs85-newbie explained that tests containing only fabricated numbers failed to catch actual mistakes, so they included the exact sentences that had been previously incorrect in the tests ².

Pipeline Placement and Exception Handling Workflow

Installation is simple. In an environment with uv, you can register it in Claude Code using the following command ².

claude mcp add korea-finance-factcheck \
  -e DART_API_KEY=발급받은_키 \
  -e ECOS_API_KEY=발급받은_키 \
  -e KRX_API_KEY=발급받은_키 \
  -- uvx korea-finance-factcheck

In Claude Desktop, add the mcpServers configuration to claude_desktop_config.json ².

{
  "mcpServers": {
    "korea-finance-factcheck": {
      "command": "uvx",
      "args": ["korea-finance-factcheck"],
      "env": {
        "DART_API_KEY": "발급받은_키",
        "ECOS_API_KEY": "발급받은_키",
        "KRX_API_KEY": "발급받은_키"
      }
    }
  }
}

Note that authentication keys for the three institutions (DART, ECOS, KRX) must each be individually issued and inserted. Due to institutional terms of service, authentication keys cannot be shared with others, so the server does not proxy or store user keys centrally ². The KRX Open API is permitted only for non-commercial use, and results must cite 'KRX Statistics Information' as the source ².

When placing the pipeline, the exception handling workflow is critical.

• Report query failures. If an API key is missing or the query itself fails, the reason is specified in the skipped field ².
• Allow partial failures. When running check_all, if some checks fail, the remaining results are still returned ².
• Distinguish unverified items. Numbers not found in disclosures or official statistics (such as securities firm estimates or intraday prices) are not judged but returned as unverified ².

The core principle is to distinguish "indecidable" from "error," prompting human final review. hs85-newbie clarified that "it does not pass silently even when checks cannot be performed," separating check failures from items outside the scope ².

Verification Coverage and Actual Limitations

The role of this server is limited to comparing whether numbers in the body match the original source. hs85-newbie clearly drew the line by stating, "It does not suggest buying or selling specific stocks or provide stock price forecasts. Do not use the results as a basis for investment decisions" ².

The limitations are also clear. korea-finance-factcheck was designed based on the three types of errors (ratio inversion, unit confusion, column offset) that hs85-newbie personally experienced ². hs85-newbie wrote on GeekNews, "Since I built this solely by looking at mistakes that occurred on my own blog, I am not sure if it will be useful for other people's posts" ¹.

Therefore, when applying this tool structure, one must first define the types of errors that frequently occur in their own content. To catch errors in securities firm consensus, PER, or PBR figures often found in investment reports, these items fall outside the server's scope and are likely to be returned as 'unverified' ². Additionally, Naver Data is not natively supported due to the narrow scope of its terms of service ². This is a design decision resulting from the narrow usage scope defined by data source terms, not a technical limitation.

To catch numerical errors in AI-written financial posts, it is effective to bundle inspection functions with scopes narrowed to the specific types of errors that actually occurred into an MCP server, rather than building a massive verification platform. Each function directly calls official APIs to compare with the original source, and items that cannot be verified are transparently revealed as skipped and unverified for human review. Designing these boundaries is the condition for maintaining checks without alert fatigue.