get_account_trendRetrieve daily account asset trends, returns, P&L, and cash flows over 2-90 days to answer 'How did my account change last month?'
일별 추정예탁자산(예수금·대용금 포함) 추이와 기간 수익률·평가손익·입출금 요약을 조회합니다 (키움 kt00002 + kt00016). "내 계좌가 지난 한 달간 어떻게 변했나" 같은 질문에 사용하세요 (기본 30일, 최대 90일). 모의투자에서는 지원되지 않는 조회입니다.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | 조회 기간(일) — 오늘부터 거슬러 계산 (2~90, 기본 30) |
Changes observed during successful MCP inspections.
v0.23.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses that the tool retrieves daily estimated data combining two sources, includes specific financial metrics, and has a usage limit (max 90 days). It does not mention side effects, authentication needs, or data freshness, but the read-only nature is implied and consistent with the tool's 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 very concise, consisting of two sentences that front-load the main purpose, then provide a usage example and limitation. No unnecessary words or repetition. It earns its place with clean structure.
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 has one well-documented parameter, no output schema, and no annotations, the description is complete: it explains what data is returned, the period range, and an important exclusion (simulated trading). No critical information is missing.
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 coverage is 100% for the single parameter 'days', with the schema already providing description and constraints. The description adds minimal extra value by repeating the default and max values and giving a usage example. Baseline 3 is appropriate as the description does not significantly augment the schema.
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 '조회' (retrieve) and the resource '계좌 자산·수익률 추이' (account asset/return trends), detailing specific components like daily estimated deposit assets and period returns. It distinguishes from siblings by mentioning it's not supported for simulated trading and by specifying the data sources (키움 kt00002 + kt00016).
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 a typical query example ('내 계좌가 지난 한 달간 어떻게 변했나'), default (30 days) and maximum (90 days) period, and explicitly states it is not supported for simulated trading. However, it does not explicitly compare with sibling tools or give when-not-to-use advice beyond the simulation restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.