Skip to main content
Glama

통신판매 사업자 조회

opendata__ftc__mail_order

공공데이터포털에 개방된 통신판매사업자 등록현황(data.go.kr 15126311)을 상호 또는 사업자등록번호로 조회합니다. 상호(bzmnNm)로 검색하면 온라인 판매를 신고한 사업자를 찾아 사업자등록번호를 함께 돌려주어 다른 조회로 이어 갈 수 있습니다. 전체 건수는 total_count 에 담고, 결과가 비어 있어도 그 상호의 사업자가 없다는 뜻은 아닙니다. 통신판매를 신고하지 않은 사업자와 오프라인 사업자는 이 자료에 없을 수 있습니다. 별도 연동 없이 사용할 수 있습니다. 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 작업을 생성하고 처리 결과를 저장합니다. 기관 원본의 조회 여부와 별개로 이 호출은 순수 읽기 전용이 아닙니다. 기관 데이터 변경은 도구별 실행 내용과 기존 확인 절차를 따릅니다.

Tool call template

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

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

Input Schema

NameRequiredDescriptionDefault
brnoNo사업자등록번호 10자리(하이픈 허용). bzmnNm 과 brno 가운데 하나 이상.
bzmnNmNo상호(사업자명). bzmnNm 과 brno 가운데 하나 이상. 상호로 검색하면 사업자등록번호를 함께 돌려줍니다.
pageNoNo페이지 번호(선택, 기본 1).
numOfRowsNo한 페이지 결과 수(선택, 기본 100).
request_idempotency_keyNoOptional same-request recovery key for authenticated calls; see the tool description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true; the description independently corroborates this by stating the call creates an XBOSS job, persists results, and is 'not purely read-only' despite the upstream being a query, plus it discloses per-call token cost. It also explains idempotency-key reuse semantics for recovery after a lost response. The one weak spot is the contradictory claim '별도 연동 없이 사용할 수 있습니다' sitting next to authenticated-call/idempotency-key requirements, which muddies the auth story.

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 Korean lead is well front-loaded (purpose, source, chaining value, count semantics, coverage caveat), but the trailing English block on idempotency keys is boilerplate that repeats itself ('Without it, calling again remains a new request') and drifts into internal implementation detail about XBOSS job creation. The mix of 'no integration needed' with authenticated-key instructions reads as assembled from two different templates.

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?

For a read-style lookup with 100% schema coverage and no output schema, the description supplies everything an agent needs: the data source, the two search keys, the fact that total_count carries the count, that brno is returned alongside name matches, and the crucial emptiness caveat. No pagination detail is needed because the schema already documents pageNo and numOfRows.

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 coverage is 100%, so the baseline is 3, but the description earns a bump because the schema explicitly defers to the description for request_idempotency_key ('see the tool description'), and the description does supply the rule: reuse the same key only to recover that request, mint a new key for a new execution. It also restates the bzmnNm→brno relationship that makes the name search useful, though that largely duplicates the schema text.

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 opening sentence names a specific verb (조회) and resource (통신판매사업자 등록현황) and pins it to a concrete public dataset (data.go.kr 15126311), so there is no ambiguity about what is being searched. It also delimits scope (online-sales-registered operators only), which distinguishes it from generic business-registry siblings like opendata__nts__status.

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 explains the key workflow: search by 상호 (bzmnNm) to obtain 사업자등록번호 for chaining into other lookups, and it warns that absence from results does not prove the business does not exist (unregistered mail-order and offline businesses are excluded). It stops short of naming an explicit alternative tool for when this dataset is the wrong choice, so it is clear context without full when-not routing.

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