한국투자증권(KIS) REST API를 MCP 도구로 호출하는 서버입니다. 국내/해외 주식 조회, 계좌 조회, 주문 관련 API를 카탈로그 기반 범용 도구와 자주 쓰는 편의 도구로 제공합니다.
이 프로젝트는 개인/커뮤니티가 운영하는 비공식 오픈소스 프로젝트이며 한국투자증권, KIS Developers, true friend 한국투자 Open API와 제휴·후원·승인·공식 배포 관계가 없습니다. 본 프로젝트의 설치, 설정, API 호출, 계좌 조회, 주문 실행, 투자 판단 및 그 결과로 발생하는 손실·장애·보안 문제 등 사용상의 모든 책임은 사용자에게 있습니다. 실제 거래 전 한국투자증권 공식 문서와 입력값을 직접 확인하세요.
Related MCP server: kiwoom-mcp
API 카탈로그 기반 호출
8개 그룹, 166개 REST API 제공
API 그룹/ID, 경로, HTTP 메서드, TR_ID 후보, 요청 파라미터 확인
파라미터별 한글 라벨, 입력 가이드, 예시값, 주요 코드값 제공
전체 목록: API_CATALOG.md
국내주식
현재가, 기간/일별 시세, 호가, 업종지수, 기본정보 조회
잔고, 투자계좌 자산현황, 매수가능금액, 매도가능수량 조회
주문/주문내역/정정취소 가능 주문 조회
해외주식
미국, 일본, 중국, 홍콩, 베트남 시장 코드 지원
현재가, 잔고, 체결기준 현재잔고, 통화별 증거금, 매수가능금액 조회
시장/매수매도 방향에 따른 주문 TR_ID 자동 선택
실행/운영
stdio, sse, streamable-http transport 지원
.env 또는 명령줄 인자 기반 설정
계좌번호, 계좌상품코드, 인증값 자동 보완
앱키와 계좌 타입 기준 토큰 캐시
알 수 없는 요청 파라미터 기본 거부
주문/정정/취소 API 기본 차단
주문/정정/취소처럼 계좌 상태를 바꾸는 API는 기본적으로 차단됩니다.
KIS_ENABLE_TRADING=true위 값을 명시적으로 설정한 경우에만 상태 변경 API가 실행됩니다. 조회 API만 사용하는 경우에는 설정하지 마세요.
Python >= 3.13
uv
설치는 INSTALL.md를 기준으로 진행하세요. LLM이나 MCP 클라이언트가 설정할 때도 이 파일을 우선 읽으면 됩니다.
INSTALL.md에는 다음 내용이 포함되어 있습니다.
uv 기반 의존성 설치
.env 생성과 KIS_APP_KEY, KIS_APP_SECRET, KIS_CANO, KIS_ACNT_PRDT_CD 설정
Codex CLI, Claude Code, Claude Desktop, 일반 MCP 클라이언트 등록 예시
컨텍스트 절약용 KIS_MCP_TOOLSET=catalog 설정
잔고, 매수가능금액, 현재가 조회용 call-kis-api 예시
빠른 로컬 준비:
pip install uv
uv sync
cp .env.example .env
chmod 600 .env그 다음 .env에 아래 값을 설정합니다. 자세한 값 설명과 클라이언트별 등록 명령은 INSTALL.md를 참고하세요.
KIS_APP_KEY="발급받은 앱키"
KIS_APP_SECRET="발급받은 시크릿키"
KIS_ACCOUNT_TYPE="REAL" # REAL 또는 VIRTUAL
KIS_CANO="계좌번호 앞 8자리"
KIS_ACNT_PRDT_CD="01"
KIS_MCP_TOOLSET="catalog"# stdio, 로컬 MCP 클라이언트 권장
uv run python server.py명령줄 인자로도 설정할 수 있습니다.
uv run python server.py \
--app-key "앱키" \
--app-secret "시크릿키" \
--account-type "REAL" \
--cano "계좌번호" \
--acnt-prdt-cd "01"Transport 선택:
MCP_TYPE=stdio uv run python server.py
MCP_TYPE=streamable-http MCP_HOST=127.0.0.1 MCP_PORT=8000 MCP_PATH=/mcp uv run python server.py
MCP_TYPE=sse MCP_HOST=127.0.0.1 MCP_PORT=8000 MCP_PATH=/sse uv run python server.pyMCP 클라이언트 등록 예시:
아래는 일반 MCP 클라이언트용 최소 예시입니다. Codex CLI, Claude Code, Claude Desktop 명령은 INSTALL.md를 사용하세요.
{
"mcpServers": {
"kis-mcp-server": {
"command": "uv",
"args": ["run", "python", "server.py"],
"cwd": "<project-root>",
"env": {
"KIS_MCP_TOOLSET": "catalog",
"KIS_MCP_LOG_LEVEL": "WARNING"
}
}
}
}도구 | 설명 |
| API 그룹/검색어 기준 목록 조회 |
| 단일 API의 경로, TR_ID 후보, 파라미터 확인 |
|
|
list-kis-api-specs는 필수 파라미터의 라벨, 예시값, 주요 코드값을 함께 반환합니다.
get-kis-api-spec는 전체 파라미터의 label, guide, examples, values, default, auto_fill 정보를 반환하므로 LLM이 호출에 필요한 입력 형태를 바로 확인할 수 있습니다.
call-kis-api는 다음 처리를 공통으로 수행합니다.
환경변수 기반 계좌번호/계좌상품코드 자동 입력
인증 토큰 발급 및 캐시
GET/POST 요청 구성
일부 MCP 클라이언트가 params를 JSON 문자열로 보낼 때 객체로 파싱
다중 TR_ID 중 자동 판별 가능한 주문 TR_ID 선택
상태 변경 API 안전 게이트 적용
카탈로그에 없는 파라미터 기본 거부
자주 쓰는 국내/해외 주식 기능은 별도 MCP 도구로도 제공합니다.
도구 | 설명 |
| 국내주식 현재가 조회 |
| 국내주식 잔고 조회 |
| 국내주식 일별 주문/체결 조회 |
| 국내주식 주문 상세 조회 |
| 국내주식 일별 시세 조회 |
| 국내주식 기간 시세 조회 |
| 국내주식 호가 조회 |
| 국내 업종/지수 현재가 조회 |
| 국내주식 기본정보 조회 |
| 해외주식 현재가 조회 |
| 국내주식 매수/매도 주문 |
| 해외주식 매수/매도 주문 |
주문 도구도 KIS_ENABLE_TRADING=true가 없으면 실행되지 않습니다.
MCP 클라이언트는 서버 연결 시 도구 이름, 설명, 입력 스키마를 컨텍스트에 올립니다. 편의 도구를 많이 노출할수록 대화 시작 시점의 컨텍스트 사용량이 늘어나므로, 필요한 경우 카탈로그 도구 3개만 노출하는 경량 모드를 사용할 수 있습니다.
KIS_MCP_TOOLSET=catalog uv run python server.py값 | 노출 도구 수 | 노출 도구 | 용도 |
| 15개 | 카탈로그 도구 + 편의 도구 전체 | 기존 동작과 호환 |
| 3개 |
| 낮은 컨텍스트 사용량 |
catalog 모드는 MCP 도구 스키마 로드량을 줄이기 위한 모드입니다. 편의 도구는 숨기지만, 166개 API는 그대로 call-kis-api로 호출할 수 있습니다. 필요한 API는 list-kis-api-specs로 찾고, 필요한 상세 파라미터는 get-kis-api-spec로 그때그때 조회하면 됩니다.
권장 사용 흐름:
list-kis-api-specs로 API를 검색합니다.
get-kis-api-spec로 필수 파라미터, 예시값, 코드값을 확인합니다.
call-kis-api로 실제 API를 호출합니다.
MCP 클라이언트 설정에서도 환경변수만 추가하면 됩니다.
{
"env": {
"KIS_MCP_TOOLSET": "catalog"
}
}자주 쓰는 편의 도구를 도구 목록에 직접 노출하고 싶으면 기본값인 full을 사용하세요.
call-kis-api 예시국내주식 현재가:
{
"group": "domestic_stock",
"api_type": "inquire_price",
"params": {
"fid_cond_mrkt_div_code": "J",
"fid_input_iscd": "005930"
}
}해외주식 잔고:
{
"group": "overseas_stock",
"api_type": "inquire_balance",
"params": {
"ovrs_excg_cd": "NASD",
"tr_crcy_cd": "USD"
}
}해외주식 체결기준 현재잔고:
{
"group": "overseas_stock",
"api_type": "inquire_present_balance",
"params": {
"wcrc_frcr_dvsn_cd": "01",
"natn_cd": "000",
"tr_mket_cd": "00",
"inqr_dvsn_cd": "00"
}
}해외주식 매수가능금액:
{
"group": "overseas_stock",
"api_type": "inquire_psamount",
"params": {
"ovrs_excg_cd": "NASD",
"ovrs_ord_unpr": "1",
"item_cd": "QQQ"
}
}그룹 | 설명 | API 수 |
| 인증 | 2 |
| 국내주식 | 74 |
| 해외주식 | 34 |
| 국내채권 | 14 |
| 국내선물옵션 | 20 |
| 해외선물옵션 | 19 |
| ELW | 1 |
| ETF/ETN | 2 |
전체 API ID, 경로, TR_ID, 필수 파라미터 가이드는 API_CATALOG.md에 정리되어 있습니다.
이름 | 설명 | 기본값 |
| KIS 앱키 | - |
| KIS 시크릿키 | - |
|
| - |
| 계좌번호 앞 8자리 | - |
| 계좌상품코드 |
|
| 토큰 캐시 파일 |
|
| 주문/정정/취소 API 활성화 | 비활성 |
| MCP 도구 노출 범위 ( |
|
| 로그 레벨 |
|
|
|
|
| HTTP/SSE host |
|
| HTTP/SSE port |
|
| HTTP/SSE path |
|
uv run python -m compileall main.py server.py example.py tests
uv run python -m unittest discover -v
git diff --checkAI 공동작성자는 기여자 목록에서 제외했습니다.
Contributor | Role |
Maintainer | |
Contributor | |
Contributor |
MIT
Get current stock balance information from Korea Investment & Securities
| 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 full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this requires authentication, has rate limits, returns real-time vs. cached data, what format the balance information comes in, or any error conditions. The description adds no behavioral context beyond the basic purpose.
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 communicates the essential purpose without any wasted words. It's appropriately sized for a simple read operation and front-loads the key information ('Get current stock balance information').
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 financial data tool with no annotations and no output schema, the description is insufficient. It doesn't explain what balance information is returned (cash balance, stock positions, margin status, etc.), the data format, whether authentication is required, or any limitations. Given the complexity of financial systems and lack of structured documentation, more context is needed.
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the schema handles documentation.
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 ('Get') and resource ('current stock balance information') with specific context ('from Korea Investment & Securities'). It distinguishes from siblings by focusing on balance rather than orders, prices, or history. However, it doesn't explicitly differentiate from potential similar tools like account summaries.
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 provided about when to use this tool versus alternatives. While the name suggests it's for balance inquiries (vs. order or price queries), the description doesn't mention when this specific balance tool should be used over other financial data tools or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get order detail from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| order_no | Yes | ||
| order_date | Yes |
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 the tool retrieves order details, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or response format. This is a significant gap for a tool with zero annotation coverage.
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 with no wasted words. It's front-loaded and directly states the tool's purpose without unnecessary elaboration.
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 lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't provide enough context for the agent to understand behavioral traits, parameter usage, or expected outcomes, which is inadequate for a tool with two required parameters.
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 description adds no information about the parameters beyond what the input schema provides. Since schema description coverage is 0%, the description doesn't compensate by explaining the meaning or format of 'order_no' and 'order_date'. However, with only 2 parameters and no complex schema, the baseline score of 3 is appropriate as the schema itself is minimal.
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 ('Get') and resource ('order detail from Korea Investment & Securities'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'inquery-order-list' or 'inquery-balance', which prevents 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. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily order list from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | ||
| end_date | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' implying a read operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, pagination, or response format. For a financial data tool with no annotations, this is a significant gap in transparency about how the tool behaves and any constraints.
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 front-loads the core purpose ('Get daily order list') and specifies the source. There is zero waste or redundancy, making it highly concise and well-structured for quick understanding.
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 (financial data retrieval with date parameters), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover authentication, error handling, return values, or how to interpret results, leaving critical gaps for an AI agent to use the tool effectively in a real-world context.
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 0%, so the description must compensate. It mentions 'daily order list' which implies date-based filtering, aligning with the 'start_date' and 'end_date' parameters. However, it doesn't add meaning beyond this implication—no details on date format, timezone, or what 'daily' entails (e.g., if it aggregates by day). With two undocumented parameters, the description provides minimal semantic value.
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 verb ('Get') and resource ('daily order list'), specifying the source ('from Korea Investment & Securities'). It distinguishes from siblings like 'inquery-balance' or 'inquery-order-detail' by focusing on daily order lists rather than balances or detailed orders. However, it doesn't explicitly differentiate from 'order-stock' or 'order-overseas-stock', which might be related write 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?
No explicit guidance on when to use this tool versus alternatives like 'inquery-order-detail' for specific orders or 'inquery-balance' for account balances. The description implies usage for retrieving daily order lists, but lacks context on prerequisites, exclusions, or comparisons to sibling tools, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get overseas stock price from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides minimal information. It states what the tool does but doesn't describe response format, error conditions, rate limits, authentication requirements, or whether this is a read-only operation. For a financial data query tool with zero annotation coverage, this leaves significant behavioral questions unanswered about how the tool actually behaves when invoked.
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 - a single sentence that gets straight to the point without unnecessary words. It's front-loaded with the core functionality. While perhaps too brief given the lack of other documentation, the sentence itself is efficient and doesn't waste space on redundant information.
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 financial query nature, 2 required parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficiently complete. It states what the tool does at a high level but provides none of the operational details needed to use it effectively. Users need to understand parameter formats, response structure, and behavioral characteristics that are completely missing from this minimal description.
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?
With 0% schema description coverage and 2 required parameters, the description provides no information about parameter meaning or usage. It doesn't explain what 'symbol' and 'market' represent, what formats they accept, or provide examples. The description doesn't compensate for the complete lack of schema documentation, leaving users to guess about parameter requirements for this overseas stock price query.
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 ('Get') and resource ('overseas stock price from Korea Investment & Securities'), making the purpose immediately understandable. It distinguishes itself from siblings like 'inquery-stock-price' by specifying 'overseas' scope, though it doesn't explicitly contrast with all siblings. The description avoids tautology by providing meaningful context beyond just restating the tool name.
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 this overseas stock price query is appropriate compared to domestic tools like 'inquery-stock-price' or other overseas-related tools like 'order-overseas-stock'. There's no indication of prerequisites, constraints, or typical use cases for this specific overseas price query functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock ask price from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves ask prices but doesn't mention whether this is a read-only operation, requires authentication, has rate limits, returns real-time or delayed data, or handles errors. For a financial data tool with zero annotation coverage, this is a significant gap in transparency.
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 purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity of financial data queries, no annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't explain what the ask price represents, the data format returned, or how it differs from related tools, leaving too many gaps for effective agent use.
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 input schema has 1 parameter with 0% description coverage, and the tool description provides no information about the 'symbol' parameter. It doesn't specify the expected format (e.g., ticker symbols for Korean stocks), examples, or constraints, failing to compensate for the lack of schema documentation.
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 ('Get') and resource ('stock ask price') with specific source ('Korea Investment & Securities'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'inquery-stock-price' or 'inquery-overseas-stock-price', which likely provide similar price information but for different markets or price types.
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. With siblings like 'inquery-stock-price' and 'inquery-overseas-stock-price' available, there's no indication of whether this tool is for Korean stocks specifically, real-time vs. historical data, or ask price vs. other price types, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily stock price history from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| start_date | Yes | ||
| end_date | Yes |
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 the tool retrieves historical data but doesn't specify aspects like rate limits, authentication requirements, data format, error handling, or whether it's a read-only operation. This leaves significant gaps for an agent to understand how to interact with it safely and effectively.
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, clear sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of a financial data tool with 3 required parameters, no annotations, and no output schema, the description is incomplete. It lacks details on parameter semantics, behavioral traits, and expected outputs, which are crucial for an agent to use this tool correctly in a real-world context.
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 0%, meaning none of the three parameters (symbol, start_date, end_date) have descriptions in the schema. The tool description doesn't compensate by explaining what these parameters mean, their expected formats (e.g., date format like YYYY-MM-DD), or valid ranges. This leaves the agent guessing about input requirements.
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 ('Get daily stock price history') and specifies the data source ('from Korea Investment & Securities'), which distinguishes it from general stock price queries. However, it doesn't explicitly differentiate from sibling tools like 'inquery-stock-price' or 'inquery-overseas-stock-price' in terms of scope or granularity.
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 prerequisites, limitations, or compare it to siblings such as 'inquery-stock-price' (which might provide current prices) or 'inquery-overseas-stock-price' (which might handle non-Korean stocks).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily stock price information from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| start_date | Yes | ||
| end_date | Yes |
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 the tool retrieves 'daily stock price information,' implying a read-only operation, but fails to mention critical details like authentication requirements, rate limits, data freshness, or error handling. This leaves significant gaps in understanding how the tool behaves in practice.
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 purpose without any unnecessary words. It is front-loaded and appropriately sized for its content, making it easy to parse quickly.
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 complexity of a financial data tool with 3 required parameters, no annotations, and no output schema, the description is incomplete. It lacks details on parameter semantics, behavioral traits, and expected outputs, leaving the agent with insufficient information to use the tool effectively in context.
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 0%, meaning parameters are undocumented in the schema. The description does not add any meaning beyond the parameter names (e.g., it doesn't explain what 'symbol' represents, date formats for 'start_date' and 'end_date', or valid ranges). This fails to compensate for the low schema coverage, making parameter understanding inadequate.
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 ('Get daily stock price information') and the resource ('from Korea Investment & Securities'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'inquery-stock-price' or 'inquery-stock-history', which likely serve similar purposes, preventing 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, such as how it differs from 'inquery-stock-price' or 'inquery-stock-history' among the sibling tools. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current stock price information from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes |
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 the tool does but lacks critical behavioral details such as whether this is a read-only operation, potential rate limits, authentication requirements, or error handling. For a financial data tool with zero annotation coverage, this is a significant gap.
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 purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to understanding what the tool does.
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 complexity of financial data queries, no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what information is returned (e.g., price, currency, timestamp), how current the data is, or any limitations. For a tool that likely provides time-sensitive financial information, this leaves too many questions unanswered.
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 input schema has 1 parameter with 0% description coverage, and the tool description provides no information about the 'symbol' parameter. It doesn't explain what format the symbol should be in (e.g., ticker symbols for Korean stocks), valid examples, or any constraints. The description fails to compensate for the complete lack of schema documentation.
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 ('Get') and resource ('current stock price information'), and specifies the data source ('Korea Investment & Securities'). However, it doesn't explicitly differentiate from sibling tools like 'inquery-overseas-stock-price' or 'inquery-stock-info', which likely serve related but distinct purposes.
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 sibling tools like 'inquery-overseas-stock-price' for overseas stocks or 'inquery-stock-info' for general stock information, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order overseas stock (buy/sell) from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| quantity | Yes | ||
| price | Yes | ||
| order_type | Yes | ||
| market | Yes |
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 'Order' implies a write/mutation operation, the description doesn't address critical behavioral aspects: whether this executes immediately or places an order, what permissions are required, whether it's reversible, confirmation requirements, rate limits, or what happens on failure. For a financial transaction tool with zero annotation coverage, this represents a significant gap in behavioral transparency.
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 at just one sentence that states the core purpose. There's no unnecessary verbiage or repetition. However, the structure could be improved by front-loading more critical information about when to use this tool versus its sibling 'order-stock'.
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 financial transaction tool with 5 required parameters, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain parameter meanings, behavioral characteristics, success/failure conditions, or differentiation from the sibling 'order-stock' tool. The description fails to provide the contextual information needed for safe and correct tool invocation.
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?
With 0% schema description coverage for all 5 required parameters, the description provides no information about what any parameter means or how to use them. The description doesn't explain what 'symbol' represents, what 'order_type' options exist, what 'market' refers to, or the units/format for 'price' and 'quantity'. For a tool with 5 undocumented parameters, this is insufficient compensation for the schema coverage gap.
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 ('Order overseas stock') and specifies the resource ('from Korea Investment & Securities'), with the parenthetical '(buy/sell)' providing additional context about the transaction type. However, it doesn't explicitly differentiate this tool from its sibling 'order-stock' which appears to handle domestic orders, leaving some ambiguity about when to use each.
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. With a sibling tool named 'order-stock' that likely handles domestic orders, there's no indication of when to choose overseas vs domestic ordering. No prerequisites, constraints, or comparison with other tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order stock (buy/sell) from Korea Investment & Securities
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| quantity | Yes | ||
| price | Yes | ||
| order_type | Yes |
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 'buy/sell' but doesn't clarify if this is a live trade execution, a simulation, or requires confirmation. It omits critical details like authentication needs, rate limits, transaction costs, or whether the order is immediate or pending.
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 gets straight to the point without unnecessary words. It's appropriately sized for a tool with four parameters, though it could benefit from slightly more detail given the lack of annotations and schema coverage.
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 complexity of a financial trading tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address behavioral traits, parameter meanings, or expected outcomes, leaving significant gaps for an AI agent to understand how to use 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?
Schema description coverage is 0%, so the description must compensate but fails to do so. It doesn't explain what 'symbol', 'quantity', 'price', or 'order_type' mean in this context (e.g., currency units, order type options like market/limit). The description adds no semantic value beyond the bare parameter names.
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 ('Order stock') and specifies the resource (stock from Korea Investment & Securities), distinguishing it from sibling tools that are primarily query operations (e.g., 'inquery-balance', 'inquery-stock-price'). However, it doesn't explicitly mention the buy/sell aspect beyond the parentheses, which could be more prominent.
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 'order-overseas-stock' or the various 'inquery' siblings. It lacks context about prerequisites, such as authentication or account setup, and doesn't specify scenarios where this tool is 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.
inquery-balanceinquery-order-detailinquery-order-listinquery-overseas-stock-priceinquery-stock-askinquery-stock-historyinquery-stock-infoinquery-stock-priceorder-overseas-stockorder-stockScored across 10 tools
The tools have clear distinctions between querying (inquery-*) and ordering (order-*), but within the querying tools there is significant overlap that could cause confusion. For example, inquery-stock-price, inquery-stock-info, and inquery-stock-ask all seem to retrieve stock price-related data with subtle differences that may not be immediately clear to an agent.
All tool names follow a consistent hyphen-separated pattern with a clear verb-noun structure (e.g., inquery-balance, order-stock). The naming is predictable and uniform across all 10 tools, making it easy for an agent to parse and understand the purpose of each tool.
With 10 tools, the count is well-scoped for a securities trading API, covering key operations like querying balances, orders, stock prices, and placing orders. Each tool appears to serve a distinct function within the domain, and the number is neither too sparse nor overwhelming.
The tool set provides comprehensive coverage for core trading operations, including querying various data (balances, orders, prices) and executing orders (domestic and overseas). A minor gap is the lack of tools for modifying or canceling orders, which might be necessary for full lifecycle management, but agents can likely work around this with the existing query and order tools.
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A Model Context Protocol server exposing real-time and historical Colombo Stock Exchange (CSE) data to AI agents and LLM applications. Provides quotes and OHLCV price history, full financial statements (income, balance sheet, cash flow), pre-computed technicals (moving averages, RS ratings, volume signals), macroeconomic indicators, corporate actions, and rule-based screening across CSE stocks and sector indices, everything needed to build CSE-aware trading assistants, research tools, and market-analysis agents. This is the official MCP server of www.ceyloncharts.com
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
