Este es un servidor que invoca la API REST de Korea Investment & Securities (KIS) como herramientas MCP. Proporciona APIs para consultas de acciones nacionales/extranjeras, consultas de cuentas y pedidos, tanto a través de herramientas generales basadas en catálogo como de herramientas de conveniencia de uso frecuente.
Invocación basada en catálogo de API
Proporciona 166 APIs REST en 8 grupos
Verificación de grupo/ID de API, ruta, método HTTP, candidatos a TR_ID y parámetros de solicitud
Proporciona etiquetas en coreano, guías de entrada, valores de ejemplo y códigos principales para cada parámetro
Lista completa: API_CATALOG.md
Acciones nacionales
Consulta de precio actual, cotizaciones por período/día, libro de órdenes, índices sectoriales e información básica
Consulta de saldo, estado de activos de la cuenta de inversión, monto disponible para compra y cantidad disponible para venta
Consulta de pedidos, historial de pedidos y pedidos corregibles/cancelables
Acciones extranjeras
Soporte para códigos de mercado de EE. UU., Japón, China, Hong Kong y Vietnam
Consulta de precio actual, saldo, saldo actual basado en ejecución, margen por moneda y monto disponible para compra
Selección automática de TR_ID de pedido según el mercado y la dirección de compra/venta
Ejecución/Operación
Soporte para transporte stdio, sse, streamable-http
Configuración basada en .env o argumentos de línea de comandos
Autocompletado de número de cuenta, código de producto de cuenta y valores de autenticación
Caché de tokens basada en clave de aplicación y tipo de cuenta
Rechazo predeterminado de parámetros de solicitud desconocidos
Bloqueo predeterminado de APIs de pedido/corrección/cancelación
Related MCP server: kiwoom-mcp
Las APIs que modifican el estado de la cuenta, como pedidos/correcciones/cancelaciones, están bloqueadas de forma predeterminada.
KIS_ENABLE_TRADING=trueLas APIs de cambio de estado solo se ejecutan si se configuran explícitamente los valores anteriores. Si solo utiliza APIs de consulta, no los configure.
Python >= 3.13
uv
Siga las instrucciones en INSTALL.md para la instalación. Los LLM o clientes MCP también deben leer este archivo primero al realizar la configuración.
INSTALL.md incluye el siguiente contenido:
Instalación de dependencias basada en uv
Creación de .env y configuración de KIS_APP_KEY, KIS_APP_SECRET, KIS_CANO, KIS_ACNT_PRDT_CD
Ejemplos de registro para Codex CLI, Claude Code, Claude Desktop y clientes MCP generales
Configuración KIS_MCP_TOOLSET=catalog para ahorrar contexto
Ejemplo de call-kis-api para consultar saldo, monto disponible para compra y precio actual
Preparación local rápida:
pip install uv
uv sync
cp .env.example .env
chmod 600 .envLuego, configure los siguientes valores en .env. Consulte INSTALL.md para obtener explicaciones detalladas de los valores y comandos de registro por cliente.
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.pyTambién se puede configurar mediante argumentos de línea de comandos.
uv run python server.py \
--app-key "앱키" \
--app-secret "시크릿키" \
--account-type "REAL" \
--cano "계좌번호" \
--acnt-prdt-cd "01"Selección de transporte:
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.pyEjemplo de registro de cliente MCP:
A continuación se muestra un ejemplo mínimo para un cliente MCP general. Utilice INSTALL.md para los comandos de Codex CLI, Claude Code y Claude Desktop.
{
"mcpServers": {
"kis-mcp-server": {
"command": "uv",
"args": ["run", "python", "server.py"],
"cwd": "<project-root>",
"env": {
"KIS_MCP_TOOLSET": "catalog",
"KIS_MCP_LOG_LEVEL": "WARNING"
}
}
}
}Herramienta | Descripción |
| Consulta de lista basada en grupo de API/término de búsqueda |
| Verificación de ruta, candidatos a TR_ID y parámetros de una sola API |
| Invocación de API de catálogo con |
list-kis-api-specs devuelve etiquetas, valores de ejemplo y códigos principales de los parámetros obligatorios.
get-kis-api-spec devuelve información de label, guide, examples, values, default y auto_fill de todos los parámetros, permitiendo al LLM verificar inmediatamente el formato de entrada necesario para la llamada.
call-kis-api realiza los siguientes procesos de forma común:
Entrada automática de número de cuenta/código de producto de cuenta basada en variables de entorno
Emisión y caché de tokens de autenticación
Configuración de solicitudes GET/POST
Selección automática de TR_ID de pedido entre múltiples candidatos
Aplicación de puerta de seguridad para APIs de cambio de estado
Rechazo predeterminado de parámetros no presentes en el catálogo
Las funciones de acciones nacionales/extranjeras de uso frecuente también se proporcionan como herramientas MCP separadas.
Herramienta | Descripción |
| Consulta de precio actual de acciones nacionales |
| Consulta de saldo de acciones nacionales |
| Consulta de pedidos/ejecuciones diarias de acciones nacionales |
| Consulta de detalles de pedidos de acciones nacionales |
| Consulta de cotizaciones diarias de acciones nacionales |
| Consulta de cotizaciones por período de acciones nacionales |
| Consulta de libro de órdenes de acciones nacionales |
| Consulta de precio actual de índices/sectores nacionales |
| Consulta de información básica de acciones nacionales |
| Consulta de precio actual de acciones extranjeras |
| Pedido de compra/venta de acciones nacionales |
| Pedido de compra/venta de acciones extranjeras |
Las herramientas de pedido tampoco se ejecutarán sin KIS_ENABLE_TRADING=true.
Al conectarse al servidor, los clientes MCP cargan los nombres, descripciones y esquemas de entrada de las herramientas en el contexto. Cuantas más herramientas de conveniencia se expongan, mayor será el uso de contexto al inicio de la conversación; por lo tanto, si es necesario, se puede utilizar un modo ligero que solo exponga las 3 herramientas de catálogo.
KIS_MCP_TOOLSET=catalog uv run python server.pyValor | Número de herramientas expuestas | Herramientas expuestas | Uso |
| 15 | Herramientas de catálogo + todas las de conveniencia | Compatible con el comportamiento existente |
| 3 |
| Bajo uso de contexto |
El modo catalog es para reducir la carga del esquema de herramientas MCP. Aunque oculta las herramientas de conveniencia, las 166 APIs se pueden seguir invocando a través de call-kis-api. Puede buscar la API necesaria con list-kis-api-specs y consultar los parámetros detallados necesarios con get-kis-api-spec en el momento.
Flujo de uso recomendado:
Busque la API con list-kis-api-specs.
Verifique los parámetros obligatorios, valores de ejemplo y códigos con get-kis-api-spec.
Invoque la API real con call-kis-api.
En la configuración del cliente MCP, solo necesita agregar variables de entorno.
{
"env": {
"KIS_MCP_TOOLSET": "catalog"
}
}Si desea exponer las herramientas de conveniencia de uso frecuente directamente en la lista de herramientas, utilice el valor predeterminado full.
call-kis-apiPrecio actual de acciones nacionales:
{
"group": "domestic_stock",
"api_type": "inquire_price",
"params": {
"fid_cond_mrkt_div_code": "J",
"fid_input_iscd": "005930"
}
}Saldo de acciones extranjeras:
{
"group": "overseas_stock",
"api_type": "inquire_balance",
"params": {
"ovrs_excg_cd": "NASD",
"tr_crcy_cd": "USD"
}
}Saldo actual de acciones extranjeras basado en ejecución:
{
"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"
}
}Monto disponible para compra de acciones extranjeras:
{
"group": "overseas_stock",
"api_type": "inquire_psamount",
"params": {
"ovrs_excg_cd": "NASD",
"ovrs_ord_unpr": "1",
"item_cd": "QQQ"
}
}Grupo | Descripción | Número de APIs |
| Autenticación | 2 |
| Acciones nacionales | 74 |
| Acciones extranjeras | 34 |
| Bonos nacionales | 14 |
| Futuros/Opciones nacionales | 20 |
| Futuros/Opciones extranjeras | 19 |
| ELW | 1 |
| ETF/ETN | 2 |
El ID completo de la API, la ruta, el TR_ID y la guía de parámetros obligatorios se resumen en API_CATALOG.md.
Nombre | Descripción | Valor predeterminado |
| Clave de aplicación KIS | - |
| Clave secreta KIS | - |
|
| - |
| Primeros 8 dígitos del número de cuenta | - |
| Código de producto de cuenta |
|
| Archivo de caché de token |
|
| Activación de API de pedido/corrección/cancelación | Desactivado |
| Alcance de exposición de herramientas MCP ( |
|
| Nivel de registro |
|
|
|
|
| Host HTTP/SSE |
|
| Puerto HTTP/SSE |
|
| Ruta HTTP/SSE |
|
uv run python -m compileall main.py server.py example.py tests
uv run python -m unittest discover -v
git diff --checkMIT
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…
