This MCP server specializes in managing file encodings for Windows development environments with Korean language support.
Core Capabilities:
Create Empty Files - Generate files with specific encodings (UTF-8-BOM, UTF-8, CP949, EUC-KR, ASCII) that AI agents can populate while preserving encoding
Detect File Encoding - Identify encodings with 95%+ accuracy using multi-layer detection: BOM detection, charset-normalizer, chardet, and fallback heuristics (analyzes up to 65536 bytes)
Convert File Encodings - Transform files between supported formats with automatic backup and error recovery
Get System Information - View available encoding libraries and supported formats
Key Features:
Windows Build Optimization - Solves UTF-8 BOM issues in C++ files, PowerShell scripts, and batch files with Korean text
Agent Collaboration - Designed for seamless workflow: server creates properly encoded empty files, agents fill content using write tools
Safe Operations - Automatic backup system with restoration on failure
Clear Interface - Separate filename and directory path parameters for better usability
Provides tools for creating and managing C++ files with UTF-8 BOM encoding for Windows builds, including template support for basic C++ files, headers, and class headers to ensure proper handling of Korean comments and characters.
Supports creation and encoding conversion of Python files with various encoding options including UTF-8 BOM, UTF-8, CP949, and ASCII to ensure compatibility across different environments.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Encoding MCP Server create an empty C++ file with Korean support in the src folder"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
문제: AI Agent(Claude, GPT 등)가 파일을 생성할 때 UTF-8 without BOM으로 작성합니다. 이는 Agent의 write 도구가 BOM을 처리하지 않기 때문입니다.
영향: Windows MSVC 컴파일러는 BOM 없이는 한글 주석/문자열을 잘못 해석합니다. 빌드 실패나 깨진 문자가 발생합니다.
해결: 이 MCP 서버는 Agent가 파일을 쓰기 전에 올바른 인코딩(UTF-8 with BOM)으로 빈 파일을 먼저 생성합니다. Agent의 구조적 한계를 우회하는 방식입니다.
Related MCP server: HWPX Document Server
Agent가 자연스럽게 현재 작업 디렉터리를 인식
파일명과 디렉터리 경로를 명확히 분리
경로 관련 사용성 문제 완전 해결
charset-normalizer: 최신 고성능 라이브러리
chardet: 전통적이지만 안정적
fallback: 라이브러리 없을 때 개선된 휴리스틱
95%+ 정확도 달성
MCP: 정확한 인코딩으로 빈 파일 생성
Agent: write 도구로 내용 채움
결과: UTF-8 BOM 보존
PyPI에서 설치 (권장)
pip install encoding-mcp개발자 모드 설치
git clone https://github.com/whyjp/encoding_mcp.git
cd encoding_mcp
pip install -e .[dev,test]# 패키지 정보 확인
pip show encoding-mcp
# 버전 확인
python -c "import encoding_mcp; print(encoding_mcp.__version__)"
# MCP 서버 실행 테스트
python -m encoding_mcpCursor 설정 → Extensions → MCP → 설정 파일에 추가:
{
"mcpServers": {
"encoding-mcp": {
"command": "python",
"args": ["-m", "encoding_mcp"],
"env": {
"DEBUG": "false"
}
}
}
}Cursor 재시작 후 사용 가능.
npx @modelcontextprotocol/inspector python -m encoding_mcp지정된 인코딩으로 빈 파일을 생성합니다. Agent가 내용을 채울 수 있도록 빈 파일만 생성합니다.
매개변수:
file_name: 생성할 파일명 (예: hello.cpp, test.h)
directory_path: 파일을 생성할 디렉터리의 절대 경로
encoding: 파일 인코딩 (utf-8-bom, utf-8, cp949, euc-kr, ascii)
파일의 인코딩을 정확하게 감지합니다.
매개변수:
file_name: 확인할 파일명 (예: hello.cpp, test.h)
directory_path: 파일이 있는 디렉터리의 절대 경로
max_bytes: 분석할 최대 바이트 수 (기본값: 8192)
파일을 지정된 인코딩으로 변환합니다. 자동 백업 지원.
매개변수:
file_name: 변환할 파일명 (예: hello.cpp, test.h)
directory_path: 파일이 있는 디렉터리의 절대 경로
target_encoding: 목표 인코딩 (utf-8-bom, utf-8, cp949, euc-kr, ascii)
backup: 원본 파일 백업 여부 (기본값: false)
Encoding MCP 시스템 정보를 확인합니다. 사용 가능한 라이브러리와 지원 인코딩을 보여줍니다.
# MCP 호출
mcp_encoding_create_empty_file(
file_name="hello.cpp",
directory_path="D:/my_project/src",
encoding="utf-8-bom"
)# Agent write 도구 사용
write(
file_path="D:/my_project/src/hello.cpp",
contents="#include <iostream>\n\nint main() {\n std::cout << \"Hello, World!\" << std::endl;\n return 0;\n}"
)# 인코딩 감지
mcp_encoding_detect_file_encoding(
file_name="hello.cpp",
directory_path="D:/my_project/src"
)# 안전한 변환 (자동 백업)
mcp_encoding_convert_file_encoding(
file_name="hello.cpp",
directory_path="D:/my_project/src",
target_encoding="utf-8",
backup=true
)# UTF-8 BOM (Windows C++ 최적화)
create_empty_file(file_name="main.cpp", directory_path="D:/project", encoding="utf-8-bom")
# UTF-8 (범용)
create_empty_file(file_name="script.py", directory_path="D:/project", encoding="utf-8")
# CP949 (Windows 한글)
create_empty_file(file_name="korean.txt", directory_path="D:/project", encoding="cp949")
# ASCII (호환성)
create_empty_file(file_name="config.txt", directory_path="D:/project", encoding="ascii")인코딩 | 설명 | Windows 호환 | 용도 |
utf-8-bom | UTF-8 with BOM | 🪟 ✅ | C++, PowerShell |
utf-8 | UTF-8 without BOM | 🐧 ✅ | 범용적 사용 |
cp949 | Windows 한글 | 🪟 ✅ | 레거시 한글 |
euc-kr | Unix/Linux 한글 | 🐧 ✅ | Unix 환경 |
ascii | 7비트 ASCII | 🌍 ✅ | 호환성 최고 |
BOM 감지 (100% 정확도)
charset-normalizer (현대적, 고성능)
chardet (전통적, 안정적)
fallback (개선된 휴리스틱)
BOM 있는 파일: 100%
UTF-8: 94%+
CP949/EUC-KR: 82%+
ASCII: 98%+
C++ 파일: UTF-8 without BOM → 한글 주석 깨짐
PowerShell 스크립트: UTF-8 without BOM → 한글 출력 깨짐
배치 파일: 인코딩 문제 → 스크립트 실행 실패
모든 파일이 UTF-8 with BOM으로 생성
Windows 환경에서 안정적 작동
한글 포함 소스코드 지원
{
"mcpServers": {
"encoding-mcp-dev": {
"command": "python",
"args": ["-m", "encoding_mcp"],
"env": {
"DEBUG": "true",
"LOG_LEVEL": "DEBUG"
}
}
}
}{
"mcpServers": {
"encoding-mcp": {
"command": "python3.11",
"args": ["-m", "encoding_mcp"],
"env": {
"DEBUG": "false"
}
}
}
}{
"mcpServers": {
"encoding-mcp": {
"command": "/path/to/venv/bin/python",
"args": ["-m", "encoding_mcp"],
"env": {
"DEBUG": "false"
}
}
}
}{
"mcpServers": {
"encoding-mcp-dev": {
"command": "python",
"args": ["/path/to/encoding_mcp/encoding_mcp/server.py"],
"env": {
"DEBUG": "true"
}
}
}
}encoding_mcp/
├── server.py # 메인 MCP 서버
├── encoding_detector.py # 인코딩 감지
├── file_operations.py # 파일 생성/변환 로직
├── __main__.py # 모듈 실행 엔트리 포인트
└── __init__.py # 패키지 초기화1. MCP: 정확한 인코딩으로 빈 파일 생성
2. Agent: write 도구로 내용 채움
3. 결과: UTF-8 BOM 보존# 1단계: MCP로 빈 파일 생성
mcp_encoding_create_empty_file(
file_name="hello.cpp",
directory_path=os.getcwd(), # Agent가 자동 인식
encoding="utf-8-bom"
)
# 2단계: Agent가 내용 채움
write(
file_path="hello.cpp",
contents="C++ 소스 코드..."
)
# 결과: UTF-8 BOM 보존된 파일Python 3.10+ (MCP 모듈의 pattern matching 기능 사용)
Windows, macOS, Linux 지원
mcp>=1.0.0: Model Context Protocol
charset-normalizer>=3.0.0: 현대적 인코딩 감지
chardet>=5.0.0: 전통적 인코딩 감지
BOM 감지: 바이트 시퀀스 분석
백업 시스템: 원본 파일 자동 보존
오류 복구: 실패 시 백업에서 복원
이 프로젝트는 MIT 라이선스 하에 배포됩니다.
버그 리포트, 기능 요청, 풀 리퀘스트를 환영합니다.
Convert file to specified encoding. Automatic backup support.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | File name to convert (e.g., hello.cpp, test.h) | |
| directory_path | Yes | Absolute path of directory containing the file | |
| target_encoding | No | Target encoding | utf-8-bom |
| backup | No | Whether to backup original file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'automatic backup support,' which adds some context about safety features, but fails to describe critical behaviors such as whether the conversion is destructive (overwrites the original file), what happens on errors, or any rate limits or permissions required. This leaves significant gaps in understanding the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences that efficiently convey the core functionality and a key feature. It is front-loaded with the main purpose, and every sentence adds value without redundancy. A slight improvement could be made by integrating usage context, but it's well-structured and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (file conversion with potential data loss), lack of annotations, and no output schema, the description is insufficient. It doesn't explain return values, error handling, or the implications of encoding changes, which are critical for safe usage. The description should provide more context to compensate for the missing structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by implying the tool handles file encoding conversion and backup, but it doesn't provide additional semantic context (e.g., how encodings affect file content or backup details). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('convert') and resource ('file'), specifying the action of changing file encoding. It distinguishes from siblings like 'create_empty_file' or 'detect_file_encoding' by focusing on conversion rather than creation or detection. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_system_info'), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'detect_file_encoding' or other encoding-related operations. It mentions 'automatic backup support' as a feature but doesn't specify scenarios where this tool is preferred or when it should be avoided, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an empty file with specified encoding. Creates only an empty file so Agent can fill in content.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | File name to create (e.g., hello.cpp, test.h) | |
| directory_path | Yes | Absolute path of directory to create file in | |
| encoding | No | File encoding | utf-8-bom |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it states the tool creates an empty file, it doesn't mention important behavioral aspects like whether it overwrites existing files, what permissions are required, error conditions, or what happens on success. For a file creation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each earn their place. The first sentence states the core functionality, and the second clarifies the purpose and scope. There's zero wasted language, and the information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file creation tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description provides basic purpose but lacks important behavioral context. It doesn't explain what the tool returns, error conditions, or file system implications. The description is adequate but has clear gaps given the tool's complexity and lack of supporting structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already fully documents all three parameters. The description mentions 'specified encoding' which aligns with the encoding parameter in the schema, but doesn't add meaningful semantic context beyond what the schema provides. The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create an empty file') and resource ('file'), distinguishing it from sibling tools like convert_file_encoding or detect_file_encoding. It explicitly mentions the purpose is to create an empty file for the agent to fill in content later, which is distinct from file manipulation or analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Creates only an empty file so Agent can fill in content'), indicating it's for initial file creation rather than modification. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accurately detect file encoding using professional libraries.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | File name to check (e.g., hello.cpp, test.h) | |
| directory_path | Yes | Absolute path of directory containing the file | |
| max_bytes | No | Maximum bytes to analyze (default: 8192) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'professional libraries' which hints at reliability but lacks critical details such as whether this is a read-only operation, potential performance impacts, error handling for inaccessible files, or the format of detection results (e.g., encoding name, confidence score).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized for a straightforward detection tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (detecting encoding with parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., encoding type, error messages), behavioral aspects like file access permissions, or how it interacts with sibling tools, leaving gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema fully documents all three parameters (file_name, directory_path, max_bytes) with descriptions, types, and constraints. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('detect') and resource ('file encoding'), and mentions the use of 'professional libraries' which adds technical context. However, it doesn't explicitly differentiate from sibling tools like 'convert_file_encoding' which might also involve encoding operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when detection is needed (e.g., before conversion, for debugging) or contrast it with siblings like 'convert_file_encoding' for encoding changes or 'get_system_info' for broader system checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Encoding MCP system information. Shows available libraries and supported encodings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what information the tool provides but doesn't describe important behavioral aspects like whether this is a read-only operation, whether it requires authentication, what format the information is returned in, or any limitations. The description is purely functional without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly state the tool's purpose and what information it provides. It's front-loaded with the main purpose and follows with specific details. There's no wasted language or unnecessary elaboration for this simple informational tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple informational tool with 0 parameters, no annotations, and no output schema, the description provides adequate but minimal coverage. It tells what the tool does but doesn't address format of returned information or any behavioral constraints. For a zero-parameter read operation, this is minimally viable but lacks completeness about what the agent should expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, which is correct for a zero-parameter tool. Baseline for this situation would be 4 since the description doesn't need to compensate for any parameter documentation gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check Encoding MCP system information' with specific details about what information is shown ('available libraries and supported encodings'). It uses a clear verb ('Check') and identifies the resource ('system information'), though it doesn't explicitly differentiate from sibling tools like 'detect_file_encoding' which serves a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it's clear this tool shows system information rather than performing file operations like the sibling tools, there's no explicit mention of when this tool should be selected over other options or what context would make it appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0convert_file_encoding5 fields changedInput schema / properties / backup / defaultPrevious value: -trueNew value: +falseInput schema / properties / backup / descriptionPrevious value: -"원본 파일 백업 여부"New value: +"Whether to backup original file"Input schema / properties / directory_path / descriptionPrevious value: -"파일이 있는 디렉터리의 절대 경로"New value: +"Absolute path of directory containing the file"Input schema / properties / file_name / descriptionPrevious value: -"변환할 파일명 (예: hello.cpp, test.h)"New value: +"File name to convert (e.g., hello.cpp, test.h)"Input schema / properties / target_encoding / descriptionPrevious value: -"목표 인코딩"New value: +"Target encoding"create_empty_file3 fields changedInput schema / properties / directory_path / descriptionPrevious value: -"파일을 생성할 디렉터리의 절대 경로"New value: +"Absolute path of directory to create file in"Input schema / properties / encoding / descriptionPrevious value: -"파일 인코딩"New value: +"File encoding"Input schema / properties / file_name / descriptionPrevious value: -"생성할 파일명 (예: hello.cpp, test.h)"New value: +"File name to create (e.g., hello.cpp, test.h)"detect_file_encoding3 fields changedInput schema / properties / directory_path / descriptionPrevious value: -"파일이 있는 디렉터리의 절대 경로"New value: +"Absolute path of directory containing the file"Input schema / properties / file_name / descriptionPrevious value: -"확인할 파일명 (예: hello.cpp, test.h)"New value: +"File name to check (e.g., hello.cpp, test.h)"Input schema / properties / max_bytes / descriptionPrevious value: -"분석할 최대 바이트 수 (기본값: 8192)"New value: +"Maximum bytes to analyze (default: 8192)"convert_file_encodingcreate_empty_filedetect_file_encodingget_system_infoEach tool has a clearly distinct purpose with no overlap: convert_file_encoding handles file conversion, create_empty_file creates new files, detect_file_encoding identifies encodings, and get_system_info provides system metadata. An agent can easily distinguish between these operations without confusion.
All tool names follow a consistent verb_noun pattern with snake_case: convert_file_encoding, create_empty_file, detect_file_encoding, and get_system_info. This predictable naming scheme makes the tool set easy to navigate and understand.
With 4 tools, the server is well-scoped for encoding operations, covering conversion, creation, detection, and system info. Each tool earns its place without redundancy, making the count appropriate for the domain's core functions.
The tool set covers key encoding workflows: detect, convert, create, and system info, with no dead ends. A minor gap exists in operations like deleting or renaming encoded files, but agents can work around this, and the core functionality is solid.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
APICK Korean data, OCR, search, conversion, image generation and asynchronous TTS
Format/lint JS, Python, HubL for automation platforms. Tools: format_code, format_json, ask_codefmt
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/whyjp/encoding_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
