tossinvest-mcp

Overview Schema Source Related Servers Discussions Admin

list_accounts

Read-onlyIdempotent

Retrieve brokerage account records and account_seq values to identify accounts for other account tools; only the last four digits of account numbers are shown.

Instructions

계좌 목록을 조회한다. 다른 계좌 tool 의 account_seq 값을 여기서 확인한다.

종합매매(BROKERAGE) 계좌만 나온다. 계좌 번호는 끝 4자리만 보여준다.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_accounts"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses two important behaviors: results are filtered to BROKERAGE accounts only, and account numbers are masked to the last 4 digits. Those are exactly the kind of scope and data-shaping facts an agent cannot get from annotations. Pagination and result size are not mentioned.

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?

Two short sentences, front-loaded with the action, followed by the key scoping facts (BROKERAGE-only, masked numbers). No filler, though the dashed-line separation suggests a slightly fragmentary structure.

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

Completeness4/5

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

With no output schema and no parameters, the description must convey what the agent gets back; it names account_seq and explains the filtering and masking, which covers the decision-relevant return behavior. It omits any other returned fields (e.g., account name/type labels) and ordering, a minor gap for a simple list tool.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate on the input side. Its mention of account_seq is about downstream usage rather than this tool's own inputs, which is appropriate.

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 opens with a specific verb+resource ("계좌 목록을 조회한다" / retrieve account list) and adds a second sentence explaining its role as the source of account_seq for other account tools. It does not need to differentiate against most siblings (which are market-data tools), though it never names a contrasting tool explicitly.

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

Usage Guidelines4/5

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

"다른 계좌 tool 의 account_seq 값을 여기서 확인한다" tells the agent this tool is the prerequisite step for tools needing account_seq, which is clear usage routing. It stops short of stating when NOT to call it or what prerequisites/auth it needs itself.

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