tossinvest-mcp

Get trading commission rates

tossinvest_get_commissions

Read-onlyIdempotent

Get trading commission rates for Korean and US markets to estimate transaction costs before ordering or reconcile gross versus after-cost profit.

Instructions

Get the account's trading commission rates for the Korean and US markets.

Use this to estimate trading costs before ordering, or to explain the gap between gross and after-cost profit in holdings.

Args:

account_seq (number, optional): resolved automatically for single-account credentials.
response_format ('markdown' | 'json'): default 'markdown'.

Returns { accountSeq, count, commissions: [{ marketCountry, commissionRate, startDate, endDate }] }. commissionRate is a PERCENT: '0.015' means 0.015% of notional, i.e. multiply notional by 0.00015. startDate/endDate bound a promotional rate; both are null for US, and endDate is null for an open-ended rate.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`account_seq`	No	accountSeq of the account to act on (the `X-Tossinvest-Account` header). Optional: falls back to TOSSINVEST_ACCOUNT_SEQ, then to the sole account on the credentials. Get valid values from tossinvest_list_accounts.
`response_format`	No	Output format: 'markdown' for a compact human-readable summary, 'json' for the complete raw payload.	markdown

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes
`accountSeq`	Yes
`commissions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. Beyond that, the description adds rich context: commissionRate is a percentage requiring multiplication by 0.00015, and startDate/endDate have specific null semantics for US and open-ended rates. This is exactly the kind of behavioral detail an agent needs.

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 well-structured: purpose first, use cases second, then args and return semantics. It is efficient, though the Args section partly duplicates the input schema descriptions, making it slightly redundant for an agent that can read the schema.

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

Completeness5/5

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

Given the read-only annotations, full schema coverage, and an output schema, the description is complete. It explains the return shape, the meaning of commissionRate, and the null behavior of date bounds, so an agent can correctly interpret results without additional inference.

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?

Schema coverage is 100%, and the schema already documents account_seq fallback behavior and response_format meaning. The description's Args section mostly restates this, adding little beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get the account's trading commission rates for the Korean and US markets.' This clearly distinguishes it from the many sibling get_* tools, none of which target commission rates.

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?

It gives explicit use cases: 'Use this to estimate trading costs before ordering, or to explain the gap between gross and after-cost profit in holdings.' It doesn't name alternative tools or exclusions, but for this read-only commission tool the use-case guidance is clear and sufficient.

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

Deploy Server