KIS REST API MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 2.8/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/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 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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/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 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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![KIS_MCP_Server MCP server](https://glama.ai/mcp/servers/migusdn/KIS_MCP_Server/badges/card.svg)](https://glama.ai/mcp/servers/migusdn/KIS_MCP_Server)

Score Badge

Copy to your README.md:

[![KIS_MCP_Server MCP server](https://glama.ai/mcp/servers/migusdn/KIS_MCP_Server/badges/score.svg)](https://glama.ai/mcp/servers/migusdn/KIS_MCP_Server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/migusdn/KIS_MCP_Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server