Skip to main content
This is a workflow design with offline examples, not evidence of live provider responses, customer adoption or legal approval. It is not credit, fraud or street-address verification.

​
Intended users

Product teams and automation partners handling repeated counterparty onboarding can query NTS business status using a registration number they lawfully hold. They may optionally normalize a Korean region name or coordinates into administrative codes and a weather grid. A business status, including closure status, is not a trust score or a transaction approval. A responsible operator makes that decision.

​
Inputs and acceptable adoption

resolve_location is a regional gazetteer and coordinate-computation meta-tool. Unsupported street addresses and ambiguous names must be marked unsupported_address or ambiguous and clarified, not presented as nationwide address validation.

​
Reuse the existing tools

  1. Follow the AI connection guide and first tool authentication/activation steps.
  2. Inspect getBusinessRegistrationStatus in civil/business-registration in the civil catalog.
  3. Preserve provider status and reference time; distinguish status lookup from registration-information matching.
  4. The existing business-information widget serves validateBusinessRegistration. Use it only with authorized additional inputs; it is not a substitute for status lookup or credit scoring.
  5. An executed result is not adoption. Record adopted only after explicit confirmation that the result was used in the task.
Do not execute before required keys and activation are available. Reading documentation or selecting a catalog tool is not task success.

​
Sources, time, permissions and cost

Repository metadata review date: 2026-10-10. No live provider request was made for this page. A location-computation timestamp is not the business-status reference time. Even a valid status must satisfy a freshness policy agreed for its intended use. Do not claim production readiness until documentation, rights, keys and separately approved live smoke evidence are checked.

​
Outcomes and unavailable data

This is a proposed normalized workflow envelope, not a change to the current MCP wire schema. Every requested component includes a source, asOf and unavailable reason. Status returned with unsupported address normalization is partial. A status-only request is judged only on its requested status output. Rows with reference-time or freshness failures are not usable. A closed-business status may still be a successful lookup; interpret status codes according to the provider, not as a business approval.

​
Offline evidence and support

The offline evidence pack contains 25 synthetic normalized cases for this bundle, out of 50 total. They contain no real business numbers, addresses, keys or provider payloads; they test four outcomes and missing-data handling only. They do not prove provider-wire compatibility, executability or adoption rates. Check input authority, rights, support ownership and expected costs before use. Display unknown time and unsupported-address reasons explicitly. Support requests should contain tool name, time and sanitized error code, not raw private inputs. Related: Place briefing, authentication and security, BYOAPI.