MCP 在做什麼？用 Python + filesystem server 串起一個本機工作流What MCP Actually Does: Wiring filesystem + Python Into One Local Workflow

Open Claude Desktop, Claude Code, or Cursor, and you see a flood of MCP servers you can install. As a user the most common question is — how is this different from just writing a Python script that calls some APIs?

This article answers that with the smallest possible example: Python MCP SDK connecting to a filesystem MCP server, running a 5-transaction workflow (write files, classify, generate monthly report) entirely on the local machine, no cloud.

The MCP Triangle

MCP splits LLM-to-tool communication into three layers:

1. Host: the program running the LLM conversation (Claude Desktop, Claude Code, or in this experiment, Python)
2. MCP Client: translates the host's requests into JSON-RPC and sends to the server
3. MCP Server: wraps real tools (filesystem, database, API) into a "tool list + invoke" interface

Protocol: JSON-RPC over stdio (minimal dependencies, language-agnostic).

The value of this layering isn't "it works" — it's that "write the server once, every MCP-aware host can use it." Write a sqlite MCP server once: Claude Desktop uses it, Claude Code uses it, your Python script uses it. No rewrites.

Demo 1: Connect to filesystem Server, List Tools

Python side:

from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

params = StdioServerParameters(
    command="/tmp/mcp-install/node_modules/.bin/mcp-server-filesystem",
    args=[str(DATA_DIR)],
)

async with stdio_client(params) as (read, write):
    async with ClientSession(read, write) as session:
        await session.initialize()
        tools = await session.list_tools()
        # → 14 tools: read_file, write_file, list_directory, ...

@modelcontextprotocol/server-filesystem is the official Node binary, providing 14 file operation tools. stdio_client spawns a child process for bidirectional JSON-RPC communication.

Actual tool call:

await session.call_tool("write_file", {
    "path": "/path/to/output.json",
    "content": json.dumps(data)
})

Compared to direct Path(...).write_text(), MCP adds ~200ms of "JSON-RPC serialization + cross-process communication" overhead. The trade is "standardization" and "LLM composability."

Demo 2: Let the LLM Pick the Tool

Give gemma4 the tool list and one transaction, ask it to choose:

You have these tools:
- write_file(path, content)
- read_text_file(path)
- list_directory(path)

Task: save this transaction as JSON
Transaction: {"date":"2026-06-02","merchant":"NETFLIX","amount":290}

Reply only with tool call JSON

After 14 seconds gemma4 responds:

{
  "tool": "write_file",
  "args": {
    "path": "NETFLIX_2026-06-02.json",
    "content": "{\"date\":\"2026-06-02\",\"merchant\":\"NETFLIX\",\"amount\":290}"
  }
}

But execution fails: path uses a relative NETFLIX_2026-06-02.json, and the MCP server rejects it (since the server isn't running in that cwd).

This exposes an engineering reality: the LLM knows which tool to use, but not necessarily the tool's detail requirements. The host layer needs to:

• Explicitly state in the system prompt that paths must be absolute
• Or intercept tool calls and auto-prepend the path prefix

This is part of what real MCP integration handles — interface standardization isn't the same as "LLM automatically knows how to use it."

Demo 3: The Full Workflow

5 fake transactions (全聯, NETFLIX, 中油, 鼎泰豐, KKBOX), running the full flow:

1. Via MCP: write_file 5 times (one JSON per transaction)
2. Via MCP: list_directory to confirm
3. gemma4 classifies: each transaction gets a category (dining / subscription / grocery / transport)
4. Python aggregates: produces a monthly markdown report

gemma4's classifications:

5/5 correct. This benefits from dropping the "if unsure, answer other" escape hatch in the prompt (same lesson as the static-vs-dynamic article).

The Generated Monthly Report

Python aggregates the 5 classifications into a markdown report:

# 2026-06 月報

## Overview
- Transactions: 5
- Total: NT$5,149

## Category Distribution
- 餐飲: NT$2,100 (40.8%)
- 交通: NT$1,380 (26.8%)
- 超市便利: NT$1,280 (24.9%)
- 訂閱服務: NT$389 (7.6%)

## Details
| Date | Merchant | Amount | Category |
| ⋯⋯

End-to-end (write through monthly report) is 44 seconds. All local, no cloud, no API fees.

MCP Way vs Direct Python

Same task "write one JSON file," two implementations:

For "batch process 5 CSVs," direct Python wins — simple, fast, no dependencies.

MCP's value emerges in larger scenarios:

• Multiple hosts share: write the server once, multiple tools use it
• Multi-tool composition: LLM picks fs / db / api combinations
• Host-managed lifecycle: Claude Desktop and similar hosts manage server lifecycle

4 Pitfalls

Pitfalls encountered (for future implementers):

1. npm permission issue: ~/.npm/_cacache corruption → Solution: npm install --cache /tmp/npm-cache --prefix /tmp/mcp-install <package>
2. MCP server path security: filesystem server only allows access to --args directories at startup, paths must be absolute → Use await session.call_tool("...", {"path": str(DATA_DIR / "file.json")})
3. gemma4 is a thinking model: small num_predict (<2000) lets thinking consume the budget, leaving an empty response → Set to 2000+
4. LLM gives tool call but path detail wrong: LLM knows to use write_file, but gives a relative path → Host layer must specify path rules in system prompt, or intercept tool calls to auto-complete paths

Decision Framework: When to Use MCP

Don't need MCP:

• Single host (just your own Python) + single tool → just write Python

Maybe need MCP:

• Multiple hosts + single tool → write the MCP server once, Claude Desktop / Cursor / your scripts all use it
• Single host + multiple tools → use MCP for LLM to switch between tools (more elegant than hardcoded if/else)

MCP sweet spot:

• Multiple hosts + multiple tools → write a set of MCP servers, hosts mix and match tools as needed

This experiment demonstrated "single host (Python) + single tool (filesystem)" — valid concept demo but not necessarily worthwhile in production, where direct Python is faster. But it's the minimum viable case to understand how MCP works.