meritz-mcp

Official

by meritz-securities

Overview Schema Source Related Servers Discussions Admin

Python

Remote

메리츠 주문

meritz_trading

Destructive

Execute and manage stock trades: place domestic/overseas buy-sell orders, cancel or modify them, and query order history, estimates, and reservations via Meritz Securities Open API.

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

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 21, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, readOnlyHint=false, and idempotentHint=false; the description adds a per-endpoint table marking POST state-changing calls with ⚠ 상태변경 and identifies safe GET queries. This provides concrete behavioral detail beyond the generic annotations, and nothing in the description contradicts them.

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?

The text is long but structured as a scannable table; the introductory sentence and describe instruction are the only prose. Each table line adds a distinct endpoint with its HTTP method and safety marker, so the length is justified for a 24-endpoint dispatcher.

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

Completeness3/5

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

For a 24-endpoint dispatcher, the description names every order API, its method, and whether it changes state, and points to 'describe' for parameter details. It does not explain abbreviations like 'ovs', authentication prerequisites, or endpoint grouping, and the output schema is expected to cover return shape—adequate but not comprehensive.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry the parameter-semantics load. It defines api_type as the selector with 24 concrete values listed in the table, and params as the container for endpoint arguments, plus the 'describe' call to discover parameter details. It does not enumerate per-endpoint params, but the mechanism is sufficiently specified.

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 opens with "메리츠 Open API — 주문" and enumerates 24 order-related endpoints, clearly bounding the tool to trading/order operations. The table of domestic, overseas, and reserved order actions distinguishes this tool from sibling domains like account, market, forex, reference, and info.

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

Usage Guidelines2/5

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

It explains the dispatch pattern (api_type selects the API, params holds arguments) and the 'describe' introspection call. However, it never states when to prefer this tool over sibling tools such as meritz_account or meritz_market, nor does it give exclusion criteria or when-not-to-use guidance.

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

Deploy Server