Summary: This MCP server generates Python code for calling Meritz Securities Open API — no API calls, no app key, runs locally.
list_categories() — list API categories and their counts.
search_api(keyword, category) — find APIs by natural-language query (Korean supported), optionally narrowed by category.
get_api_detail(api_type) — get an API's path, parameters, response fields, and cautions.
generate_code(api_type) — generate callable Python code (REST or realtime WebSocket); orders/forex default to non-sending until confirm=True; api_type='token' generates token issuance code.
api_conventions() — return auth flow, calling conventions, response codes, and known issues.
meritz_code_prompt(task) prompt — guides the search-to-code-generation workflow.
Click on "Deploy 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., "@meritz-codegen Generate Python code to get real-time stock price for Samsung Electronics."
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.
현재 베타 서비스 기간입니다.
메리츠증권 Open API를 호출하는 파이썬 코드를 만들어 주는 MCP 서버입니다. API를 직접 호출하지 않으므로 앱키가 필요 없습니다. 내 PC에서 도는 로컬 서버이고, 단일 실행 파일이라 Python이나 uv를 따로 설치하지 않으셔도 됩니다.
REST 69건과 실시간 13건 전부를 다룹니다. 카탈로그는 개발자 포털 등록 명세에서 만듭니다.
파일은 릴리스 페이지에서 받으십시오. 쓰시는 것 하나만 받으시면 됩니다. 앱키를 넣는 자리는 없습니다.
쓰시는 도구 | 방법 |
Claude Desktop | OS에 맞는 |
아무 도구나 — 자동 설치 |
|
Claude Code |
|
Codex CLI · ChatGPT 데스크톱 |
|
Gemini CLI |
|
Cursor · VS Code | 각 앱의 MCP 설정 파일에 JSON 을 넣습니다 — |
실행 파일은 meritz-codegen-mcp-darwin-arm64 · meritz-codegen-mcp-darwin-x64 · meritz-codegen-mcp-win32-x64.exe 입니다.
Mac에서 직접 내려받으셨다면 실행 권한과 격리 속성 해제가 필요합니다.
chmod +x ~/Downloads/meritz-codegen-mcp-darwin-arm64
xattr -d com.apple.quarantine ~/Downloads/meritz-codegen-mcp-darwin-arm64격리 속성이 남아 있으면 서버가 아무 메시지 없이 종료되어 도구 목록에 나타나지 않습니다.
OS 보안 경고, 체크섬 대조, 기동 대기 시간, Claude 웹·ChatGPT 웹용 터널 연결은
docs/install.md에 있습니다.
Related MCP server: Kiwoom API MCP Server
설치하고 클라이언트를 다시 시작하면 도구 다섯 개가 뜹니다. 그대로 물어보시면 됩니다.
삼성전자 현재가 조회하는 파이썬 코드 만들어 줘
해외 주문 취소는 어떤 API 써?도구 | 하는 일 |
| 분류와 API 개수 |
| 자연어 검색. 한글 표현도 알아듣습니다 |
| 경로·파라미터·응답 필드·주의사항 |
| 호출 코드 (REST·실시간) |
| 인증·호출 규약·응답 코드 |
meritz_code_prompt(task) 프롬프트도 함께 제공합니다. 검색부터 코드 생성까지의
순서를 안내합니다.
토큰 발급·재사용, 요청, 응답 판정까지 들어갑니다. HTTP 200만 보고 넘기지 않습니다
연속 조회로 다음 페이지를 받는 방법을 주석으로 적어 줍니다
실시간은 웹소켓 구독 코드를 만듭니다. 접속점은 하나이고 tr_cd가 무엇을 받을지 정합니다
주문·환전 코드는 confirm=True를 넘기기 전까지 전송하지 않는 형태로 만듭니다
주문 코드에는 경고 확인 흐름이 들어갑니다. 응답이 성공이어도 data.warn_cls_code가
0이 아니면 접수되지 않은 상태이므로, 생성된 코드가 MeritzWarning을 던집니다
응답 판정 규칙과 오류 코드 해석은 llms.txt에, 코드표는
open-api 저장소의 docs/errors.md에 있습니다.
하고 싶으신 일 | 여기로 |
호출 코드를 받아 쓰기 | 이 저장소 |
파이썬으로 직접 호출해 보기 | open-api — 실행 예제 |
터미널에서 조회·주문하기 | open-api-studio — |
AI 클라이언트에 붙이기 | open-api-mcp — MCP 서버 |
uv sync
uv run pytest tests/ -q
./build_binary.sh # bin/meritz-codegen-mcp — PyInstaller 단일 실행 파일
python3 make_bundle.py darwin-arm64 # dist/meritz-open-api-codegen-darwin-arm64.mcpb릴리스는 태그를 밀면 GitHub Actions가 세 플랫폼을 빌드해 올립니다.
생성된 코드는 운영 서버를 향합니다. 실행하시면 실계좌에 영향을 줍니다
주문 코드의 확인 단계를 지우시면 확인 없이 전송됩니다. 남겨 두시길 권합니다
MIT — LICENSE
실행 파일에 함께 들어가는 오픈소스의 라이선스 전문은 THIRD-PARTY-NOTICES.txt 에 있습니다.
문의는 개발자 포털을 이용해 주세요.
인증 절차·호출 규약·응답 코드·알려진 문제를 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the content scope (authentication, conventions, response codes, known issues) but does not disclose any additional behavioral aspects such as whether results are static, cached, or require specific permissions. With annotations present, the added content context justifies a 3.
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, concise sentence that front-loads the primary purpose. There is no redundant or filler content, and it efficiently conveys the full scope of what the tool returns.
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 parameterless read-only reference tool with an output schema, the description is complete. It lists the four categories of content returned, and the output schema covers the response structure. No additional prerequisites or caveats are needed, making this definition fully sufficient for an agent to call it correctly.
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 zero parameters, and the input schema is an empty object. The baseline for zero parameters is 4, and the description correctly implies no arguments are needed. It does not need to explain parameter formats or defaults since there are none.
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 returns authentication procedures, call conventions, response codes, and known issues. The verb 'returns' plus the specific content types make the purpose explicit, and the content differs from sibling tools like get_api_detail, which presumably provides API-specific details rather than conventions.
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?
No guidance is given about when to use this tool versus alternatives. The description implies it is for retrieving conventions, but it does not mention exclusions or contrast with siblings like get_api_detail or search_api. An agent would have to infer the appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
api_type 을 호출하는 Python 코드를 만듭니다. REST 는 토큰 발급·요청·응답 판정까지, 실시간은 웹소켓 구독 코드를 만듭니다. 주문·환전은 confirm=True 전까지 전송하지 않는 안전장치가 들어갑니다. api_type='token' 이면 토큰 발급 코드만 만듭니다.
| Name | Required | Description | Default |
|---|---|---|---|
| api_type | Yes | 코드를 만들 API 의 api_type. search_api 나 get_api_detail 에서 확인한 값을 넣습니다. 'token' 이면 접근토큰 발급 코드만 만듭니다. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: generated code includes token issuance, request/response handling, websocket subscription, and a confirm=True safety guard so orders/exchanges are not sent prematurely. It stops short of describing error behavior or code usability caveats.
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?
Three concise sentences, all front-loaded: main purpose, then REST/real-time variants, then safety behavior and the token exception. Every sentence earns its place with no filler or redundant expansion.
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 one-parameter generator with a rich output schema and safety annotations, the description covers the core input semantics and all generation modes. It is slightly incomplete about when to consult api_conventions and what happens on invalid api_type values, but nothing essential to calling it correctly is missing.
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 coverage is 100%, and the parameter description already explains that api_type must come from search_api/get_api_detail and that 'token' produces token-issuance code only. The tool description repeats the token special case but adds little semantic value beyond the schema, so the baseline 3 is appropriate.
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 opens with a specific verb and resource: 'Creates Python code that calls api_type' and then disambiguates REST, real-time websocket, and token-only generation modes. This makes the purpose unmistakable and clearly distinguishes it from the sibling discovery/inspection 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 implies usage by API type and special-cases api_type='token', while the parameter schema tells agents to use a value from search_api or get_api_detail. However, it never explicitly states when to prefer this tool over api_conventions or other siblings, nor does it give exclusions. Guidance is adequate but mostly left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
api_type 의 상세를 반환합니다 — 경로·파라미터·응답 필드·주의사항.
| Name | Required | Description | Default |
|---|---|---|---|
| api_type | Yes | search_api 결과의 api_type 값을 그대로 넣습니다. 예: 'market_prices', 'order_buy'. 짐작해서 쓰지 말고 먼저 search_api 로 찾으십시오. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the result scope (path, parameters, response fields, caveats) but does not add deeper behavioral context like authentication or rate limits; given the read-only annotations, that is an acceptable baseline.
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 compact sentence that front-loads the action and resource ('api_type 의 상세를 반환합니다') and then lists the relevant result categories. Every word earns its place, with no filler or redundancy.
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 single-parameter read-only/idempotent tool with an output schema and strong annotation hints, the definition is complete. The only potentially missing guidance—search_api first—is already supplied by the parameter schema, so an agent has everything needed to call the tool correctly.
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%, and the schema itself documents the single parameter thoroughly with examples and a 'don't guess; use search_api first' instruction. The tool description adds no additional parameter-specific meaning, so the high-coverage baseline of 3 is appropriate.
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 action and resource: it returns the details of an api_type and enumerates the content (path, parameters, response fields, caveats). It does not explicitly contrast itself with sibling search_api in the main description, so it stops short of fully earning the sibling-differentiation bar for a 5.
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 input schema's parameter description gives explicit workflow guidance: use the api_type value from search_api results exactly as-is, don't guess, and run search_api first. This names the alternative tool and the correct ordering, making when to use this tool unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
분류와 API 개수를 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is consistent and adds the specific return content (categories and counts). It does not disclose any further behavioral traits such as pagination or result limits, but the annotations cover the safety profile, so a mid score is appropriate.
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?
A single, direct sentence with no filler. The purpose is stated efficiently and the content is front-loaded.
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 simplicity (no parameters, read-only, output schema exists), the description is minimally sufficient but lacks any usage context or differentiation from sibling tools. For a simple tool this is adequate, but not complete in terms of guiding correct selection.
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 zero parameters, so the baseline is 4. The schema is empty and the description adds nothing about parameters, which is acceptable since there are none to explain.
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 states the tool returns categories and API counts, which is a clear verb-resource pair. However, it does not differentiate itself from sibling tools like search_api or get_api_detail; the name itself provides most of the clarity.
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 gives no guidance on when to use this tool versus alternatives. It does not mention any context, exclusions, or relationships to sibling tools, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
자연어로 API 를 찾습니다. 예: search_api('삼성전자 현재가'), search_api('매수'), search_api('실시간 체결통보'). category 로 좁힐 수 있습니다 (account·domestic_market·overseas_market·trading·forex·reference·realtime·oauth2). 인증(접근토큰 발급·폐기)은 '토큰'·'인증'·'oauth'·'revoke' 로 찾습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 찾으려는 것을 우리말로 적습니다. 예: '삼성전자 현재가', '매수 주문', '실시간 체결통보', '예수금'. API 이름을 몰라도 됩니다. | |
| category | No | 분류로 좁히고 싶을 때만 씁니다. account·domestic_market·overseas_market·trading·forex·reference·realtime·oauth2 중 하나. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is well covered. The description adds useful behavioral context about natural-language matching and which keywords surface authentication APIs, going slightly beyond the structured annotations without contradicting them.
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 compact and front-loaded: the first sentence states the purpose with examples, and the second covers category narrowing and auth-related search terms. Every sentence earns its place, with no repetition or filler.
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 two-parameter search tool with an output schema and annotation coverage, the description is complete. It explains the query language, provides examples, enumerates valid categories, and handles special auth-related searches. Nothing needed for correct invocation is missing.
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 coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics by showing realistic query examples (e.g., '매수', '실시간 체결통보') and listing category values inline, which helps an agent choose the right keyword and category beyond the schema definitions alone.
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: it finds/search APIs using natural-language queries, with concrete examples like search_api('삼성전자 현재가'). It does not explicitly differentiate from sibling tools such as get_api_detail or list_categories, but the verb '찾습니다' and resource 'API' make the core purpose unambiguous.
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 gives clear usage context: use natural-language keywords, optionally narrow by category, and use specific authentication-related terms to find auth APIs. It does not explicitly state when not to use this tool or compare it with alternatives, so it does not reach 5, but the guidance is concrete and actionable.
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.
v0.3.7generate_code1 field changedInput schema / properties / api_type / descriptionAdded value: +"코드를 만들 API 의 api_type. search_api 나 get_api_detail 에서 확인한 값을 넣습니다. 'token' 이면 접근토큰 발급 코드만 만듭니다."get_api_detail1 field changedInput schema / properties / api_type / descriptionAdded value: +"search_api 결과의 api_type 값을 그대로 넣습니다. 예: 'market_prices', 'order_buy'. 짐작해서 쓰지 말고 먼저 search_api 로 찾으십시오."search_api2 fields changedInput schema / properties / category / descriptionAdded value: +"분류로 좁히고 싶을 때만 씁니다. account·domestic_market·overseas_market·trading·forex·reference·realtime·oauth2 중 하나."Input schema / properties / keyword / descriptionAdded value: +"찾으려는 것을 우리말로 적습니다. 예: '삼성전자 현재가', '매수 주문', '실시간 체결통보', '예수금'. API 이름을 몰라도 됩니다."v0.3.0api_conventionsgenerate_codeget_api_detaillist_categoriessearch_apiScored across 5 tools
Each tool has a distinct role: search_api discovers APIs via natural language, get_api_detail provides specific API details, api_conventions offers general conventions, generate_code produces code, and list_categories gives a categorical overview. No overlapping purposes.
Four tools follow the verb_noun pattern (search_api, get_api_detail, generate_code, list_categories), but api_conventions deviates by being a noun phrase. The snake_case style is consistent, and the deviation is minor.
With 5 tools, the server is well-scoped for its code generation purpose. Each tool contributes to the discovery-to-code pipeline without redundancy or bloat.
The tool surface covers the full workflow: finding APIs, inspecting details, understanding conventions, generating code, and exploring categories. No obvious gaps for the intended code generation functionality.
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
Korea-native MCP gateway: Korean commerce, payments, messaging, gov & finance APIs for AI agents.
Search and run data, text, code, PDF and web APIs. Requests not stored. Network tools need a key.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
