How do I use tossinvest-openapi-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tossinvest-openapi-mcp what are my current holdings?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tossinvest-openapi-mcp

by EthanKlocked

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

tossinvest-openapi-mcp

Safe-by-default local stdio MCP server for the official Toss Securities / 토스증권 Open API.

This package is an independent developer tool and is not affiliated with, endorsed by, or sponsored by Toss Securities.

This package is designed for developers who want read-only account, market, and order data in an MCP client, with optional order operations protected by multiple explicit safety gates.

Safety defaults

Uses only the official Toss Open API server: https://openapi.tossinvest.com
Starts without credentials; auth_status reports missing configuration instead of crashing.
Keeps OAuth access tokens in memory only.
On 401 invalid-token data API responses, discards the cached token, requests a fresh OAuth token, and retries the original request once.
auth_status separates token issuance from data endpoint reachability and reports whether a default TOSS_ACCOUNT_SEQ is configured.
Redacts API keys, secrets, bearer tokens, account headers, and account numbers from tool output/errors.
Trading is disabled by default.
v0.2 workflow tools are safety-first and preview-based: portfolio_snapshot → pre_trade_check → order_preview → approval → order_execute → order_status_summary.
order_preview stores preview contracts in memory only and never calls Toss order POST endpoints.
order_execute is intentionally fast: it rechecks only preview/confirmation/hash/env/delegated-authority gates, submits at most one order POST, and reports timeout/network ambiguity as unknown_execution_state for reconciliation before any manual retry.
Order tools default to dryRun=true.
Real create/modify/cancel operations require ENABLE_TRADING=true plus the operation-specific gate.
Confirmation is required by default.
Default max order amounts are 0 KRW and 0 USD.
BLOCKED_SYMBOLS takes precedence over ALLOWED_SYMBOLS.

Related MCP server: tossinvest-mcp

Install and run

This repository is currently distributed from GitHub source only. It has not been published to npm under an EthanKlocked-owned package.

Important: the unscoped npm name tossinvest-openapi-mcp is already used by a different npm package, so do not install or run that package expecting this repository's code.

Clone this repository, then install and build locally:

git clone https://github.com/EthanKlocked/tossinvest-openapi-mcp.git
cd tossinvest-openapi-mcp
npm install
npm run build
npm test

Run locally:

TOSS_API_KEY=... TOSS_SECRET_KEY=... node dist/index.js

Do not put real secrets in committed files. Prefer passing env vars from your local shell or MCP client secret manager.

MCP client configuration example

Use the local cloned path:

{
  "mcpServers": {
    "tossinvest": {
      "command": "node",
      "args": ["/absolute/path/to/cloned/tossinvest-openapi-mcp/dist/index.js"],
      "env": {
        "TOSS_API_KEY": "${TOSS_API_KEY}",
        "TOSS_SECRET_KEY": "${TOSS_SECRET_KEY}",
        "TOSS_ACCOUNT_SEQ": "${TOSS_ACCOUNT_SEQ}"
      }
    }
  }
}

If this project is later published to npm, use a package name owned by the maintainer, such as @ethanklocked/tossinvest-openapi-mcp, rather than the already-taken unscoped name.

Environment variables

Name	Default	Purpose
`TOSS_API_KEY`	unset	Toss Open API client id / API key.
`TOSS_SECRET_KEY`	unset	Toss Open API client secret.
`TOSS_ACCOUNT_SEQ`	unset	Optional default account sequence for account-scoped tools.
`ENABLE_TRADING`	`false`	Global gate for any real order operation.
`ENABLE_ORDER_CREATE`	`false`	Gate for real order create.
`ENABLE_ORDER_MODIFY`	`false`	Gate for real order modify.
`ENABLE_ORDER_CANCEL`	`false`	Gate for real order cancel.
`REQUIRE_CONFIRMATION`	`true`	Requires exact confirmation text for real order operations.
`MAX_ORDER_KRW`	`0`	Maximum allowed calculated KRW order amount.
`MAX_ORDER_USD`	`0`	Maximum allowed calculated USD order amount.
`ALLOWED_SYMBOLS`	unset	Optional comma-separated allow list.
`BLOCKED_SYMBOLS`	unset	Optional comma-separated block list; always wins over allow list.
`TOSS_REQUEST_TIMEOUT_MS`	`15000`	Timeout for OAuth, read-only, and order requests. Set `0` only for local debugging to disable the timeout.

Confirmation text for real order operations:

I understand this may place a real Toss Securities order

Tools

Read-only tools:

auth_status
accounts
holdings
prices
orderbook
trades
price_limits
candles
stock_info
stock_warnings
exchange_rate
market_calendar
orders_open
orders_closed
order_detail
buying_power
sellable_quantity
commissions

Workflow tools:

portfolio_snapshot — reads holdings, KRW/USD buying power, open orders, calculable position weights, account/accountSeq state, warning flags, and partial failures. Position weights use a KRW-converted, cash-inclusive denominator (holdings + KRW/USD cash buying power); when cashStatus is partial, omitted cash currencies are listed in omittedCashCurrencies.
pre_trade_check — separate read/check layer for candidate orders; returns canProceedDryRun, realOrderBlockedByDefault, checks, warnings, blockers, missing, estimate, and dataFreshness.
order_preview — creates an in-memory preview contract; returns previewId, requestHash, ttlSeconds, expiresAt, exact confirmationText, estimated amount/fee/cash/quantity checks, gate status, risk flags, and calculability notes. It never calls order POST endpoints. Default TTL: 90 seconds; max accepted TTL: 300 seconds.
order_execute — fast preview-based submission; requires previewId, matching requestHash, exact confirmation (I approve this exact Toss order preview), unexpired preview, env gates, and optional delegated-authority bounds. It does not run pre_trade_check in the hot path and does not add automatic order POST retry.
order_status_summary — read-only reconciliation summary for open/recently closed orders, state counts, filled/partial/canceled/rejected/replace-related states when present, and caveats for disappeared/replaced orders.

Trading tools:

order_validate — checks local gates only and never calls Toss order POST endpoints.
order_create — defaults to dry-run; real execution requires all create gates.
order_modify — defaults to dry-run; real execution requires all modify gates.
order_cancel — defaults to dry-run; real execution requires all cancel gates. When ALLOWED_SYMBOLS or BLOCKED_SYMBOLS is configured, real cancellation also requires caller-supplied request.symbol so local symbol policy can be evaluated before the POST. The server does not fetch order details before cancel because this would add a second API dependency and the official detail payload shape should be confirmed by users with live credentials before relying on it for safety.

Auth status and account selection

auth_status intentionally separates OAuth token issuance from actual data API reachability:

configured: required credential environment variables are present.
tokenAvailable: POST /oauth2/token succeeded.
dataApiReachable: a real read-only data check against GET /api/v1/accounts succeeded.
authenticated: true only when both token issuance and the data endpoint check succeed.
accountSeqConfigured: true when TOSS_ACCOUNT_SEQ is set.
accountSeqRequiredForAccountTools: true; account-scoped tools need either a per-call accountSeq or TOSS_ACCOUNT_SEQ.

Most market-data tools such as prices, orderbook, trades, and stock_info do not require accountSeq. Account-scoped tools such as holdings, orders_open, orders_closed, order_detail, buying_power, sellable_quantity, commissions, and real/dry-run order tools require accountSeq via the tool arguments or TOSS_ACCOUNT_SEQ.

Endpoint mapping

Tool	Method/path	Side effect
`auth_status`	`POST /oauth2/token`; then `GET /api/v1/accounts` when token issuance succeeds	Token/data reachability check only
`accounts`	`GET /api/v1/accounts`	Read-only
`holdings`	`GET /api/v1/holdings`	Read-only
`prices`	`GET /api/v1/prices`	Read-only
`orderbook`	`GET /api/v1/orderbook`	Read-only
`trades`	`GET /api/v1/trades`	Read-only
`price_limits`	`GET /api/v1/price-limits`	Read-only
`candles`	`GET /api/v1/candles`	Read-only
`stock_info`	`GET /api/v1/stocks`	Read-only
`stock_warnings`	`GET /api/v1/stocks/{symbol}/warnings`	Read-only
`exchange_rate`	`GET /api/v1/exchange-rate`	Read-only
`market_calendar`	`GET /api/v1/market-calendar/KR` or `GET /api/v1/market-calendar/US`	Read-only
`orders_open`	`GET /api/v1/orders?status=OPEN`	Read-only
`orders_closed`	`GET /api/v1/orders?status=CLOSED`	Read-only
`order_detail`	`GET /api/v1/orders/{orderId}`	Read-only
`buying_power`	`GET /api/v1/buying-power`	Read-only
`sellable_quantity`	`GET /api/v1/sellable-quantity`	Read-only
`commissions`	`GET /api/v1/commissions`	Read-only
`portfolio_snapshot`	Composes `GET /api/v1/holdings`, `GET /api/v1/buying-power`, and `GET /api/v1/orders?status=OPEN`	Read-only workflow snapshot
`pre_trade_check`	Composes market calendar, warnings, price limits, buying power/sellable quantity, commissions, and open orders	Read/check only; no order POST
`order_preview`	Local preview contract plus read/check calls	No Toss order POST; memory-only preview storage
`order_execute`	`POST /api/v1/orders` only after preview/confirmation/hash/env gates pass	At most one order POST; no automatic order POST retry
`order_status_summary`	`GET /api/v1/orders?status=OPEN` and `GET /api/v1/orders?status=CLOSED`	Read-only reconciliation
`order_validate`	Local gate evaluation only	No Toss order POST
`order_create`	`POST /api/v1/orders`	Real order only after all gates pass
`order_modify`	`POST /api/v1/orders/{orderId}/modify`	Real order modification only after all gates pass
`order_cancel`	`POST /api/v1/orders/{orderId}/cancel`	Real order cancellation only after all gates pass

v0.2 workflow examples

Recommended safety-first flow:

portfolio_snapshot → pre_trade_check → order_preview → user/delegated approval → order_execute → order_status_summary

Market calendar checks are routed by request market:

currency=KRW or a six-digit Korean stock symbol uses market_calendar(KR).
US tickers / currency=USD use market_calendar(US).
US non-business days are detected from the official calendar shape when result.today.dayMarket, preMarket, regularMarket, and afterMarket are all null.
KR non-business days are detected when result.today.integrated is null.
In those cases pre_trade_check and order_preview return a market_closed_non_business_day blocker with market, date, and nextBusinessDay; they do not report market_open_unknown in missing.

portfolio_snapshot example:

{
  "accountSeq": 1,
  "currencies": ["KRW", "USD"],
  "limit": 50
}

pre_trade_check example. This is a separate read/check tool and is intentionally not forced into order_execute's hot path:

{
  "accountSeq": 1,
  "request": {
    "symbol": "005930",
    "side": "BUY",
    "orderType": "LIMIT",
    "quantity": "1",
    "price": "70000",
    "currency": "KRW"
  },
  "delegatedAuthority": {
    "remainingAmount": 100000,
    "expiresAt": "2026-07-05T15:00:00.000Z"
  }
}

order_preview example. It never calls Toss order POST endpoints and returns previewId, requestHash, TTL, and exact confirmation text:

{
  "accountSeq": 1,
  "ttlSeconds": 90,
  "request": {
    "symbol": "005930",
    "side": "BUY",
    "orderType": "LIMIT",
    "quantity": "1",
    "price": "70000",
    "currency": "KRW"
  }
}

order_execute example. Copy the previewId, requestHash, and exact confirmationText from the preview response:

{
  "previewId": "preview_...",
  "requestHash": "<sha256-from-preview>",
  "confirmation": "I approve this exact Toss order preview"
}

If an order POST times out or returns an ambiguous network failure, order_execute returns status: "unknown_execution_state" and directs callers to reconcile with order_status_summary/order_detail before any manual retry. The server does not automatically retry order POSTs.

order_status_summary example:

{
  "accountSeq": 1,
  "symbol": "005930",
  "limit": 50
}

Trading safety examples

Dry-run validation:

{
  "request": {
    "symbol": "005930",
    "side": "BUY",
    "orderType": "LIMIT",
    "quantity": "1",
    "price": "70000",
    "currency": "KRW"
  }
}

Real create requires all of the following:

ENABLE_TRADING=true
ENABLE_ORDER_CREATE=true
REQUIRE_CONFIRMATION=true
MAX_ORDER_KRW=100000
ALLOWED_SYMBOLS=005930

And the tool call must include:

{
  "dryRun": false,
  "confirmation": "I understand this may place a real Toss Securities order",
  "request": {
    "symbol": "005930",
    "side": "BUY",
    "orderType": "LIMIT",
    "quantity": "1",
    "price": "70000",
    "currency": "KRW"
  }
}

Official endpoint mapping

The implementation is intentionally thin and maps tools to official Toss Open API paths:

OAuth: POST /oauth2/token
Market/account/order data: /api/v1/... paths from https://openapi.tossinvest.com/openapi-docs/latest/openapi.json
Order create/modify/cancel: official /api/v1/orders POST paths only, guarded locally before any POST is attempted.

Development

npm install
npm test
npm run lint
npm run audit:prod

The required test suite uses Node's built-in test runner and mocked fetch calls. It does not require real Toss credentials and does not call live order endpoints.

Opt-in read-only integration smoke test

After configuring your own Toss credentials locally, you can run a safe read-only smoke test:

TOSS_API_KEY=... TOSS_SECRET_KEY=... npm run smoke:readonly

Optional account-scoped checks can use TOSS_ACCOUNT_SEQ, but the default smoke path only calls read-only tools that do not create, modify, or cancel orders: auth_status, accounts, and market_calendar. If TOSS_API_KEY or TOSS_SECRET_KEY is missing, the command exits successfully with a SKIP message and makes no Toss API request. Output is passed through the same redaction helpers used by the MCP server.

Timeout/retry policy

This server applies a configurable request timeout to OAuth, read-only calls, and order calls. It intentionally does not add broad automatic retries: read-only retry policy should be based on observed Toss API behavior, and order POST retries are disabled unless official idempotency guarantees are documented. The only automatic retry remains the existing one-time token refresh/retry for a 401 invalid-token response.

Release checklist

Before publishing or tagging a release:

Verify package ownership and name availability; do not publish the unscoped tossinvest-openapi-mcp name.
Run npm test, npm run lint, npm run audit:prod, and npm pack --dry-run.
Confirm the dry-run tarball includes only runtime files (dist/ JavaScript/declarations without source maps), scripts/smoke-readonly.mjs, README.md, LICENSE, .env.example, and package metadata.
Re-scan docs for secrets, account numbers, local paths, private workflow notes, or investment advice/automation claims.
Publish only after explicit maintainer approval.

Publication hygiene

.gitignore excludes .env, .env.*, logs, coverage, node_modules, and build output.
.npmignore excludes local env files, logs, coverage, internal handoff/QA notes, and local run artifacts.
package.json files only publishes dist, public docs, .env.example, and changelog/security/license files.

Disclaimer

This software is not investment advice and does not implement trading strategy, rebalancing, optimization, or automated trading loops. Order tools can place real financial orders only when explicitly enabled and used with valid Toss credentials; use at your own risk.

Available Tools

27 tools

accountsA

List Toss Securities accounts. Account numbers are masked.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so the description carries the burden. It mentions account numbers are masked, which is useful, but lacks information on read-only nature or permissions.

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?

Two concise sentences with no wasted words. Front-loaded with the action and resource.

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?

For a simple parameterless tool, the description covers the core purpose and a key behavioral detail. It is complete enough without an output schema.

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?

No parameters exist, so schema coverage is 100%. The description adds context about masking, which is valuable but not about parameters per se. Baseline 4 applies.

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 clearly states 'List Toss Securities accounts' with a specific verb and resource, and it distinguishes from siblings which are about stocks, orders, etc.

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. It is implied but not stated.

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

auth_statusA

Check Toss API credential configuration and token status without returning secrets.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior4/5

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

The description explicitly states it does not return secrets, which is a key behavioral trait. Given no annotations, this adds value. However, it does not mention if the call requires prior authentication or what the response format looks like.

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, concise sentence that front-loads the core purpose and key behavioral constraint. No wasted words.

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?

For a simple parameter-less tool, the description covers the essential purpose and safety aspect. However, since there is no output schema, the description fails to hint at the return value structure, which could be valuable for the agent.

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?

With zero parameters and 100% schema coverage, the description adds no parameter details, but the baseline for 0-parameter tools is 4. There is no need for additional parameter semantics.

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 clearly states the tool checks Toss API credential configuration and token status, using a specific verb 'Check' and specifying the resource. It distinguishes itself from sibling tools which are primarily for trading data and order management.

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 on when to use this tool versus alternatives, nor any prerequisites or context for using the credential check.

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

buying_powerC

Read buying power for an account and currency.

ParametersJSON Schema

Name	Required	Description	Default
`currency`	Yes
`accountSeq`	No

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only says 'Read', implying no side effects, but lacks information on authentication needs, rate limits, or return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but under-specified. It fails to earn its place by omitting critical details for a tool with two parameters and no other documentation.

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

Completeness1/5

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

Given the lack of annotations and output schema, the description is inadequate. It does not cover return value structure, required permissions, or how to handle the optional 'accountSeq' parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It adds no meaning beyond the schema: it does not explain the format of 'currency' or the context of 'accountSeq'.

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 'read' and the resource 'buying power' with a scope of 'for an account and currency'. It is specific and distinguishes from sibling tools like 'sellable_quantity' or 'holdings'.

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 on when to use this tool versus alternatives. There is no mention of prerequisites, excluded scenarios, or better-suited tools.

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

candlesD

Read candles for a symbol.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`before`	No
`symbol`	Yes
`adjusted`	No
`interval`	Yes

TDQS

D1.6/5.0

Behavior1/5

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

No annotations and minimal description. Does not disclose behavioral traits such as read-only nature, output format, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short but under-specified. Conciseness is not beneficial when critical information is omitted.

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

Completeness1/5

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

With no annotations, no output schema, and 5 undocumented parameters, the description is severely incomplete. Does not enable correct tool selection or invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description adds no meaning to parameters like 'count', 'before', 'adjusted', 'interval'. Agent must guess their semantics from names alone.

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

Purpose3/5

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

The description 'Read candles for a symbol' clearly states the verb and resource, but does not differentiate from sibling tools like 'prices' or 'trades' which might also read time series data.

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

Usage Guidelines1/5

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

No guidance on when to use this tool versus alternatives. No context provided for appropriate use cases.

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

commissionsC

Read official Toss account commission rates.

ParametersJSON Schema

Name	Required	Description	Default
`accountSeq`	No

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only says 'Read' implying non-destructive, but fails to mention authentication needs, rate limits, or what happens if accountSeq is invalid. The behavior is under-communicated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it is too brief to provide sufficient context. It is front-loaded but lacks necessary details that would earn its place.

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 simple tool (one parameter, no output schema, no annotations), the description barely answers what it does. It omits details about the output format, error scenarios, and any prerequisites. The description is incomplete for an agent to use confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the tool description does not mention the accountSeq parameter. The description adds no meaning beyond the schema, which itself lacks parameter descriptions. The agent gets no help understanding what accountSeq is or how to format it.

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 clearly states the action ('Read') and the resource ('official Toss account commission rates'), which is a specific function that distinguishes it from sibling tools like stock_info or orders_open.

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 on when to use this tool over alternatives. For example, it doesn't clarify if this is the only way to get commission rates or if other tools might return similar data. The description lacks usage context.

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

exchange_rateC

Read exchange rate from official Toss API.

ParametersJSON Schema

Name	Required	Description	Default
`dateTime`	No
`baseCurrency`	Yes
`quoteCurrency`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations provided; description lacks details on rate limits, data freshness, error handling, or safety profile beyond the implicit read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but sacrifices essential detail; front-loaded but insufficiently informative.

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

Completeness1/5

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

No output schema, no parameter details, no behavioral context; lacks completeness for a tool with three parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and description provides no information about parameters such as dateTime format, baseCurrency, or quoteCurrency.

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?

Clearly states 'Read exchange rate from official Toss API', specifying the verb and resource uniquely among sibling tools.

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 on when to use this tool versus siblings, no context on prerequisites or limitations.

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

holdingsC

Read holdings for an account using X-Tossinvest-Account.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	No
`accountSeq`	No

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided. The description claims a read operation but does not confirm idempotency, data freshness, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, but it is too sparse to be considered well-structured. Conciseness is positive but incomplete.

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

Completeness1/5

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

Given no output schema, no annotations, and minimal description, the tool is severely under-documented. Missing return format, limitations, and behavioral details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. Parameters symbol and accountSeq are not explained in the description, leaving the agent without guidance on their purpose or usage.

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 it reads holdings for an account using a specific header. However, it does not differentiate from siblings like portfolio_snapshot or accounts, which might also return similar data.

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 on when to use this tool versus alternatives. No prerequisites or exclusions are mentioned.

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

market_calendarC

Read KR or US market calendar.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No
`market`	No		KR

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states 'Read' implying it's non-destructive, but lacks details on rate limits, data freshness, or whether it returns holidays, trading hours, or both.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While the description is very short, it omits critical information. It is not front-loaded with key details; it sacrifices completeness for brevity.

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 output schema and minimal parameter documentation, the description is insufficient. The tool has optional parameters but no explanation of calendar content or return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds zero meaning to parameters. It does not explain the 'date' format or the 'market' enum values beyond KR/US. The schema provides all available information.

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 clearly states the tool reads a market calendar for KR or US markets. It uses a specific verb ('Read') and resource ('market calendar'), and distinguishes itself from sibling tools by being the only calendar-related tool.

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 (e.g., for specific date ranges or market types). No context on preferred use cases or exclusions.

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

orderbookC

Read orderbook for a symbol.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

Annotations are missing, so the description carries full burden. It only states 'Read' but does not disclose data recency, depth levels, response structure, or any side effects. For a read operation, basic behavioral context is absent.

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 (5 words) with no fluff. However, the brevity sacrifices necessary detail, making it efficient but potentially insufficient.

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 no output schema and no annotations, the description should explain what the orderbook contains (e.g., bids/asks, levels) and return format. It fails to provide this, leaving the agent with incomplete understanding.

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%. The description adds no meaning beyond the schema's regex pattern for 'symbol'. It does not explain case sensitivity, valid formats, or how the symbol maps to the orderbook.

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 ('Read') and resource ('orderbook') with a specific context ('for a symbol'). It distinguishes itself from sibling tools like 'candles' and 'stock_info'.

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 on when to use this tool versus alternatives like 'candles' or 'prices'. No explicit conditions or when-not-to-use scenarios are provided.

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

order_cancelA

Cancel an order. Default dry-run; real execution requires ENABLE_TRADING, ENABLE_ORDER_CANCEL, dryRun=false, confirmation, and caller-supplied request.symbol when symbol allow/block policy is configured.

ParametersJSON Schema

Name	Required	Description	Default
`dryRun`	No
`orderId`	Yes
`request`	No
`accountSeq`	No
`confirmation`	No

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. Discloses default dry-run behavior and prerequisites for real execution, but omits side effects, success/failure indications, or auth requirements. Partial disclosure, not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but becomes a run-on list of conditions. Could benefit from structuring (e.g., bullet points) to improve readability without losing brevity.

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 5 parameters (1 required), no output schema, and no annotations, the description fails to cover return values, error handling, or parameter usage like accountSeq and request. Insufficient for agents to confidently invoke the tool.

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 coverage is 0%. Description only hints at dryRun (default) and confirmation, but does not explain orderId, accountSeq, or request object. Most parameters lack any semantic addition, leaving agents to infer from names alone.

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 clearly states 'Cancel an order' as the primary action, which is a specific verb+resource combination. Among siblings like order_create, order_modify, order_execute, it is distinct as the cancellation tool.

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?

Provides explicit conditions for real execution (ENABLE_TRADING, ENABLE_ORDER_CANCEL, dryRun=false, confirmation, and caller-supplied request.symbol when policy is configured). Implies dry-run is for testing, but does not explicitly state when not to use or name alternatives.

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

order_createA

Create an order. Default dry-run; real execution requires ENABLE_TRADING, ENABLE_ORDER_CREATE, dryRun=false, confirmation, amount, and symbol gates.

ParametersJSON Schema

Name	Required	Description	Default
`dryRun`	No
`request`	Yes
`accountSeq`	No
`confirmation`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the default dry-run behavior and the multiple gates required for real execution. However, it lacks details about side effects, return value, or what happens on failure, which would further improve 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 two sentences with no redundant words. The first sentence clearly states the core function; the second packs key usage conditions efficiently. Every sentence adds value.

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 (4 parameters, 1 required, nested request object, no output schema), the description is insufficient. It does not explain the structure of the 'request' object, what confirmation entails, or the response format. This leaves significant ambiguity for an agent.

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 description coverage is 0%, so the description must compensate. It explains dryRun's role and mentions confirmation, but does not clarify the 'request' object (which is required and nested with additionalProperties) or accountSeq. This partial coverage earns a 3.

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 clearly states 'Create an order' as a verb+resource combination. Among sibling tools like order_modify, order_cancel, and order_preview, this uniquely identifies the creation action, distinguishing it effectively.

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

Usage Guidelines5/5

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

The description explicitly details when to use the tool: default dry-run mode, and the conditions for real execution (ENABLE_TRADING, ENABLE_ORDER_CREATE, dryRun=false, confirmation, amount, and symbol gates). This provides clear context and exclusions for safe invocation.

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

order_detailC

Read one order detail for an account.

ParametersJSON Schema

Name	Required	Description	Default
`orderId`	Yes
`accountSeq`	No

TDQS

C2.2/5.0

Behavior2/5

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

With no annotations provided, the description fails to disclose behavioral traits beyond the implied read-only nature. It does not mention authentication requirements, error conditions, or any other side effects. The word 'read' suggests non-destructive behavior but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (one sentence) and concise, but it lacks structure and necessary details. It is not front-loaded with key information beyond the purpose.

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

Completeness1/5

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

Given the tool has 2 parameters, no output schema, and many siblings, the description is severely incomplete. It does not specify what the tool returns, how to use the parameters, or any context about the account.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain the meaning or usage of the two parameters ('orderId' and 'accountSeq'). Since the schema description coverage is 0%, the description should compensate but fails to do so.

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 'read' and resource 'one order detail' and the scope 'for an account'. It distinguishes itself from sibling tools like 'order_create' or 'order_cancel' by specifying it is a read operation. However, it could be more specific about what 'order detail' includes.

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

Usage Guidelines1/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 'order_status_summary' or 'orders_open'. There is no mention of prerequisites, context, or when not to use it.

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

order_executeB

Fast preview-based order execution. Requires valid unexpired previewId, matching requestHash, exact confirmation, and passing env/delegated-authority gates. No automatic order POST retry.

ParametersJSON Schema

Name	Required	Description	Default
`previewId`	Yes
`requestHash`	Yes
`confirmation`	Yes
`delegatedAuthority`	No

TDQS

B3.1/5.0

Behavior3/5

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

Without annotations, the description discloses 'fast', 'preview-based', and 'no automatic retry'. However, it omits side effects, error states, and success behavior. The disclosure is partial.

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 concise sentences with no wasted words. Could be improved with clearer structure (e.g., bullet points for requirements), but overall efficient.

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?

With 4 parameters, no output schema, no annotations, and many sibling tools, the description is too brief. It fails to explain the execution flow, return values, or how to obtain previewId/requestHash, leaving the agent underinformed.

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 coverage is 0%, so description must explain parameters. It only implicitly mentions previewId and requestHash in the requirement list, but does not clarify confirmation format or delegatedAuthority object. Meaning is lacking.

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 it's for preview-based order execution, with a specific verb ('execute') and resource ('order'). It implies a link to order_preview, but does not explicitly differentiate from sibling order_create.

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

Usage Guidelines3/5

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

Lists prerequisites (previewId, requestHash, confirmation, gates) but does not specify when to use vs alternatives like order_create or order_validate, nor when not to use.

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

order_modifyA

Modify an order. Default dry-run; real execution requires ENABLE_TRADING, ENABLE_ORDER_MODIFY, dryRun=false, confirmation, and applicable gates.

ParametersJSON Schema

Name	Required	Description	Default
`dryRun`	No
`orderId`	Yes
`request`	Yes
`accountSeq`	No
`confirmation`	No

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It reveals the default dry-run mode and prerequisites for execution, but omits behavioral details such as whether modifications are partial or full replacements, error handling, or side effects. The impact of the 'request' parameter is unclear.

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 very concise, consisting of a single sentence that efficiently conveys the core purpose and key constraints. However, it could be slightly more structured without adding length, such as separating the dry-run note from the execution requirements.

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 (5 parameters, nested 'request' object, no output schema), the description lacks completeness. It fails to explain the structure of the 'request' object, expected inputs, return values, or error conditions, leaving the agent underinformed for correct 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?

Despite 0% schema description coverage, the description only adds meaning for the 'dryRun' parameter by stating the default. Other critical parameters like 'orderId', 'request', 'accountSeq', and 'confirmation' are left undefined, providing minimal value beyond their names.

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 clearly states the tool's purpose as modifying an order, with a specific verb and resource. The name 'order_modify' and the verb 'modify' differentiate it from sibling tools like order_create, order_cancel, etc., which have distinct verbs.

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?

The description provides usage context by noting the default dry-run behavior and the requirements for real execution (e.g., ENABLE_TRADING, dryRun=false, confirmation). However, it does not explicitly guide the agent on when to use this tool versus alternatives like order_validate or order_preview.

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

order_previewB

Create an in-memory preview contract for an order. Never calls Toss order POST endpoints. order_execute confirmation text: I approve this exact Toss order preview

ParametersJSON Schema

Name	Required	Description	Default
`date`	No
`request`	Yes
`accountSeq`	No
`ttlSeconds`	No
`delegatedAuthority`	No

TDQS

B3.1/5.0

Behavior3/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. It discloses that no POST calls are made and mentions the in-memory nature, but omits details such as authentication requirements, error handling, return format, or what happens on success/failure.

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 extremely concise: three short sentences. The first sentence immediately states the primary action, the second clarifies a key behavioral trait, and the third provides a specific usage hint. No extraneous content.

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 (5 parameters, nested objects, no output schema), the description is insufficient. It fails to explain what an 'in-memory preview contract' produces, how the parameters affect the preview, or how the result compares to similar tools like order_validate. Significant completeness gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 5 parameters with 0% description coverage, and the tool description provides zero explanation of any parameter (e.g., request, date, accountSeq, ttlSeconds, delegatedAuthority). This is a critical gap for an agent to correctly invoke the tool.

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 that the tool creates an 'in-memory preview contract' and explicitly distinguishes itself from actual order submission by noting it never calls Toss order POST endpoints. The purpose is clear, but the concept of a 'preview contract' could be more precisely defined.

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

Usage Guidelines3/5

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

The description implies it is a safe dry-run tool ('never calls POST endpoints') and provides the confirmation text needed for order_execute, but does not explicitly state when to use this tool versus siblings like order_validate or order_create, nor does it give exclusion criteria.

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

orders_closedB

Read closed orders for an account if supported by Toss API.

ParametersJSON Schema

Name	Required	Description	Default
`to`	No
`from`	No
`limit`	No
`cursor`	No
`symbol`	No
`accountSeq`	No

TDQS

B3.4/5.0

Behavior3/5

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

Describes a read-only operation with no destructive behavior. However, no annotations are provided, so the description must stand alone. It does not mention pagination, rate limits, or authentication requirements, which are minimal for a read endpoint but still relevant.

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?

Single sentence, no fluff. However, it is too brief for a tool with 6 parameters; a bit more detail could be added without losing conciseness.

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 (6 parameters, no output schema, no annotations), the description is insufficient. It does not explain how to use parameters or what the return value looks like, leaving the agent under-informed.

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?

No explanation of the 6 parameters despite 0% schema description coverage. The description does not mention any parameter, leaving the agent to rely solely on the schema, which lacks descriptions for all parameters.

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?

Clearly states the action (Read closed orders) and the resource (for an account). The phrase 'if supported by Toss API' adds a necessary condition. Distinguishes from siblings like orders_open.

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

Usage Guidelines3/5

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

Implies that this tool is for closed orders, and the sibling orders_open is for open orders, but does not explicitly state when to use this tool instead of others. The 'if supported' is a prerequisite but not usage guidance.

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

orders_openC

Read open orders for an account.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`symbol`	No
`accountSeq`	No

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description solely implies a read-only operation. No details on pagination, rate limits, auth requirements, or data freshness are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it omits essential context and parameter information, making it minimally acceptable.

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

Completeness1/5

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

Given the tool has 3 optional parameters, no output schema, and many siblings, the description is highly incomplete. It fails to explain return values, filtering behavior, or how accountSeq is used.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description mentions none of the three parameters (limit, symbol, accountSeq). The agent receives no explanation beyond 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 'Read open orders for an account', specifying the verb (read) and resource (open orders), and distinguishes from sibling tools like orders_closed. However, it lacks detail about optional filtering.

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 (e.g., orders_closed, order_detail). No usage context or exclusions are mentioned.

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

order_status_summaryC

Read-only order reconciliation summary for open and recently closed orders, state counts, and replace/modify caveats.

ParametersJSON Schema

Name	Required	Description	Default
`to`	No
`from`	No
`limit`	No
`cursor`	No
`symbol`	No
`accountSeq`	No

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It states 'read-only' and vaguely mentions 'caveats', but fails to detail what caveats exist, data freshness, pagination, or return format, leaving significant uncertainty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is compact, but it omits critical details like parameter meaning and output structure, making it under-specified rather than efficiently concise.

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 6 parameters, no output schema, many sibling tools, and no annotations, the description is insufficient. It lacks information on return values, parameter roles, and behavioral specifics needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description does not mention any of the 6 parameters (to, from, limit, cursor, symbol, accountSeq), providing no guidance on their purpose or usage.

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 it provides a 'read-only order reconciliation summary for open and recently closed orders, state counts, and replace/modify caveats', distinguishing it from sibling tools like orders_open, orders_closed, and order_detail by focusing on a summary view.

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

Usage Guidelines3/5

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

The description implies use for high-level summary via 'reconciliation summary', but lacks explicit guidance on when to prefer this over siblings (e.g., orders_open for individual open orders) or prerequisites.

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

order_validateC

Validate order safety gates only. Never calls Toss order POST endpoints. Confirmation text: I understand this may place a real Toss Securities order

ParametersJSON Schema

Name	Required	Default
`dryRun`	No
`request`	Yes
`operation`	No	create
`confirmation`	No

TDQS

C2.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states the tool validates only and avoids POST calls, but the required confirmation text contradicts this by implying a real order may be placed. This inconsistency undermines transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short with two sentences and a required confirmation line. However, the confirmation text is poorly integrated and creates confusion, making it less effective despite brevity.

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

Completeness1/5

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

Given no output schema, a complex nested request object, and no behavioral details, the description fails to provide sufficient context for correct usage. Users cannot infer expected inputs, outputs, or error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description only mentions the confirmation parameter. The dryRun, request, and operation parameters are not explained, leaving their meaning and usage unclear.

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

Purpose3/5

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

The description states it validates order safety gates and never calls POST endpoints, indicating a read-only validation tool. However, it does not define what 'safety gates' are, and the confirmation text suggests a possible order execution, creating ambiguity.

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 on when to use this tool versus siblings like pre_trade_check or order_preview. The only hint is that it never calls POST endpoints, implying safety, but no explicit comparison or usage conditions.

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

portfolio_snapshotA

Read a structured account snapshot: holdings, KRW/USD buying power, open orders, calculable position weights, warning flags, and partial failures. Position weights use a KRW-converted, cash-inclusive denominator (holdings + KRW/USD cash buying power); when cashStatus is 'partial', omitted cash currencies are listed in omittedCashCurrencies. If status is 'partial', do not trust holdings.count as a complete account position count; retry or use a fallback read path.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`accountSeq`	No
`currencies`	No

TDQS

A4.4/5.0

Behavior5/5

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

Discloses important behavioral traits: position weight calculation using KRW-converted cash-inclusive denominator, partial cash behavior with omittedCashCurrencies, and warning about holdings.count on partial status. No annotations to contradict; description adds full context.

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?

Description is fairly detailed but well-structured. Front-loads the purpose. Some redundancy in explaining position weights, but overall efficient.

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 no output schema, the description thoroughly explains what the snapshot contains, including edge cases and calculation details. Covers partial failures and warnings, making it complete for agent decision-making.

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 0%, so description should compensate, but parameters (limit, accountSeq, currencies) are straightforward and their semantics are clear from the schema. The description does not add extra parameter meaning, but the schema is sufficient.

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?

Clearly states it reads a structured account snapshot including holdings, buying power, open orders, position weights, warning flags, and partial failures. Distinguishes itself from sibling tools like holdings or orders_open by being a composite snapshot.

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?

Provides guidance on what to do when status is 'partial' (do not trust holdings.count, retry or use fallback). Also explains the denominator for position weights. However, does not explicitly compare to alternatives like individual endpoints.

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

pre_trade_checkB

Run separate pre-execution safety/reality checks for a candidate order. Read/check only; not required in order_execute hot path.

ParametersJSON Schema

Name	Required	Description	Default
`date`	No
`request`	Yes
`accountSeq`	No
`delegatedAuthority`	No

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations, the description adds 'Read/check only', disclosing non-destructive behavior. But it lacks details on side effects, authorization, rate limits, or what exactly is checked. Adequate but minimal.

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?

Two concise sentences, front-loaded with purpose and followed by behavioral context. No wasted words.

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 has 4 parameters (1 required), nested objects, no output schema, and many siblings, the description lacks essential details about input structure, return value, and relationship to similar validation tools. Incomplete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description provides zero information about the four parameters (date, request, accountSeq, delegatedAuthority). This is a critical 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 indicates the tool runs pre-execution safety/reality checks (verb) for a candidate order (resource). It distinguishes itself as separate and not required in the order_execute hot path, but doesn't differentiate from siblings like order_validate or order_preview.

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

Usage Guidelines3/5

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

The description implies usage before order execution and states it's optional ('not required in order_execute hot path'). However, it provides no explicit when-to-use, when-not-to-use, or alternatives among sibling tools like order_validate.

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

price_limitsB

Read upper/lower price limits for a symbol.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

The description indicates a read operation with no side effects, but no annotations are present to confirm. The description does not add additional behavioral context beyond what is implied.

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?

A single, concise sentence that is front-loaded. No unnecessary words.

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?

The description lacks details about what the price limits represent, the return format, or any additional context needed for correct usage, especially given the absence of an output schema.

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?

With 0% schema description coverage, the description adds context by linking the symbol parameter to the tool's purpose, but it does not elaborate on format or constraints beyond the schema's pattern.

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 it reads upper/lower price limits for a symbol, using a specific verb and resource. However, it does not differentiate from sibling tools like 'prices' or 'stock_info' which might also provide price-related data.

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 on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned.

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

pricesA

Read current prices for comma-separated symbols.

ParametersJSON Schema

Name	Required	Description	Default
`symbols`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Indicates read operation but lacks details on error handling, rate limits, or what happens with invalid symbols. Minimal 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?

Single sentence, no wasted words, front-loaded with essential information. Highly efficient.

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?

Adequate for a simple read tool with one parameter. No output schema, but description covers input format. Slight gap in output description, but overall complete enough.

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?

Schema has 0% coverage; description adds meaning by specifying 'comma-separated symbols', clarifying input format beyond the schema pattern. Slightly improves understanding.

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?

Description clearly states verb 'read', resource 'current prices', and method 'comma-separated symbols'. Distinguishes from siblings like 'candles' (historical) and 'exchange_rate' (currency).

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 on when to use this tool versus alternatives like 'candles' or 'stock_info'. No when-not-to-use or prerequisites stated.

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

sellable_quantityC

Read sellable quantity for an account and symbol.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes
`accountSeq`	No

TDQS

C2.4/5.0

Behavior2/5

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

No annotations exist, so the description fully carries the burden. It only states 'read' but gives no details about behavior (e.g., what happens if accountSeq is missing, error handling, or data freshness).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence is concise but lacks critical details. Every word is functional, but the description is under-specified rather than efficiently informative.

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?

With no output schema and only two parameters poorly explained, the agent lacks sufficient context to invoke the tool correctly. The description does not mention return format, common errors, or parameter interplay.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%; the description adds no parameter explanations. 'For an account and symbol' is vague and does not clarify the meaning of 'accountSeq' or the symbol pattern, leaving the agent to rely solely on the schema which has minimal info.

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 reads sellable quantity for an account and symbol, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'prices' or 'holdings', which might also involve quantity concepts.

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 on when to use this tool vs alternatives. No prerequisites, context, or exclusions provided.

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

stock_infoC

Read basic stock info for comma-separated symbols.

ParametersJSON Schema

Name	Required	Description	Default
`symbols`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

The verb 'Read' implies idempotent read-only behavior, but no annotations are provided to confirm safety. No mention of rate limits, authentication needs, or return structure. The description does not disclose potential side effects or limitations.

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 sentence of 9 words, highly concise and front-loaded with the action. Every word is necessary with no redundancy.

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 tool with no output schema and sparse parameter info, the description lacks details on return values, error handling, or usage limits. Given the number of sibling tools, more context (e.g., typical use cases, example output) would aid agent decision-making.

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 meaning to the 'symbols' parameter by stating it expects comma-separated symbols, which partially compensates for the 0% schema description coverage. However, it does not specify valid symbol formats, case sensitivity, or provide examples.

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 (Read) and resource (basic stock info) and specifies input format (comma-separated symbols). It adequately distinguishes from sibling tools like candles or stock_warnings, though it could explicitly list what data fields are included.

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 on when to use this tool vs alternatives such as candles for historical price data or stock_warnings for alerts. The description does not provide context for selection.

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

stock_warningsC

Read buy-warning information for a stock.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It indicates a read operation but omits details on side effects, data sensitivity, rate limits, or authentication requirements, which are critical for a financial tool.

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 concise and front-loaded with the key action and resource. However, it could include additional context without becoming overly long, such as mentioning typical use cases or output format.

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 single parameter and no output schema or annotations, the description is too minimal. It lacks information about the output structure, possible return values, or edge cases, making it incomplete for confident tool selection and 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?

The description adds no meaning to the 'symbol' parameter beyond its name and the schema's pattern constraint. With 0% schema description coverage, the description should explain the format or source of valid symbols, but it does not.

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 ('Read') and the resource ('buy-warning information for a stock'), distinguishing it from sibling tools like 'stock_info' or 'prices'. However, the term 'buy-warning information' could be more specific, leaving some ambiguity about what exactly is returned.

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 on when to use this tool versus alternatives such as 'stock_info' or 'trades'. The description does not specify scenarios, prerequisites, or exclusions, leaving the agent to infer usage context.

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

tradesC

Read recent trades for a symbol.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No
`symbol`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

Annotations are not provided, so description carries full burden. It implies a read-only operation ('read recent trades'), which is appropriate, but lacks details on data freshness or any filtering behavior. No contradictions.

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?

Extremely concise single sentence with no wasted words. Structure is front-loaded with the key action and resource.

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 tool with two parameters and no output schema, the description is too sparse. It does not clarify what 'recent' means (time window), how 'count' affects results, or the format of the output. Incomplete for effective 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?

Schema description coverage is 0%. The description does not explain the 'count' parameter or provide any additional meaning beyond the schema's type constraints. The 'symbol' parameter is implied but not described.

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?

Description uses specific verb 'read' and resource 'recent trades' with 'for a symbol', clearly stating the action and target. It distinguishes from sibling tools like orders and portfolio by focusing on trade history, but does not explicitly contrast.

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 on when to use this tool versus alternatives (e.g., orders, candle). No context about prerequisites or when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

27 tool updatesv0.2.0Jul 29, 2026
- First observedaccounts
- First observedauth_status
- First observedbuying_power
- First observedcandles
- First observedcommissions
- First observedexchange_rate
- First observedholdings
- First observedmarket_calendar
- First observedorder_cancel
- First observedorder_create
- First observedorder_detail
- First observedorder_execute
- First observedorder_modify
- First observedorder_preview
- First observedorder_status_summary
- First observedorder_validate
- First observedorderbook
- First observedorders_closed
- First observedorders_open
- First observedportfolio_snapshot
- First observedpre_trade_check
- First observedprice_limits
- First observedprices
- First observedsellable_quantity
- First observedstock_info
- First observedstock_warnings
- First observedtrades

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.7/5.0

Scored 2026-07-29 07:25 across 27 tools

Disambiguation3/5

Many tools related to orders (e.g., orders_open, orders_closed, order_detail, order_validate, order_preview, order_execute, order_create, order_modify, order_cancel) have similar purposes but descriptions help distinguish them. Some overlap exists, such as between order_validate and order_preview, but they are not identical.

Naming Consistency4/5

All tool names use lowercase with underscores, but they are not strictly verb_noun; many are noun phrases (e.g., stock_info, exchange_rate, portfolio_snapshot) or adjective_noun (e.g., orders_open, orders_closed). The pattern is consistent in structure, though not perfectly verb_noun.

Tool Count3/5

With 27 tools, the server is on the upper end of a reasonable range. While a trading platform may require many tools, some could be combined (e.g., orders_open and orders_closed into one with a parameter) to reduce count without loss of functionality.

Completeness4/5

The tool surface covers market data, account information, order management, and safety checks comprehensively. Minor gaps exist, such as no explicit tool for deposit/withdrawal history, but core trading workflows are well-supported.

Maintenance

ActivityStale

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

MCP Server for Zerodha Kite Connect APIOAuth
io.github.Sundeepg98
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.
Finance Search Monitoring
2
openmm-mcp A
io.github.QBT-Labs
MCP server for OpenMM — exposes market data, account, trading, and strategy tools to AI agents
Finance
1513
schwab-mcp A
io.github.lonniev
Multi-tenant FastMCP server for Charles Schwab brokerage data, monetized via DPYC Tollbooth
Finance Data Platforms
642
stocksense-ai
io.github.doc2mcp
MCP server for stocksense-ai documentation, generated by doc2mcp.
Documentation Access Finance
24

Related MCP Servers

tossinvest-mcp
Finance
ryum91
A
license
A
quality
D
maintenance
MCP server wrapping Toss Securities Open API, enabling stock price queries and trading for Korean and US stocks via natural language.
Updated 3 months ago (2026-06-14 14:47 UTC)
36
7 npm
MIT
tossinvest-mcp
Finance Search
scjang01
A
license
A
quality
A
maintenance
Toss Securities (토스증권) Open API MCP server for the Korean stock market. Supports real-time quotes, orderbook, candles, account holdings, buying power, and order management (create/modify/cancel) with a built-in safety gate requiring explicit confirmation before any real order is placed.
Updated 3 months ago (2026-06-26 15:59 UTC)
17
7 npm
3
MIT
tossinvest-api-mcp
Finance Developer Tools
Kuco-dev
A
license
A
quality
B
maintenance
A local MCP server that automatically generates tools from Toss Securities' official OpenAPI spec, enabling real API calls with multi-layered order safety and OAuth 2.0 authentication.
Updated 2 months ago (2026-07-28 08:17 UTC)
36
1
MIT
tossinvest-mcp
Finance
meteoroh
F
license
A
quality
B
maintenance
MCP server for Toss Securities Open API that exposes Korean (KRX) and US market data, portfolio holdings, order management, and conditional orders through 28 tools, with read-only and authenticated remote modes.
Updated a month ago (2026-07-31 05:47 UTC)
28
-