meritz-mcp

Official

by meritz-securities

Overview Schema Source Related Servers Discussions Admin

Python

Remote

메리츠 주문

meritz_trading

Destructive

Place, cancel, or modify domestic and overseas stock orders and query order history via Meritz Open API by specifying api_type and params.

Instructions

메리츠 Open API — 주문 (24건). api_type 으로 호출할 API 를 고르고 params 에 파라미터를 넣습니다. api_type='describe' 로 부르면 파라미터 설명을 돌려줍니다.

credit_orders_buy POST 신용매수 주문 ⚠ 상태변경 credit_orders_sell POST 신용매도 주문 ⚠ 상태변경 orders_buy POST 일반주문 매수 ⚠ 상태변경 orders_cancel POST 국내주식 주문 취소 ⚠ 상태변경 orders_estimate GET 주문가능금액·수량 조회 orders_history GET 주문내역 조회 orders_modify POST 국내주식 주문 정정 ⚠ 상태변경 orders_sell POST 일반주문 매도 ⚠ 상태변경 ovs_orders_buy POST 해외주식 매수 주문 ⚠ 상태변경 ovs_orders_cancel POST 해외주식 주문 취소 ⚠ 상태변경 ovs_orders_detail GET 해외주식 주문체결 상세조회 ovs_orders_estimate GET 해외주식 주문가능금액 조회 ovs_orders_history GET 해외주식 주문체결내역 조회 ovs_orders_modify POST 해외주식 주문 정정 ⚠ 상태변경 ovs_orders_sell POST 해외주식 매도 주문 ⚠ 상태변경 ovs_orders_today GET 해외주식 당일 주문체결내역 조회 ovs_reserved_orders GET 해외주식 예약주문 조회 ovs_reserved_orders_buy POST 해외주식 예약주문 매수 ⚠ 상태변경 ovs_reserved_orders_cancel POST 해외주식 예약주문 취소 ⚠ 상태변경 ovs_reserved_orders_sell POST 해외주식 예약주문 매도 ⚠ 상태변경 reserved_orders GET 국내주식 예약주문 조회 reserved_orders_buy POST 국내주식 예약주문 매수 ⚠ 상태변경 reserved_orders_cancel POST 국내주식 예약주문 취소 ⚠ 상태변경 reserved_orders_sell POST 국내주식 예약주문 매도 ⚠ 상태변경

Input Schema

Name	Required	Description	Default
`params`	No
`account`	No
`api_type`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.12Oct 15, 2026

addedInput schema / properties / account

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

First observedv0.3.0Sep 21, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false for the whole tool, but the description adds granular value by flagging which of the 24 sub-operations actually change state (⚠) versus pure GET lookups. It also discloses the self-describing 'describe' escape hatch for parameter details. It stops short of covering auth, account selection behavior, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and usage rules are front-loaded in three short lines, followed by a dense 24-line catalogue where each line carries an id, verb, operation name, and risk marker. The list is long but every line is load-bearing since it enumerates valid api_type values; structure is clean and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not document return values, and annotations already carry the safety profile. For a dispatcher over 24 endpoints it is largely complete, with the notable remaining gap being the opaque params object and undocumented account parameter, only partially mitigated by the 'describe' mechanism.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and none of the three properties carry descriptions, so the description must compensate. It effectively serves as the enum for api_type by listing the 24 valid values with their meanings, but leaves params (an arbitrary object) and account entirely unexplained except through the separate describe call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (주문/orders) and then enumerates all 24 concrete sub-operations with Korean labels and HTTP verbs, so an agent can see exactly what the tool covers. This is clearly distinguishable from the sibling groups (meritz_forex, meritz_account, meritz_market, etc.), which cover other API families. Purpose is unambiguous even before opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states the invocation pattern: pick an operation with api_type and pass arguments in params, and use api_type='describe' to fetch parameter documentation first. The per-endpoint ⚠ 상태변경 (state change) markers also guide the agent on which calls mutate state. What is missing is when-not-to-use guidance or any routing rule relative to the sibling category tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server