Skip to main content
Glama

하나은행 빠른계좌조회 거래내역

hana_fast_account__accounts__transaction_history__search

REQUIRES prior hana_fast_account__session__login call with same account_link_id. Search transaction history for one registered Hana Bank fast-account using the existing provider session. Files: a document generated from this result, as Excel (xlsx) only when requested in output_formats, listed in artifacts[] of the result with a download_url that works for 15 minutes; each file is kept for 7 days. If a link has expired, call xdata__job__result with the job_id from the result for fresh links. For an anonymous result, keep its private recovery_receipt and send it with the original job_id or pack_run_id to xdata__job__result. It grants access to that result only, until the original file retention expires. Do not publish it. Losing it cannot be repaired by signing up. The receipt also works if the client later signs in; it does not grant access to other results. Without a receipt, results require the original account and lane. Send exactly one of bank_account_credential_id (one account), bank_account_credential_ids (several accounts) or all_accounts (every account). 계좌마다 사용 토큰이 하나씩 듭니다. 기업정보 브리프처럼 한 번에 여러 사용 토큰을 쓰는 업무는 그 값만큼 계좌마다 듭니다. For an authenticated call, generate and save request_idempotency_key before the first request. Reuse it with the same arguments only to recover that request after a lost response; use a new key for a new execution. Without it, calling again remains a new request. This optional key is not available to anonymous taste calls. Keep any provider-specific idempotency_key unchanged; it is a different field. 호출마다 토큰 1소진 요청 처리 시 XBOSS 작업을 생성하고 처리 결과를 저장합니다. 기관 원본의 조회 여부와 별개로 이 호출은 순수 읽기 전용이 아닙니다. 기관 데이터 변경은 도구별 실행 내용과 기존 확인 절차를 따릅니다.

Input Schema

NameRequiredDescriptionDefault
end_dateYesEnd date YYYY-MM-DD or YYYYMMDD
sort_orderNoTransaction time sort orderdesc
start_dateYesStart date YYYY-MM-DD or YYYYMMDD
all_accountsNoSet to true to run this once for every account registered for this bank. Each account is handled separately and uses the tokens this action costs. Send exactly one of bank_account_credential_id (one account), bank_account_credential_ids (several accounts) or all_accounts (every account).
output_formatsNoOptional. Also return this result as a file (Excel (xlsx)) in artifacts[] of the result. Omit it for data only.
account_link_idNoAccount link ID (UUID v4). Optional — the server auto-resolves from your API key when omitted. Provide explicitly only when you have multiple connections for the same provider.
transaction_typeNoTransaction direction filterall
request_idempotency_keyNoOptional same-request recovery key for authenticated calls; see the tool description.
bank_account_credential_idNobank_account_credential_id of one registered account - take it from this bank's accounts list tool
bank_account_credential_idsNobank_account_credential_id values from this bank's accounts list tool. Runs this once for each listed account. Each account is handled separately and uses the tokens this action costs. Send exactly one of bank_account_credential_id (one account), bank_account_credential_ids (several accounts) or all_accounts (every account).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / request_idempotency_key
      Added value: +{
      +  "description": "Optional same-request recovery key for authenticated calls; see the tool description.",
      +  "maxLength": 128,
      +  "minLength": 1,
      +  "pattern": "^[\\x20-\\x7E]+$",
      +  "type": "string"
      +}
  2. Added

TDQS

B3.4/5.0
Behavior4/5

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

The description adds meaningful context beyond the annotations: it states that each call consumes a token, that the call creates an XBOSS job and persists the result, and explicitly says the call is not purely read-only despite the underlying source being a lookup — which explains the readOnlyHint=false annotation rather than contradicting it. It also discloses file download_url validity (15 minutes) and retention (7 days) and the irrecoverable nature of the anonymous recovery_receipt. Much of this reads as pack-wide boilerplate, and it does not describe the returned transaction records themselves.

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 dense block that interleaves at least five unrelated topics: artifact/retention behavior, anonymous recovery_receipt handling, token cost, idempotency key protocol, and side-effect disclosure, partly in Korean. The core purpose is stated first but then buried, and large portions duplicate the schema verbatim ("Send exactly one of bank_account_credential_id ... all_accounts").

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

Completeness3/5

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

For a 10-parameter authenticated tool with no output schema, it covers prerequisites, artifact output, retention, retry semantics, and the expired-link escape hatch. It leaves the actual transaction payload undescribed (fields, volume, pagination across multi-account runs) and never clarifies the one-account vs multi-account scope conflict, which matters for correctly invoking it.

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 100%, so the schema already documents dates, sort_order, transaction_type, output_formats, and the three mutually exclusive account selectors. The description does add genuine semantics for request_idempotency_key (generate before the first request, reuse only to recover a lost response, new key for a new execution, unavailable to anonymous calls), which the schema defers to it. Otherwise it mostly restates parameter rules already present in the schema.

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

Purpose4/5

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

The description opens with a specific verb+resource ("Search transaction history for one registered Hana Bank fast-account") and names the required session prerequisite, so an agent can identify the operation. However, "for one registered fast-account" conflicts with the later statement that the tool accepts bank_account_credential_ids or all_accounts and runs once per account, muddying the scope.

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?

It gives a real prerequisite (prior hana_fast_account__session__login with the same account_link_id) and routes expired links to xdata__job__result, plus the one-vs-several-vs-all account selection rule. But there is no differentiation from the obvious sibling hana_fast_account__accounts__list, and the account-selection guidance is buried mid-paragraph amid unrelated receipt and idempotency text.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources