Official Korean listed company facts in English: DART profiles, KRW financial summaries, recent filings, and live National Tax Service business status checks. Keyless, read-only.
Scored across 4 tools
Each tool maps to a distinct stage: search for discovery, profile for listed-company filings/financials, procurement for KONEPS contracts, and business status for live tax registration. Minor overlap exists because search and profile surface procurement summaries, but the descriptions clearly direct users to kr_company_procurement for full breakdowns.
All names use lowercase snake_case with a kr_ prefix and readable noun phrases, making the set predictable. The only slight deviation is kr_business_status not following the kr_company_* stem, but the convention remains clear.
Four tools are tightly scoped to the domain's core read-only workflows: search, profile, procurement, and tax-status verification. There are no redundant or filler tools, and each operation earns its place.
The set covers discovery, listed-company profiles, procurement history, and tax-status verification, which supports common supplier due-diligence workflows. A minor gap is that profile-level corporate details and financials are limited to KOSPI-listed companies, leaving unlisted suppliers with less identity and financial context.
Check whether Korean 10-digit business registration numbers are currently active, suspended, or closed via the National Tax Service (NTS) live API. Use this to verify a Korean supplier, customer, or counterparty before a transaction; business_registration_no can be obtained from kr_company_search, kr_company_profile, or kr_company_procurement results. Accepts 1–10 ten-digit numbers (hyphens allowed, e.g. "124-81-00998") and returns per number: status (active | suspended | closed | not_registered), original Korean status text, tax type, closure date if closed, and check timestamp. Combine with kr_company_procurement to inspect the entity's 12-month KONEPS public procurement track record. Limitations: queries an external government API in real time; submitted numbers are never stored or logged. Read-only, keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| business_numbers | Yes | 1 to 10 Korean 10-digit business registration numbers (hyphens allowed, e.g. "124-81-00998") |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| notice | Yes | |
| results | Yes | |
| source_url | Yes | |
| verified_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only/idempotent/open-world safety, and the description adds context beyond them: a real-time external government API call, keyless access, and the privacy guarantee that submitted numbers are never stored or logged. It also enumerates the response fields (status, Korean status text, tax type, closure date, check timestamp).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage, then return format, then limitations — good ordering with no filler. It is fairly dense (a long first sentence plus a combined follow-up suggestion), so slightly less than maximally tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still summarizes the returned fields, and it covers external-API latency, privacy, and follow-up workflows. Nothing an agent needs to select and invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3, but the description adds where the values originate (three sibling tools) and reiterates the hyphen-tolerant 10-digit format and 1–10 batch limit. That extra provenance guidance is genuinely useful and not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (check Korean 10-digit business registration numbers) plus the authoritative source (NTS live API) and the three possible outcomes. It is clearly distinguishable from the kr_company_* siblings, which fetch company profiles or procurement records rather than registry status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it (verify a supplier, customer, or counterparty before a transaction) and where the input comes from (kr_company_search, kr_company_profile, kr_company_procurement). It also names the follow-up tool to combine with for procurement history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get precomputed 12-month Korean government and public-agency contract totals and recent awards for a listed company or unlisted corporate supplier from the Public Procurement Service (KONEPS), cross-linked with DART corporate identifiers. Use this to evaluate a Korean company's public-sector delivery track record when you have an 8-digit DART corp_code, 6-digit KRX stock_code, or 10-digit business_registration_no (call kr_company_search first if you only have a name). Returns company identifiers (including business_registration_no), period (with basis: "original_signed_date"), 12-month contract_count, joint_contract_count, total_amount_krw, breakdowns by_category (goods, construction, services, foreign) and by_contract_type (lump_sum, unit_price, multi_year), top 5 government buyers, and up to 20 recent contracts with KONEPS detail URLs; if the company has no contracts in the window, returns found=true and has_procurement=false with a "No procurement in last 12 months" message. Pass business_registration_no to kr_business_status to verify live National Tax Service status, or corp_code to kr_company_profile for DART financials. Limitations: corporate entities only (sole proprietors are excluded). The 12-month window is by original contract signing date (period.basis = "original_signed_date"): it covers contracts first signed in the period, and excludes amendments registered in the period to contracts signed earlier. Amounts are in KRW from KONEPS; the 12-month total counts sole contracts in full and joint contracts by the supplier's share (joint contracts without a published share are counted but not summed), multi-year contracts count only the current-period amount, and unit-price (framework) contracts are reported separately because their values are ceilings, not spend. Read-only, keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| corp_code | No | 8-digit DART corp_code (e.g. "00126380") | |
| stock_code | No | 6-digit KRX stock_code (e.g. "005930") | |
| business_registration_no | No | 10-digit Korean corporate business registration number (hyphens allowed, e.g. "124-81-00998") |
| Name | Required | Description |
|---|---|---|
| error | No | |
| found | Yes | |
| notice | Yes | |
| company | Yes | |
| message | No | |
| identifier | No | |
| source_url | Yes | |
| amount_note | Yes | |
| procurement | Yes | |
| verified_at | Yes | |
| has_procurement | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/keyless/idempotent, and the description adds substantial context beyond them: the exact no-results contract (found=true, has_procurement=false with a specific message), the corporate-entities-only exclusion of sole proprietors, and how the aggregate is computed (sole contracts in full, joint contracts by share with unshared ones counted but not summed, multi-year only current-period amounts, unit-price frameworks reported separately as ceilings). These are non-obvious aggregation semantics that materially affect interpretation of the numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and identifier requirement are front-loaded in the opening sentences, and the limitations block earns its place by explaining the 12-month basis and amount accounting. It is, however, a dense multi-clause paragraph that enumerates return fields already covered by the output schema, adding length without new decision value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with full schema coverage, an output schema, and no destructive behavior, nothing an agent needs is missing: input identity resolution, the empty-result shape, the temporal window definition and its amendment caveat, and the currency and aggregation rules are all stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each identifier already has a pattern and example, so the schema does the heavy lifting. The description still adds resolution guidance — which identifier maps to which downstream tool and that a name alone requires kr_company_search first — but it does not explain the anyOf behavior or precedence when multiple identifiers are supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — precomputed 12-month Korean public procurement contract totals and recent awards from KONEPS for a listed or unlisted corporate supplier. It also scopes what the tool is not for by deferring name-only lookups to kr_company_search and live tax status to kr_business_status, so an agent can distinguish it from all three siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case ('evaluate a Korean company's public-sector delivery track record') and the exact precondition for invoking it: possession of a corp_code, stock_code, or business_registration_no. It also names the fallback (call kr_company_search first if you only have a name) and the follow-on tools (kr_business_status, kr_company_profile), which is precisely the when/alternatives routing an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the precomputed, cross-linked profile of one KOSPI-listed Korean company from official Korean government filings: corporate identifiers (8-digit DART corp_code, 6-digit KRX stock_code, 10-digit business_registration_no, corporate_registration_no, CEO, address, website, founding date, fiscal month, industry code), the latest annual financial summary with prior-year comparison (revenue, operating income, net income, assets, liabilities, equity in integer KRW, consolidated CFS preferred), recent 90-day DART filings (up to 20), and cross-linked 12-month KONEPS public procurement summary if present. Use this when you have a KOSPI company's corp_code or stock_code; if you only have a name or business_registration_no, call kr_company_search first. Follow up with kr_company_procurement for full contract-type breakdowns or kr_business_status to verify active tax registration. Returns found=false if the company is not in the KOSPI index. Source: Korea FSS OpenDART and PPS KONEPS. Read-only, keyless. Not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| corp_code | No | 8-digit DART corp_code (e.g. "00126380") | |
| stock_code | No | 6-digit KRX stock_code (e.g. "005930") |
| Name | Required | Description |
|---|---|---|
| error | No | |
| found | Yes | |
| notice | Yes | |
| company | Yes | |
| message | No | |
| financials | Yes | |
| identifier | No | |
| source_url | Yes | |
| amount_note | No | |
| name_labels | No | |
| procurement | No | |
| verified_at | Yes | |
| recent_filings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive, and the description adds genuinely new behavioral facts: data provenance (official government filings), that values are precomputed, integer-KRW units, consolidated CFS preference, a 20-filing cap, and found=false for non-KOSPI companies. Only minor redundancy ('read-only' restates the annotation) and the absence of any caching/freshness or pagination note keep it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the payload contents, then usage, then caveats — a sensible order with no filler sentences. It is a dense single paragraph with a long parenthetical field list, which is informative but slightly hard to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, yet the description still tells the agent what it will receive and when it comes back empty (found=false), plus the source system and a non-advice disclaimer. For a 2-parameter read tool with full annotations, nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is a 3, but the description adds real semantics the schema's anyOf does not articulate in prose: you need one of corp_code or stock_code, and each is an official government-issued identifier (8-digit DART, 6-digit KRX). It does not discuss precedence if both are supplied, which prevents a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ('Get the precomputed, cross-linked profile of one KOSPI-listed Korean company') and enumerates exactly what the profile contains (identifiers, annual financials, 90-day filings, 12-month procurement). It also anchors the data source (FSS OpenDART, PPS KONEPS) and scope (KOSPI only), which separates it cleanly from kr_company_procurement and kr_company_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the entry condition explicitly ('Use this when you have a KOSPI company's corp_code or stock_code') and the fallback ('if you only have a name or business_registration_no, call kr_company_search first'). It also names two follow-up routes (kr_company_procurement for contract-type breakdowns, kr_business_status for tax registration) and the not-found case, so an agent can route without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search KOSPI-listed Korean companies and corporate public procurement suppliers across precomputed, cross-linked official Korean government datasets (FSS OpenDART and Public Procurement Service KONEPS). Use this first when you have a company name (Korean or English, e.g. "Samsung Electronics", "삼성전자", "한화시스템"), a 6-digit KRX stock_code, an 8-digit DART corp_code, or a 10-digit business_registration_no. Returns up to 20 ranked candidates with kind ("listed" or "supplier"), corp_code, stock_code, business_registration_no, Korean legal name, DART/KONEPS registered English name, alternate names, and 12-month KONEPS procurement total in KRW; results sort by exact identifier match first, then listed companies, then 12-month procurement amount descending. Pass corp_code or stock_code to kr_company_profile for financials and DART filings, pass corp_code, stock_code, or business_registration_no to kr_company_procurement for KONEPS contract breakdowns, or pass business_registration_no to kr_business_status for live tax registration status. Coverage: all KOSPI companies (~830) and all corporate KONEPS suppliers (~110,000 over 12 months); corporate entities only (sole proprietors are excluded). Read-only, keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max candidates to return (1..20, default 10) | |
| query | Yes | Company name (Korean, English, or alternate), 6-digit KRX stock_code, 8-digit DART corp_code, or 10-digit business_registration_no |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| query | Yes | |
| notice | Yes | |
| candidates | Yes | |
| source_url | Yes | |
| name_labels | No | |
| verified_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety, but the description adds substantial context: official data sources, precomputed cross-linked datasets, ranking order, result fields, coverage counts, and the corporate-only exclusion. It also notes the tool is keyless, which is useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and every sentence carries relevant information, but it is a dense single paragraph and enumerates return fields that are already covered by the output schema. It is still appropriately sized for a multi-purpose search and routing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations, full schema coverage, and existing output schema, the description is complete enough to select and invoke the tool correctly. It covers inputs, coverage, result composition, routing to siblings, and exclusions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents query and limit. The description adds useful examples of accepted names and identifier forms, plus match-ordering context, though limit semantics remain mostly covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: searching KOSPI-listed Korean companies and corporate KONEPS suppliers. It also distinguishes this tool from its siblings by explaining the downstream profile, procurement, and business-status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this first when the user has a company name or official identifier, and it routes the agent to specific sibling tools based on which identifier is available. The corporate-only exclusion of sole proprietors is also stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
kr_company_procurementkr_company_profile3 fields changedOutput schema / properties / amount_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / company / properties / procurementAdded value: +{
+ "properties": {
+ "amount_note": {
+ "type": "string"
+ },
+ "by_category": {
+ "properties": {
+ "construction": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "foreign": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "goods": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "services": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "by_contract_type": {
+ "properties": {
+ "lump_sum": {
+ "properties": {
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "share_amount_krw": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "contract_count",
+ "amount_total_krw",
+ "amount_this_krw",
+ "share_amount_krw"
+ ],
+ "type": "object"
+ },
+ "multi_year": {
+ "properties": {
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "share_amount_krw": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "contract_count",
+ "amount_total_krw",
+ "amount_this_krw",
+ "share_amount_krw"
+ ],
+ "type": "object"
+ },
+ "unit_price": {
+ "properties": {
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "share_amount_krw": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "contract_count",
+ "amount_total_krw",
+ "amount_this_krw",
+ "share_amount_krw"
+ ],
+ "type": "object"
+ },
+ "unknown": {
+ "properties": {
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "share_amount_krw": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "contract_count",
+ "amount_total_krw",
+ "amount_this_krw",
+ "share_amount_krw"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "joint_contract_count": {
+ "type": "integer"
+ },
+ "period": {
+ "properties": {
+ "basis": {
+ "const": "original_signed_date",
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "from",
+ "to",
+ "basis"
+ ],
+ "type": "object"
+ },
+ "recent_contracts": {
+ "items": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "buyer_ko": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "enum": [
+ "goods",
+ "construction",
+ "services",
+ "foreign"
+ ],
+ "type": "string"
+ },
+ "changed_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "contract_no": {
+ "type": "string"
+ },
+ "contract_type": {
+ "enum": [
+ "lump_sum",
+ "unit_price",
+ "multi_year",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "joint": {
+ "type": "boolean"
+ },
+ "method_ko": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "role": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "share_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "signed_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_ko": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "contract_no",
+ "title_ko",
+ "category",
+ "contract_type",
+ "signed_date",
+ "amount_total_krw",
+ "amount_this_krw",
+ "amount_krw",
+ "buyer_ko",
+ "joint",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "top_buyers": {
+ "items": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "buyer_code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "buyer_ko": {
+ "type": "string"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "buyer_ko",
+ "contract_count",
+ "amount_krw"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total_amount_krw": {
+ "type": "integer"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / procurementAdded value: +{
+ "properties": {
+ "amount_note": {
+ "type": "string"
+ },
+ "by_category": {
+ "properties": {
+ "construction": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "foreign": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "goods": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ },
+ "services": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "by_contract_type": {
+ "properties": {
+ "lump_sum": {
+ "properties": {
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "share_amount_krw": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "contract_count",
+ "amount_total_krw",
+ "amount_this_krw",
+ "share_amount_krw"
+ ],
+ "type": "object"
+ },
+ "multi_year": {
+ "properties": {
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "share_amount_krw": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "contract_count",
+ "amount_total_krw",
+ "amount_this_krw",
+ "share_amount_krw"
+ ],
+ "type": "object"
+ },
+ "unit_price": {
+ "properties": {
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "share_amount_krw": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "contract_count",
+ "amount_total_krw",
+ "amount_this_krw",
+ "share_amount_krw"
+ ],
+ "type": "object"
+ },
+ "unknown": {
+ "properties": {
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "share_amount_krw": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "contract_count",
+ "amount_total_krw",
+ "amount_this_krw",
+ "share_amount_krw"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "contract_count": {
+ "type": "integer"
+ },
+ "joint_contract_count": {
+ "type": "integer"
+ },
+ "period": {
+ "properties": {
+ "basis": {
+ "const": "original_signed_date",
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "from",
+ "to",
+ "basis"
+ ],
+ "type": "object"
+ },
+ "recent_contracts": {
+ "items": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "amount_this_krw": {
+ "type": "integer"
+ },
+ "amount_total_krw": {
+ "type": "integer"
+ },
+ "buyer_ko": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "category": {
+ "enum": [
+ "goods",
+ "construction",
+ "services",
+ "foreign"
+ ],
+ "type": "string"
+ },
+ "changed_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "contract_no": {
+ "type": "string"
+ },
+ "contract_type": {
+ "enum": [
+ "lump_sum",
+ "unit_price",
+ "multi_year",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "joint": {
+ "type": "boolean"
+ },
+ "method_ko": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "role": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "share_pct": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "signed_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_ko": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "contract_no",
+ "title_ko",
+ "category",
+ "contract_type",
+ "signed_date",
+ "amount_total_krw",
+ "amount_this_krw",
+ "amount_krw",
+ "buyer_ko",
+ "joint",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "top_buyers": {
+ "items": {
+ "properties": {
+ "amount_krw": {
+ "type": "integer"
+ },
+ "buyer_code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "buyer_ko": {
+ "type": "string"
+ },
+ "contract_count": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "buyer_ko",
+ "contract_count",
+ "amount_krw"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total_amount_krw": {
+ "type": "integer"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+}kr_company_search11 fields changedInput schema / properties / query / descriptionPrevious value: -"Company name (English, Korean, or alternate), 6-digit KRX stock_code, or 8-digit DART corp_code (e.g. \"samsung\", \"현대자동차\", \"005930\")"New value: +"Company name (Korean, English, or alternate), 6-digit KRX stock_code, 8-digit DART corp_code, or 10-digit business_registration_no"Output schema / properties / candidates / items / properties / business_registration_noAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / candidates / items / properties / corp_code / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / candidates / items / properties / kindAdded value: +{
+ "enum": [
+ "listed",
+ "supplier"
+ ],
+ "type": "string"
+}Output schema / properties / candidates / items / properties / market / constRemoved value: -"KOSPI"Output schema / properties / candidates / items / properties / market / enumAdded value: +[
+ "KOSPI",
+ null
+]Output schema / properties / candidates / items / properties / market / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / candidates / items / properties / procurement_amount_12m_krwAdded value: +{
+ "type": "integer"
+}Output schema / properties / candidates / items / properties / procurement_contracts_12mAdded value: +{
+ "type": "integer"
+}Output schema / properties / candidates / items / properties / stock_code / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / candidates / items / requiredPrevious value: -[
- "corp_code",
- "stock_code",
- "name_en",
- "name_ko",
- "alternate_names",
- "market"
-]New value: +[
+ "kind",
+ "corp_code",
+ "stock_code",
+ "business_registration_no",
+ "name_en",
+ "name_ko",
+ "alternate_names",
+ "market"
+]kr_business_status3 fields changedInput schema / properties / business_numbers / descriptionPrevious value: -"1 to 10 Korean 10-digit business registration numbers (hyphens optional)"New value: +"1 to 10 Korean 10-digit business registration numbers (hyphens allowed, e.g. \"124-81-00998\")"Input schema / properties / business_numbers / items / patternAdded value: +"^[0-9]{3}-?[0-9]{2}-?[0-9]{5}$"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "properties": {
+ "business_registration_no": {
+ "type": "string"
+ },
+ "checked_at": {
+ "type": "string"
+ },
+ "closed_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "enum": [
+ "active",
+ "suspended",
+ "closed",
+ "not_registered"
+ ],
+ "type": "string"
+ },
+ "status_ko": {
+ "type": "string"
+ },
+ "tax_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "business_registration_no",
+ "status",
+ "status_ko",
+ "tax_type",
+ "closed_date",
+ "checked_at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "count",
+ "results",
+ "notice",
+ "source_url",
+ "verified_at"
+ ],
+ "type": "object"
+}kr_company_profile4 fields changedInput schema / anyOfAdded value: +[
+ {
+ "required": [
+ "corp_code"
+ ]
+ },
+ {
+ "required": [
+ "stock_code"
+ ]
+ }
+]Input schema / properties / corp_code / patternAdded value: +"^[0-9]{8}$"Input schema / properties / stock_code / patternAdded value: +"^[0-9A-Z]{6}$"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "company": {
+ "properties": {
+ "address": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "alternate_names": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "business_registration_no": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ceo_name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "corp_code": {
+ "type": "string"
+ },
+ "corporate_registration_no": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "established_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "financials": {
+ "properties": {
+ "basis": {
+ "enum": [
+ "CFS",
+ "OFS"
+ ],
+ "type": "string"
+ },
+ "currency": {
+ "const": "KRW",
+ "type": "string"
+ },
+ "fiscal_year": {
+ "type": "integer"
+ },
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "operating_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "prior_year": {
+ "properties": {
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "operating_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_assets": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_equity": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_liabilities": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "revenue",
+ "operating_income",
+ "net_income",
+ "total_assets",
+ "total_liabilities",
+ "total_equity"
+ ],
+ "type": "object"
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "total_assets": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_equity": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_liabilities": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "fiscal_month": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "homepage": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "industry_code": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "market": {
+ "const": "KOSPI",
+ "type": "string"
+ },
+ "name_en": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name_ko": {
+ "type": "string"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "recent_filings": {
+ "items": {
+ "properties": {
+ "filed_date": {
+ "type": "string"
+ },
+ "filer": {
+ "type": "string"
+ },
+ "receipt_no": {
+ "type": "string"
+ },
+ "title_en": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_ko": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_no",
+ "filed_date",
+ "title_ko",
+ "filer",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source_urls": {
+ "properties": {
+ "company": {
+ "type": "string"
+ },
+ "filings": {
+ "type": "string"
+ },
+ "financials": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "stock_code": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "error": {
+ "type": "string"
+ },
+ "financials": {
+ "properties": {
+ "basis": {
+ "enum": [
+ "CFS",
+ "OFS"
+ ],
+ "type": "string"
+ },
+ "currency": {
+ "const": "KRW",
+ "type": "string"
+ },
+ "fiscal_year": {
+ "type": "integer"
+ },
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "operating_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "prior_year": {
+ "properties": {
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "operating_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_assets": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_equity": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_liabilities": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "revenue",
+ "operating_income",
+ "net_income",
+ "total_assets",
+ "total_liabilities",
+ "total_equity"
+ ],
+ "type": "object"
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "total_assets": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_equity": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "total_liabilities": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "found": {
+ "type": "boolean"
+ },
+ "identifier": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "name_labels": {
+ "properties": {
+ "name_en": {
+ "type": "string"
+ },
+ "name_ko": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "recent_filings": {
+ "items": {
+ "properties": {
+ "filed_date": {
+ "type": "string"
+ },
+ "filer": {
+ "type": "string"
+ },
+ "receipt_no": {
+ "type": "string"
+ },
+ "title_en": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title_ko": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "receipt_no",
+ "filed_date",
+ "title_ko",
+ "filer",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "found",
+ "company",
+ "financials",
+ "recent_filings",
+ "notice",
+ "source_url",
+ "verified_at"
+ ],
+ "type": "object"
+}kr_company_search4 fields changedInput schema / properties / limit / defaultAdded value: +10Input schema / properties / query / descriptionPrevious value: -"Company name (EN/KO/alternate), 6-digit stock_code, or 8-digit corp_code"New value: +"Company name (English, Korean, or alternate), 6-digit KRX stock_code, or 8-digit DART corp_code (e.g. \"samsung\", \"현대자동차\", \"005930\")"Input schema / properties / query / minLengthAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "candidates": {
+ "items": {
+ "properties": {
+ "alternate_names": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "corp_code": {
+ "type": "string"
+ },
+ "market": {
+ "const": "KOSPI",
+ "type": "string"
+ },
+ "name_en": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name_ko": {
+ "type": "string"
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "stock_code": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "corp_code",
+ "stock_code",
+ "name_en",
+ "name_ko",
+ "alternate_names",
+ "market"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "count": {
+ "type": "integer"
+ },
+ "name_labels": {
+ "properties": {
+ "name_en": {
+ "type": "string"
+ },
+ "name_ko": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "notice": {
+ "type": "string"
+ },
+ "query": {
+ "type": "string"
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "query",
+ "count",
+ "candidates",
+ "notice",
+ "source_url",
+ "verified_at"
+ ],
+ "type": "object"
+}kr_business_statuskr_company_profilekr_company_search
Add one secure layer between your agents and this server.