Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@export-controls-agent What license exceptions apply to our battery cathode exports to Germany?"
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.
Local MCP server for export-control legal research and transaction-risk analysis, focused on Korean semiconductor and secondary-battery companies.
The line between what is modelled from the regulation text and what is merely flagged for manual review matters more than the feature list, so it comes first. The regime_overview tool reports the same split at runtime.
Modelled — evaluated against bundled snapshots of the regulation, with citations and a data vintage:
Area | Provision |
EAR jurisdiction | § 734.4 de minimis, all thirteen § 734.9 Foreign Direct Product rules |
Licence requirement | Part 738 Commerce Country Chart and the § 738.4(a)(2) procedure, with the § 738.3(b) territory rule and the § 738.3(a)(1) entries that bypass the chart |
License Exceptions | Part 740, including the § 740.2 mandatory restrictions |
Country Groups | Part 740 Supplement No. 1 |
End-use / end-user | Part 744, including the 50 percent affiliates rule |
Commerce Control List | Part 774 Supplement No. 1, text search over all 633 entries |
Restricted parties | U.S. Consolidated Screening List, 25,921 parties across 12 lists |
PRC (MOFCOM) | Dated instrument and numbered-announcement register, current strategic-mineral/rare-earth packages, the November 2025 suspension, No. 61 extraterritorial reach, and current 2026 designation records |
Korean statutes | 대외무역법 and 국제사법, full current article text |
Not modelled — the server holds no data and performs no analysis; it only raises these as issues to check:
General Prohibitions Four through Ten (Part 736). This matters directly to the Country Chart result. Under § 738.4(a)(2)(ii)(B), an absent mark means no licence is required only if those prohibitions do not apply and the entry does not refer you elsewhere. A no_chart_requirement answer is therefore never clearance.
两用物项出口管制清单, the Chinese Export Control List for Dual-Use Items. Not bundled, so the server cannot classify an item under Chinese export control. That is the Chinese equivalent of the ECCN question and is usually an exporter's first one.
管控名单, the Unreliable Entity List and the Malicious Entity List. No complete machine-readable list is published in a form that can be bundled and kept current, so Chinese entity screening is not offered rather than offered badly. A name that produces no match has not been checked.
EU Regulation 2021/821. Annex I is not bundled. The server flags that an EU touchpoint exists and reminds you to review the Regulation. It cannot classify an item under EU law or analyse EU authorisations.
전략물자수출입고시, the Korean control list. The statute text is bundled; the control list is not. So the server cannot tell you whether an item is a 전략물자, which is usually a Korean exporter's first question. Use the KOSTI 전략물자관리시스템 or apply for a 전문판정 under Article 20.
Part 742 licence requirements, Part 746 embargoes, Parts 748/758/762/764. Cited where relevant, not evaluated.
Related MCP server: lawink-mcp
It identifies the issues a reviewer must work through and quotes the governing text. It does not decide them.
Specifically, it cannot:
classify an item — classify_eccn searches the text of the Commerce Control List and quotes candidate paragraphs
determine that a License Exception is available — analyze_license_exceptions reports which exceptions are foreclosed, out of scope, or worth reviewing, and lists the conditions each requires
clear a party — screen_restricted_party returns ranked candidate matches against the Consolidated Screening List. It does not screen ownership, so the 50 percent affiliates rule in § 744.21(a)(3) can catch an unlisted entity that produces no hit at all
decide jurisdiction from facts it does not have — assess_ear_jurisdiction applies § 734.4 and all thirteen § 734.9 FDP rules, but most FDP prongs turn on which U.S.-origin technology was used in production, which only the manufacturer knows
Two consequences worth stating plainly. An empty issue list means the heuristic found nothing, not that a transaction is permissible. And requires_verification never means "yes".
git clone https://github.com/seelpeed-debug/export-controls-agent-mcp.git
cd export-controls-agent-mcp
npm installNode 18 or later. The regulation snapshots are committed, so the server runs immediately after npm install with no network access and no API key.
The server bundles dated snapshots of the regulation text rather than hardcoded summaries, because the EAR is amended frequently. Each snapshot records the eCFR issue date it was built from, and every tool response carries that vintage in a dataProvenance block.
Dataset | Source | Rebuild |
Country Groups (Part 740, Supp. No. 1) | eCFR XML |
|
Commerce Country Chart (Part 738, Supp. No. 1) | eCFR XML |
|
License Exception catalog (Part 740) | eCFR XML |
|
Commerce Control List (Part 774, Supp. No. 1) | eCFR XML |
|
Consolidated Screening List (25,921 parties, 12 lists) | trade.gov bulk download, no API key |
|
§ 734.9 FDP rule scopes (13 rules) | transcribed from eCFR |
|
PRC framework, announcement register and No. 61 tests | transcribed from MOFCOM announcements |
|
대외무역법 / 국제사법 full text | law.go.kr Open API |
|
Rebuild the EAR datasets together with npm run data:rebuild, which finishes by running the validators.
Two properties worth knowing:
Each builder asserts facts verified against the regulation and refuses to write a dataset that fails them, so a change in the upstream document structure fails loudly instead of silently producing wrong compliance data. The Country Chart builder refuses outright if the 16 column identifiers change, because every rule in the CCL names them by string.
A builder that finds nothing substantively changed leaves the file alone rather than bumping its retrievedAt stamp. That keeps the git history meaningful: a commit touching src/data/ means the regulation moved, not merely that someone re-ran the script. Pass --force to rewrite regardless.
The screening snapshot has its own, much shorter staleness threshold of 7 days, because restricted-party lists change by Federal Register notice rather than by quarterly amendment. The PRC transcription uses 14 days: MOFCOM publishes no versioned text, the framework moved six times in the twelve months to July 2026, and the current suspension carries a fixed expiry. The other snapshots use 30 days.
The PRC dataset cannot be rebuilt. There is no versioned machine-readable source — MOFCOM publishes numbered announcements as individual pages with no index and no diff mechanism — so validate:china instead converts the decay into a failure: once the suspension expiry passes, the validator fails until a human re-reads MOFCOM and updates the transcription.
Check whether the snapshots have fallen behind:
# from a client, call the check_data_freshness tool, or:
node -e "import('./src/lib/provenance.js').then(m=>m.checkFreshness()).then(r=>console.log(r.recommendation))"LAW_OC is a law.go.kr Open API account id. It is optional at run time: without it the Korean statute tool serves the bundled snapshot and says so. It is required to rebuild the Korean law snapshot.
No API key is stored in the source or in the generated data files.
npm startMCP clients normally launch this server over stdio. Example client config, substituting the absolute path to your clone:
{
"mcpServers": {
"export-controls-agent": {
"command": "node",
"args": ["/absolute/path/to/export-controls-agent-mcp/src/server.js"],
"env": {
"LAW_OC": "your-law-go-kr-account-id"
}
}
}
}On Windows, escape the backslashes: "C:\\\\path\\\\to\\\\export-controls-agent-mcp\\\\src\\\\server.js".
LAW_OC may be omitted entirely; the Korean statute tool then serves the bundled snapshot.
regime_overviewOrientation map of the regimes bearing on a transaction, and which of them this server actually models. Each regime carries a coverageInThisServer value of modelled, partial or pointer_only, plus explicit modelledParts and notModelledParts lists. Worth calling first, because it tells the reader where the server's silence means nothing.
Also records that the 2024-02-20 전문개정 split the former 대외무역법 제19조 into 제19조 (designation), 제19조의2 (수출허가, including intangible technology transfer) and 제19조의3 (상황허가).
classify_transaction_riskTriage score and review plan. Terms are matched on word boundaries and negated statements ("no military end use") are reported separately and excluded from the score. The destination is assessed from the Country Group tables rather than from keywords.
classify_eccnSearches the Commerce Control List text and quotes the paragraphs that mention the technical terms in an item description, with the entry's Reason for Control and List Based License Exception flags.
The search separates what a user might write from what the regulation writes — a datasheet says "ion implanter", the CCL says "ion implantation". Terms whose CCL occurrences are in an unrelated sense are flagged: "cathode" in the CCL means metal crude forms and cathodic arc deposition, not battery cathode active material.
assess_ear_jurisdictionAnswers the question that comes before classification: is this item subject to the EAR at all? Applies two independent routes.
De minimis (§ 734.4) — the threshold is set by the destination: 10 percent for Country Group E:1 and E:2, 25 percent everywhere else. Nine categories in § 734.4(a) have no de minimis level whatsoever, and the tool checks those before running any percentage.
Foreign Direct Product rules (§ 734.9) — all thirteen, each evaluated as two independent prongs. A rule applies only if the product scope and the destination or end-user scope are both met; an unresolved prong is reported as indeterminate rather than as inapplicable.
The FDP rules are why this matters for a Korean manufacturer. They have no percentage test at all:
Korean-built etcher, ECCN 3B001.c
0% U.S. content
produced using U.S.-origin 3E992 technology
destination: China
de minimis → threshold met (0% ≤ 25%)
overall → SUBJECT TO THE EAR under § 734.9(k), the SME FDP rulePassing de minimis is routinely mistaken for an answer. It is not one, and the tool never reports it as one while any FDP rule remains unresolved. The two rules that reach Korean semiconductor-equipment supply chains most directly are § 734.9(k) (SME) and § 734.9(e)(3) (Footnote 5 and advanced-node IC production, which reaches entities located at logic or DRAM advanced-node fabs in Macau or Country Group D:5).
The § 734.9 rule scopes are transcribed from the regulation rather than machine-parsed, because they are prose mixed with ECCN lists and exclusions. npm run validate:fdp checks the transcription against the live section and fails on drift.
screen_restricted_partyScreens party names against the bundled Consolidated Screening List: BIS Entity List, Denied Persons, Unverified and MEU; OFAC SDN, SSI, CMIC, NS-MBS, PLC and Capta; State ITAR Debarred and Nonproliferation Sanctions. Each hit carries the list's authority, the operative licence requirement text, the licence review policy and the Federal Register notice.
Matching is aliased, diacritic-insensitive and tolerant of corporate form words, and it handles acronyms — SMIC resolves to Semiconductor Manufacturing International Corporation via its alias. Generic industry words carry no weight, so "Zzyzx Energy Holdings" does not match on energy alone.
Scores above 85 are treated as probable identifications; 70 to 84 are red flags to resolve.
check_part744_enduseLists Part 744 issues: military end use (§ 744.21) including the 50 percent affiliates rule, military-intelligence (§ 744.22), nuclear (§ 744.2), missile (§ 744.3), chemical and biological (§ 744.4), U.S.-person activities (§ 744.6), and the supercomputer, advanced-node IC and semiconductor-manufacturing-equipment controls (§ 744.23).
Screens endUser and additionalParties against the Consolidated Screening List automatically, and reports a strong hit as a blocking issue with its licence requirement. It still blocks on incomplete screening, because one name is not a transaction and ownership is not in the list.
assess_china_export_controlsChinese export controls under the Export Control Law, the 2024 Regulations on Export Control of Dual-Use Items, and the numbered MOFCOM announcements.
This regime differs from the EAR in three ways that shape the tool.
The operative question is usually whether a measure is in force, not what it says. Announcements Nos. 55, 56, 57, 58, 61 and 62 of 2025 are suspended by Announcement No. 70 of 2025 until 10 November 2026. Announcement No. 18 of 2025, covering seven medium and heavy rare earths, is not suspended and still requires a licence. So status is computed against a date, and a fact pattern that meets a suspended test returns license_required_if_reactivated with the expiry, because the instruments are not repealed. Suspension is not an exemption. Pass asOfDate to test a future date.
A detail worth knowing: No. 61 § 1(c), covering Chinese-origin listed items, took effect on publication on 9 October 2025. Its content and technology limbs (§ 1(a) and § 1(b)) were due on 1 December 2025, but the suspension began on 7 November. The delayed limbs therefore never operated; the Chinese-origin limb operated briefly before the suspension. The delayed text still matters on revival.
It binds non-Chinese parties directly. Announcement No. 61 requires a MOFCOM permit for a shipment where both ends are outside China, and a 管控名单 designation prohibits parties in any country from supplying the listed entity with Chinese-origin dual-use items. A Korean exporter with no Chinese entity and no U.S. nexus can be squarely inside this regime.
Its content test runs the opposite way to EAR de minimis.
EAR § 734.4 | MOFCOM Announcement No. 61 § 1(a) | |
Threshold | 25 percent, or 10 percent for the strictest destinations | 0.1 percent |
Direction | a ceiling you fall below to escape | a floor you rise above to be caught |
Clearing U.S. de minimis at 20 percent says nothing about this test. The tool refuses to carry a conclusion across.
Announcement No. 61's other limbs mirror provisions you will recognise: § 1(b) is a Foreign Direct Product analogue reached from the other direction, catching items produced abroad using Chinese rare-earth extraction, smelting separation, metal smelting, magnetic material manufacturing or recycling technology, with no percentage test. § 2 carries a 50 percent affiliates rule and makes applications for military end users impermissible in principle. The register also records the 2025 strategic-mineral package and the 2026 Japan, U.S. and EU measures, but the item list and complete designation lists remain unbundled.
The tool does not classify items and does not screen entities, because neither list is bundled. Every answer says so.
determine_license_requirementWorks the Commerce Country Chart for an ECCN and a destination, following § 738.4(a)(2). Reads every Reason for Control in the entry and resolves each one to a chart column or to the prose destination scope the entry states instead. Only 1263 of the 1536 License Requirements rows in the CCL name a column; the other 273 say things like "To or within any destination worldwide" or "To or within Macau or a destination specified in Country Group D:5", so a column-only reading would return nothing for 3A090 and for 3B001.c. One row in the whole list cannot be read, and the reason is in the regulation: 1D018's MT row has a blank Country Chart cell and its control text names no requirement.
Each requirement is reported separately, because § 738.4(a)(2)(ii)(A) requires each one to be overcome on its own.
Four things a table lookup gets wrong, all handled here:
Cuba, Iran, North Korea and Syria carry no marks at all. Their rows point to Part 746 instead. An empty row is reported as embargo_destination, never as an absence of requirements.
The footnotes create requirements the grid does not show. Australia's row is empty apart from CB 1, yet footnote 10 still requires a licence for a list of firearms entries. Ask about 0A501 to Australia and the footnote fires.
Some destinations have no row. Hong Kong's was removed by 85 FR 83788 and is governed by the China entry; under § 738.3(b) a dependent territory takes its parent's row. A destination that is neither a row nor one of the inheritance cases the EAR names comes back indeterminate_input, not clear.
Some entries bypass the chart. § 738.3(a)(1) requires a licence to all destinations for 0A983, 5A980 and others, with no License Exception at all for some of them.
Rows are scoped to subparagraphs, so 3B001.b resolves cleanly while a bare 3B001 returns a conditional answer and asks which subparagraph applies. Where a row's scope is a physical description — "shotguns with a barrel length less than 18 inches" — no ECCN string can decide it, and the row is reported as conditional rather than dropped.
Statuses are license_required, no_chart_requirement, requires_verification, embargo_destination, indeterminate_input and out_of_scope. no_chart_requirement is not clearance; see the Coverage note on General Prohibitions Four through Ten.
analyze_license_exceptionsApplies the mandatory restrictions in § 740.2 — including § 740.2(a)(9)(i), under which semiconductor manufacturing equipment and its associated software and technology going to Macau or Country Group D:5 has no License Exception available other than GOV — then reports each exception's status and the conditions it would require.
Carries a licenceRequirement block from the Country Chart, because an exception exists to overcome a licence requirement and an exception analysis with nothing to overcome is moot. Where the chart produces more than one requirement, the block says so: a single exception has to defeat all of them.
draft_export_control_clauseDrafts Korean or English clauses. riskLevel selects cumulative tiers: low gives baseline compliance and termination provisions, medium adds end-user certification and the affiliates-rule representation, high adds conditions precedent tied to pre-shipment re-screening, FDP and de minimis acknowledgement, § 744.6 U.S.-person control, and a mandatory-rules provision.
build_due_diligence_checklistStage-specific checklist. The industry parameter changes the output: the semiconductor set covers 3B001 subparagraph scoping and the § 744.23 controls, the battery set covers the absence of CCL entries for battery chemistry and the superficially matching entries to avoid.
get_korean_law_articleRetrieves an article of 대외무역법 or 국제사법 from the law.go.kr Open API, falling back to the bundled snapshot. Sub-articles are supported.
Note that the 2024-02-20 전문개정 split the former 제19조 into 제19조 (전략물자 지정·고시), 제19조의2 (수출허가) and 제19조의3 (상황허가), and several articles were further amended with effect from 2025-10-01.
check_data_freshnessCompares the bundled snapshots against the latest eCFR issue date and reports which need rebuilding.
export-controls://official-sources — canonical official source links
export-controls://data-provenance — bundled snapshot vintage and rebuild commands
export-controls://china-framework — the PRC instrument and announcement register, the November 2025 suspension, the Announcement No. 61 tests and the entity mechanisms. Held as a resource because it is constant, so the tool does not repeat it on every call
npm run preflightOne command, seven groups of checks, exit 0 means safe to push. It then prints the commit and push commands.
Each check exists because the corresponding mistake actually happened while building this, not because it seemed prudent:
Check | What went wrong once |
credentials in tracked files | a law.go.kr account id survived as a default value in a test harness about to be committed |
tracked file sizes | the 32 MB raw Consolidated Screening List download got staged |
placeholder in the remote URL | a literal |
runtime data present |
|
snapshot vintage | a "Refresh regulation snapshots" commit changed nothing but a timestamp |
tests and validators | — |
server starts over stdio | — |
The snapshot-vintage check uses the same thresholds the server does: 7 days for the screening list, 30 days for everything else.
If preflight warns that a snapshot is stale:
npm run data:rebuild # Country Groups, Part 740 catalog, CCL, screening list
LAW_OC=<your-oc> npm run data:korean-law
npm run preflight
git add -A && git commit -m "Refresh regulation snapshots to eCFR <date>" && git pushA commit touching src/data/ should mean the regulation actually moved. The builders skip writing when only the retrievedAt stamp would change, so a clean git status after a rebuild is the expected result when nothing has been amended.
npm testTen suites, covering term matching and negation, the Part 738 chart determination, the Part 740 and Part 744 gating logic, § 734 jurisdiction, CCL search behaviour, screening, the PRC framework and its suspension arithmetic, the risk and clause tiering, Korean statute retrieval, and the honesty of the coverage claims in this README and in regime_overview.
npm run validateFour validators, which check assumptions no snapshot can catch:
validate:vocabulary asserts every regulation-side search term actually occurs in the bundled CCL, so a search key that would silently return nothing fails instead.
validate:fdp re-reads § 734.9 and confirms the thirteen hand-transcribed rule scopes still match the section.
validate:country-chart confirms every prose destination scope the chart evaluator recognises still appears in the CCL. This is the one that matters most for the EAR: if BIS rewords a scope such as "To or within any destination worldwide", the pattern stops matching, the affected rows quietly become unreadable, and the tool silently stops reporting a licence requirement it used to catch. It also pins the number of unreadable rows, which may fall but not rise, and re-reads § 738.3 and § 738.4 against the live eCFR.
validate:china fails once the MOFCOM suspension expiry passes, because from that moment every "not currently required" answer about Announcements 55 to 62 is wrong until someone re-reads the source. It also checks the internal cross-references of a hand-transcribed dataset and enforces the honesty invariants: the designation list must keep declaring itself incomplete, a matched counterparty name must not suppress the unscreened question for the others, the 0.1 percent test must stay marked as a floor, and no unverified article number may be added.
This server is a research assistant, not a source of legal advice. It does not guarantee that its bundled snapshots reflect the law in force. Verify every output against official sources, and have export-control counsel confirm any conclusion before shipment.
Three limits are structural rather than incidental, and no amount of further work on this server removes them:
Ownership is invisible to name screening. The 50 percent affiliates rule under § 744.21(a)(3) reaches entities that appear on no list. Only a traced ownership chain answers it.
FDP turns on production facts. Most § 734.9 prongs depend on which U.S.-origin technology or software was used to make the item. Only the manufacturer knows that, which is why § 734.9(a)(2) supplier certifications exist.
Part 744 turns on knowledge, including reason to know. A structured input cannot capture a red flag that a human noticed in a conversation.
See the Coverage section for what is modelled and what is only flagged. Where something is listed as not modelled, this server has performed no analysis of it and its silence carries no meaning.
Official sources:
BIS EAR: https://www.bis.gov/regulations/ear
BIS Entity List: https://www.bis.gov/entity-list
eCFR Title 15: https://www.ecfr.gov/current/title-15
EU Regulation 2021/821: https://eur-lex.europa.eu/eli/reg/2021/821/oj?locale=en
국가법령정보센터: https://www.law.go.kr/
Identify which 15 C.F.R. Part 740 License Exceptions are foreclosed, out of scope, or worth reviewing for a transaction, and list the conditions each one requires. Applies the mandatory restrictions in 740.2, including 740.2(a)(9)(i) for semiconductor manufacturing equipment to Macau/Country Group D:5 and 740.2(a)(9)(ii) for advanced computing items. This tool does NOT determine that any exception is available; 'requires_verification' must not be read as 'yes'.
| Name | Required | Description | Default |
|---|---|---|---|
| eccn | Yes | ECCN with subparagraph, e.g. 3B001.f.1, 3A090.c, or EAR99. | |
| flags | No | ||
| itemType | No | hardware | |
| valueUsd | No | Per-shipment value in USD, used only for the LVS limit check. | |
| endUserType | No | commercial | |
| transactionType | No | export | |
| destinationCountry | Yes | Destination country. Matched against 15 C.F.R. Part 740, Supplement No. 1. | |
| entityHeadquarteredInMacauOrD5 | No | Set when the end user is headquartered in, or has an ultimate parent headquartered in, Macau or Country Group D:5. This triggers 740.2(a)(9)(ii) regardless of the shipping destination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It is transparent about applying mandatory 740.2 restrictions, names the specific semiconductor and advanced-computing subparagraphs, and explicitly warns that 'requires_verification' must not be read as an affirmative determination. It does not disclose the full output format or whether the operation is read-only, which prevents 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?
Three sentences with no filler: purpose and output, critical legal scope, and a safety caveat about misreading the result. The most important interpretive warning is placed prominently and every sentence earns its place.
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 an 8-parameter legal analysis tool with no output schema and no annotations, the description covers the core behavior and a key caveat but leaves gaps. It does not define 'foreclosed' versus 'out of scope' versus 'worth reviewing', does not describe the return structure beyond 'list the conditions', and does not explain how inputs drive the classification.
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 only 50%, and the description does not compensate for the undocumented parameters. It references 740.2(a)(9)(i) and (ii) but does not explain how flags such as highBandwidthMemory, encryption, or temporaryExport map to the analysis, nor how parameters like itemType or transactionType affect results.
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 action — identifying which Part 740 License Exceptions are foreclosed, out of scope, or worth reviewing — and the output is listing required conditions. This clearly differentiates it from sibling tools like determine_license_requirement or check_part744_enduse by scoping the analysis to 15 C.F.R. Part 740.
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?
The description implies this tool is used when analyzing whether License Exceptions survive mandatory 740.2 restrictions, but it does not explicitly state when to prefer it over sibling tools or when not to use it. There is no exclusionary guidance, so an agent must infer the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify Chinese export-control exposure under the Export Control Law, the 2024 Regulations on Export Control of Dual-Use Items, and the numbered MOFCOM announcements. Answers the question that decides most cases in this regime first: is the measure currently in force? Announcements Nos. 55, 56, 57, 58, 61 and 62 of 2025 are suspended by Announcement No. 70 of 2025 until 10 November 2026, while Announcement No. 18 of 2025 on seven medium and heavy rare earths is NOT suspended and still requires a licence. No. 61 has split commencement dates: its Chinese-origin limb began on 9 October 2025, while its content and technology limbs were due on 1 December 2025. A fact pattern that meets a suspended test is reported as license_required_if_reactivated with the expiry date, because the instruments are not repealed. This regime binds non-Chinese parties directly: Announcement No. 61 requires a MOFCOM permit for a shipment between two points both outside China, on a 0.1 percent content floor, and a 管控名单 designation prohibits parties in ANY country from supplying the listed entity with Chinese-origin dual-use items. Do not carry a U.S. de minimis conclusion across; § 734.4 is a 25 or 10 percent ceiling you fall below to escape, while No. 61 is a 0.1 percent floor you rise above to be caught. This tool does NOT classify items and does NOT screen entities, because neither the Export Control List for Dual-Use Items nor any designation list is bundled.
| Name | Required | Description | Default |
|---|---|---|---|
| asOfDate | No | ISO date to assess against, e.g. 2026-12-01. Defaults to today. Decides whether a suspended measure is operative. | |
| itemCategory | No | unknown | |
| endUserMilitary | No | No. 61 § 2: applications for foreign military users are in principle not permitted. | |
| exportToCountry | No | ||
| itemDescription | No | Free-text item description. Scanned for the controlled rare-earth elements, in English or Chinese. | |
| itemOriginChina | No | Whether the item was originally produced in China. No. 61 § 1(c). | |
| counterpartyNames | No | ||
| exportFromCountry | No | ||
| rareEarthElements | No | Rare-earth elements present, e.g. ['dysprosium','terbium']. | |
| chineseRareEarthTechnologyTypes | No | ||
| containsChineseOriginRareEarths | No | ||
| chineseOriginRareEarthValuePercent | No | Value of Chinese-origin rare earths as a percentage of item value. The No. 61 § 1(a) threshold is a 0.1 percent FLOOR, not a ceiling: 0.1 or more is caught. | |
| counterpartyIsSubsidiaryOfListedEntity | No | Whether a parent controlling 50 percent or more of shares is a listed user. No. 61 § 2 reaches such subsidiaries. | |
| producedOutsideChinaUsingChineseRareEarthTechnology | No | No. 61 § 1(b). The Chinese analogue of the Foreign Direct Product rules, with no percentage test. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers substantially: it discloses the output naming convention ('reported as license_required_if_reactivated with the expiry date'), exact suspension dates (Announcement No. 70 of 2025 through 10 November 2026), split commencement dates for No. 61, and the rationale that suspended instruments are 'not repealed.' The 0.1 percent floor versus 25/10 percent ceiling contrast also pre-empts a common reasoning error.
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?
Dense but every clause earns its place: in-force dates, extraterritorial scope, output naming, and the floor-versus-ceiling trap are all load-bearing. The structure is front-loaded — purpose first, then the deciding question, then dates, then scope boundaries. At roughly 230 words it is long, but for a 14-parameter legal tool with zero annotations the density is justified.
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?
Remarkably complete for a complex regime tool with no annotations and no output schema: legal basis, temporal validity, extraterritorial reach, and scope exclusions are all covered, including the counterintuitive extraterritorial application to shipments between two points outside China. The main gap is that only one output value (license_required_if_reactivated) is named; the full status taxonomy and any insufficient-information behavior are left unspecified.
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 57%, so the description must partially compensate, and it does for the pivotal parameters: asOfDate is explained as decisive for whether a suspended measure is operative, and the chineseOriginRareEarthValuePercent threshold is reinforced with the FLOOR-vs-ceiling warning. It also contextualizes the Chinese-origin, content, and technology limbs of No. 61 that several boolean parameters map to, though it does not walk through all 14 parameters.
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 precise verb+resource: 'Identify Chinese export-control exposure under the Export Control Law, the 2024 Regulations on Export Control of Dual-Use Items, and the numbered MOFCOM announcements.' Explicit boundary statements — 'This tool does NOT classify items and does NOT screen entities' — cleanly separate it from siblings like classify_eccn and screen_restricted_party, while the U.S. de minimis contrast distinguishes it from EAR-regime 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?
Gives clear exclusions that route to the right siblings: no item classification, no entity screening, and 'Do not carry a U.S. de minimis conclusion across' marks the boundary against US-regime analysis. It stops short of explicitly naming sibling tools or stating a positive selection condition, so some routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Determine whether an item is subject to the EAR before doing any classification or licence analysis. Applies the de minimis U.S.-content rule (15 C.F.R. 734.4) and all thirteen Foreign Direct Product rules (734.9) as independent routes. The FDP rules have NO percentage test: a foreign-produced item with zero U.S. content is subject to the EAR if a rule's product scope and destination or end-user scope are both met. The SME rule at 734.9(k) and the Footnote 5 rule at 734.9(e)(3) are the ones that reach Korean-manufactured semiconductor equipment.
| Name | Required | Description | Default |
|---|---|---|---|
| skipFdp | No | ||
| itemOrigin | No | U.S.-origin items are subject to the EAR under 734.3 and need no further jurisdiction analysis. | foreign |
| skipDeMinimis | No | ||
| foreignItemEccn | No | The foreign-produced item's own ECCN with subparagraph, e.g. 3B001.c, 3A090.a, or EAR99. | |
| foreignItemType | No | commodity | |
| destinedToCrimea | No | ||
| noDeMinimisFacts | No | Facts bearing on the 734.4(a) categories that have no de minimis level at all. | |
| usSoftwareBundled | No | For software: whether it ships bundled with the item. Separately exported U.S. software is never de minimis eligible. | |
| destinationCountry | Yes | Destination country, matched against Part 740 Supplement No. 1. | |
| entityListFootnotes | No | Entity List footnote designations of any party, e.g. [1], [4], [5]. Footnote 3 is Russia/Belarus MEU. | |
| category5Part2UsContent | No | ||
| containsIcFromSuchPlant | No | Whether the commodity contains an integrated circuit produced by such a plant. IC production here includes assembly, testing and packaging. Relevant to 734.9(e)(3) and (k). | |
| entityListFootnotesKnown | No | Set true once every party's footnote status has actually been checked on the Entity List. | |
| governmentOfIranIsAParty | No | ||
| usControlledContentPercent | No | Controlled U.S.-origin content as a percentage, calculated under Supplement No. 2 to Part 734. | |
| forSupercomputerInPrcOrMacau | No | ||
| producedUsingUsTechnologyEccns | No | ECCNs of the U.S.-origin technology or software used to PRODUCE the item, e.g. ['3E992']. This is the single most decisive input for FDP and is about production inputs, not the item's own content. | |
| commingledTechnologyReportFiled | No | Whether the one-time BIS report for commingled technology has been filed. Required before relying on de minimis for technology. | |
| producedUsingUsTechnologyInAnyDorE | No | Set when production used U.S.-origin technology or software in any product group D or E ECCN. | |
| recipientAtAdvancedNodeFacilityInMacauOrD5 | No | Recipient is at a facility in Macau or Country Group D:5 producing logic or DRAM advanced-node ICs. | |
| producedByPlantThatIsDirectProductOfUsTechnology | No | Whether the producing plant, or a major component of it, is itself a direct product of U.S.-origin technology or software. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It meaningfully reveals that the FDP rules have no percentage test, that zero U.S.-content items can still be subject to the EAR, that the rules operate as independent routes, and that specific rules reach Korean-manufactured semiconductor equipment. This goes well beyond a generic statement, though it does not describe the output form or how indeterminate facts are handled.
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 compact and front-loaded, opening with the core purpose and timing before explaining the legal rules. Every sentence carries substantive information: purpose, applicable rules, the no-percentage-test caveat, and the Korea-relevant rules. There is no filler or repetition.
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 complex tool with 21 parameters, a nested object, no output schema, and no annotations, the description gives strong legal context but omits operational essentials such as the required destinationCountry input, how to handle unknown facts, and what the determination output looks like. It is adequate for high-level orientation but not fully sufficient for correct invocation in all cases.
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 67%, so the schema already documents many parameters. The description adds important interpretive context, such as FDP having no percentage test and de minimis applying U.S.-content percentage, which helps agents understand usControlledContentPercent and producedUsingUsTechnologyEccns. However, it does not systematically compensate for the remaining undocumented parameters or map legal concepts to specific input fields.
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: 'Determine whether an item is subject to the EAR' and situates it before classification or license analysis. It distinguishes this jurisdiction-assessment tool from siblings like classify_eccn and determine_license_requirement by naming the exact legal rules it applies.
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?
The description explicitly says to use this tool 'before doing any classification or licence analysis,' giving clear workflow context. It names the de minimis and Foreign Direct Product rules as the applicable tests, though it does not state when not to use it or name an alternative tool for follow-on steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a due-diligence checklist for a transaction stage. The industry parameter materially changes the output: the semiconductor set covers 3B001 subparagraph scoping and the 744.23 advanced-node, SME and ECAD controls, while the battery set covers the absence of CCL entries for battery chemistry and the superficially matching entries to avoid.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | both | |
| transactionStage | No | pre_contract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full behavioral disclosure burden. It does disclose a key behavioral trait — the industry parameter 'materially changes the output' — and specifies content differences (3B001/744.23 for semiconductor, CCL absence for battery). But it does not disclose return format, whether the tool consults live regulatory data, or what happens with industry='both'.
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 purpose is front-loaded in the first sentence and the industry detail follows. The content is dense but purposeful. The second sentence is a long compound that could be restructured into conditional form per industry value, but no words are wasted.
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?
With no output schema and no annotations, the description must convey what the agent gets back and how parameters shape it. It covers the industry dimension well but omits the checklist's output format, the semantics of the five transaction stages, and the behavior of the 'both' enum value — leaving notable gaps for a 2-param tool with zero ancillary documentation.
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 0%, so the description must compensate — and it does well for 'industry', explaining exactly what each of the two industry sets covers. However, 'transactionStage' receives no semantic explanation beyond the schema's enum names; the checklist's stage-specific variation is never described. Compensation is partial, hence a 3.
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 opens with a specific verb+resource pairing — 'Generate a due-diligence checklist for a transaction stage' — which makes the tool's function immediately identifiable. It is clearly distinct from all siblings (classify_eccn, screen_restricted_party, draft_export_control_clause, etc.), none of which produce a checklist artifact.
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?
The scope 'for a transaction stage' implies when the tool applies, and the industry detail implies parameter-driven usage. However, it never explicitly states when to choose this over sibling tools (e.g., draft_export_control_clause or classify_transaction_risk), and gives no when-not-to-use guidance. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare this server's bundled EAR snapshots (Country Groups, the Part 740 License Exception catalog, and the Commerce Control List) against the latest eCFR issue date, and report which datasets need rebuilding. Requires network access to eCFR.
| Name | Required | Description | Default |
|---|---|---|---|
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully reveals that the tool makes a network request to eCFR, that it is a comparison/check operation rather than a mutation, and that it reports which datasets need rebuilding. It does not discuss failure behavior or explicitly state read-only status, but the 'compare and report' wording strongly implies a non-destructive check.
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 a single, well-structured sentence that front-loads the action and key scope, lists the checked datasets, states the result, and ends with the network prerequisite. Every clause earns its place, with no filler or redundancy.
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 simple check tool with one optional parameter and no output schema, the description covers what is checked, why, what the tool reports, and a key environmental requirement (network access). It does not detail the output format or behavior on network failure, but the core information an agent needs to decide to call it and interpret the result is present.
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 0%, and the description does not mention or explain the optional timeoutMs parameter at all. The schema's name, default, and min/max bounds provide basic meaning, but the description adds no context about how timeoutMs affects the network request or when an agent might want to adjust it.
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 clearly identifies the action ('Compare'), the subject ('this server's bundled EAR snapshots'), and the specific datasets involved (Country Groups, Part 740 License Exception catalog, Commerce Control List). It also states the outcome ('report which datasets need rebuilding'), making the tool's purpose fully distinguishable from the regulatory-analysis and clause-drafting siblings.
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?
The description gives a clear context for use: checking whether bundled EAR data is current relative to eCFR and needs rebuilding. It also flags a key prerequisite, network access to eCFR, which helps an agent decide whether to invoke the tool. It does not explicitly name alternatives or exclusions, but the sibling list shows no overlapping freshness-check tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the EAR Part 744 end-use and end-user issues that must be reviewed for a transaction: military end use (744.21) including the 50 percent affiliates rule, military-intelligence (744.22), nuclear (744.2), missile (744.3), chemical/biological (744.4), U.S.-person activities (744.6), and the supercomputer / advanced-node IC / semiconductor-manufacturing-equipment controls (744.23). This tool performs NO restricted-party screening and cannot clear a transaction; an empty issue list means the heuristic found nothing, not that the transaction is permissible.
| Name | Required | Description | Default |
|---|---|---|---|
| eccn | No | ECCN with subparagraph if known, e.g. 3B001.f.1, 3A090.c, or EAR99. | |
| flags | No | ||
| endUse | No | Stated end-use. | |
| endUser | No | End-user name or description. | |
| endUserScreening | No | ||
| additionalParties | No | Other named parties to screen: ultimate consignee, intermediate consignees, purchaser, freight forwarders, banks. | |
| destinationCountry | Yes | Destination country. Matched against 15 C.F.R. Part 740, Supplement No. 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so clearly: it discloses that the tool is a heuristic, performs NO restricted-party screening, cannot clear a transaction, and that an empty issue list does not mean the transaction is permissible. These are exactly the behavioral limitations an agent needs to avoid over-reliance.
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?
Two sentences with no filler: the first front-loads the purpose and scope in a compact enumerated list, and the second delivers the critical caveats. Every clause earns its place.
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 complex nested-schema tool with no output schema or annotations, the description explains what it returns ('list of issues'), what an empty result means, and what it cannot do. It could add a bit more detail on the exact output format or how flags should be populated, but the essential invocation and interpretation guidance is present.
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 71%, so the schema already explains many parameters. The description adds regulatory meaning beyond individual field labels by mapping the issue categories to Part 744 sections and mentioning the 50 percent affiliates rule, which clarifies the role of ownership and end-use flags. It does not walk through every parameter, but the aggregate framing plus the 'no screening' caveat provides useful selection context.
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 opens with a specific verb and resource: 'List the EAR Part 744 end-use and end-user issues that must be reviewed,' and then enumerates the exact regulatory sections covered (744.21, 744.22, 744.2, 744.3, 744.4, 744.6, 744.23). It also distinguishes itself from restricted-party screening and license-clearance tools by stating what it does not do.
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?
The first sentence identifies the use case (reviewing Part 744 end-use/end-user issues for a transaction), and the second sentence provides important when-not guidance: no restricted-party screening, cannot clear a transaction, and an empty result is not a compliance clearance. It does not explicitly name sibling tools as alternatives, so it stops just short of full 5-level routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the text of the Commerce Control List (15 C.F.R. Part 774, Supplement No. 1) for entries and paragraphs that mention the technical terms in an item description, and quote the controlling language verbatim together with the entry's Reason for Control and List Based License Exception flags. This tool does NOT classify the item: a text match means the paragraph is worth reading, and the absence of a match does not establish EAR99 status.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | Narrows which CCL categories are searched. Use 'other' to search all categories. | semiconductor |
| itemType | No | equipment | |
| keySpecs | No | Key technical parameters, e.g. exposure wavelength, etch selectivity, node size, cathode chemistry. | |
| itemDescription | Yes | Technical description of the item, software or technology. Technical nouns produce better matches than commercial names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and uses it well: it reveals the tool is a text-match searcher rather than a classifier, and explains the interpretation of both positive ('a text match means the paragraph is worth reading') and negative ('absence of a match does not establish EAR99 status') outcomes. It also pre-states the return envelope (verbatim quotes, Reason for Control, license exception flags). It stops short of disclosing limits such as result caps or pagination behavior.
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?
Two sentences with zero waste: the first front-loads the search-and-quote behavior, the second delivers the critical non-classification caveat. Every clause earns its place, and no schema content is needlessly repeated.
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?
Absent an output schema, the description covers the return-value contract (verbatim language, Reason for Control, List Based License Exception flags) and the no-match interpretation (does not establish EAR99). It could add workflow guidance — e.g., that actual classification should continue in a sibling like determine_license_requirement — but for a text-search tool the essential coverage is present.
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 high at 75% — industry, keySpecs, and itemDescription all have meaningful schema descriptions, and industry/itemType have enums — so the schema carries the semantic load. The description reinforces that itemDescription should contain 'technical terms' to be matched, but adds no new parameter-level meaning beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 precise verb+resource: 'Search the text of the Commerce Control List (15 C.F.R. Part 774, Supplement No. 1)' and specifies the exact output ('quote the controlling language verbatim together with the entry's Reason for Control and List Based License Exception flags'). The explicit 'does NOT classify the item' boundary clearly differentiates it from siblings like classify_transaction_risk, determine_license_requirement, and assess_ear_jurisdiction.
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?
Delivers explicit when-not guidance: 'This tool does NOT classify the item' and 'the absence of a match does not establish EAR99 status,' which prevents an agent from misusing it as a classification decision tool. However, it never names the alternative tools (e.g., determine_license_requirement, assess_ear_jurisdiction) that should be used instead, leaving that routing to inference rather than instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a triage score and review plan for a semiconductor or battery transaction. Terms are matched on word boundaries and negated statements are excluded from the score; the destination is assessed from the Country Group tables rather than from keywords. A 'low' tier is not a clearance -- no screening, classification or Part 744 analysis is performed here.
| Name | Required | Description | Default |
|---|---|---|---|
| endUse | No | ||
| description | Yes | Plain-language transaction description. | |
| counterparty | No | ||
| hasEuTouchpoint | No | ||
| destinationCountry | No | Destination country. Matched against 15 C.F.R. Part 740, Supplement No. 1. | |
| hasUsOriginTechnology | No | ||
| involvesTechnologyTransfer | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It reveals non-obvious matching semantics ('word boundaries', 'negated statements are excluded') and clarifies that destination is assessed from Country Group tables rather than keywords. It also warns that a 'low' tier is not clearance, which is important for correct interpretation of results.
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 three focused sentences with no filler. It front-loads the core purpose, then adds methodological caveats and a critical limitation. Every sentence contributes useful information.
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?
This is a moderately complex tool with seven parameters, no output schema, and no annotations, so the description must do more work. It covers overall behavior and limitations well, but it does not explain the format of the 'triage score', what the 'review plan' contains, or how the remaining parameters influence the result. An agent would likely need additional information to invoke it with full confidence.
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 only 29%, and the description partially compensates by explaining that terms are matched on word boundaries and that destination is assessed via Country Group tables—both relevant to the description and destinationCountry parameters. However, the other five parameters (endUse, counterparty, booleans) receive no semantic clarification, so interpretation still depends heavily on 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, resource, and outcome: 'Produce a triage score and review plan for a semiconductor or battery transaction.' It also distinguishes itself from related tools by explicitly saying no screening, classification, or Part 744 analysis is performed, so an agent can differentiate it from siblings like screen_restricted_party or classify_eccn.
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?
The description provides clear usage boundaries: it is a triage step, not a clearance, and it explicitly states what it will not do ('no screening, classification or Part 744 analysis'). It does not name alternative sibling tools directly, but the exclusions are specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work the Commerce Country Chart (15 C.F.R. Part 738, Supplement No. 1) for an ECCN and a destination, following the 738.4(a)(2) procedure. Reads every Reason for Control in the entry, resolves each to a chart column or to the prose destination scope the entry states instead (273 of the 1536 License Requirements rows state a scope rather than naming a column), and reports each requirement separately because 738.4(a)(2)(ii)(A) requires each one to be overcome on its own. Handles the cases a table lookup misses: the four embargoed destinations whose rows carry no marks at all, the footnotes that require a licence where the grid is empty, destinations that have no row and inherit another country's, and the 738.3(a)(1) entries that bypass the chart entirely. An absent mark is reported as 'no_chart_requirement', never as clearance.
| Name | Required | Description | Default |
|---|---|---|---|
| eccn | Yes | ECCN, ideally with subparagraph, e.g. 3B001.c, 3A090.a, 0A501.y. Rows in one entry are scoped to different subparagraphs and resolve differently, so a bare 3B001 will return a conditional answer. | |
| destination | Yes | Destination country. Matched against the rows of Supplement No. 1 to Part 738, whose spellings differ from the Part 740 Country Group tables. Hong Kong resolves to the China row. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers: it explains how every Reason for Control is resolved, that each requirement is reported separately, how unusual destinations and footnotes are handled, and that an absent mark is reported as 'no_chart_requirement' rather than clearance. This is well beyond a typical description.
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?
Every sentence earns its place. The description is front-loaded with the core procedure and then adds high-value nuance about edge cases and result semantics without redundancy or filler. The density is justified by the legal complexity of the 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?
For a complex tool with no output schema and no annotations, the description is unusually complete: it covers the procedure, per-requirement reporting, edge cases, and a critical result sentinel. It stops short of fully specifying the output structure, but an agent has enough context to invoke it correctly.
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%, and the schema already provides rich parameter details, including ECCN subparagraph guidance and Hong Kong resolving to the China row. The tool description itself adds no additional parameter-specific meaning, so the baseline score of 3 is appropriate.
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 precise verb and resource: 'Work the Commerce Country Chart ... for an ECCN and a destination'. It also differentiates itself from sibling tools like classify_eccn and analyze_license_exceptions by focusing specifically on the Part 738 chart and the 738.4(a)(2) procedure.
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?
The tool's usage context is clear: use it when you need to determine whether the CCL requires a licence for a given ECCN and destination. It does not explicitly list alternatives or when-not-to-use conditions, but the scope is unambiguous and the edge cases it handles make the intended invocation clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft Korean or English export-control and sanctions risk-allocation clauses. riskLevel selects cumulative clause tiers and materially changes the output: 'low' gives baseline compliance and termination provisions, 'medium' adds end-user certification, restricted-party notification and the 50 percent affiliates-rule representation, and 'high' adds conditions precedent tied to pre-shipment re-screening, Foreign Direct Product and de minimis acknowledgement, U.S.-person activity control, technology-access control, and a mandatory-rules provision.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ko | |
| riskLevel | No | medium | |
| transactionType | Yes | e.g. equipment supply, technology license, joint development, battery material long-term supply | |
| includeIndemnity | No | ||
| includeAuditRight | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does so well by explaining that riskLevel materially changes the output and listing what each tier adds (e.g., 'high' adds conditions precedent, FDP/de minimis acknowledgement). It stops short of describing the response format or any limitations, but the behavioral core is disclosed.
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?
One dense sentence carries all the essential information and front-loads the purpose before the riskLevel detail. The riskLevel enumeration is long but tightly packed; it could be more scannable with bullets, but no sentence is wasted.
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 moderate complexity (five parameters, no annotations, no output schema), the description covers the core invocation choices: language, riskLevel, and the output-changing behavior. The undocumented booleans and missing return-shape note are minor gaps because the parameter names and the drafting purpose make them inferable.
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 only 20%, so the description must compensate. It richly explains riskLevel and partially covers language ('Korean or English'), but it says nothing about includeIndemnity or includeAuditRight, leaving those booleans to be inferred from their names and defaults.
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?
Description opens with a specific verb ('Draft') and a precise resource ('Korean or English export-control and sanctions risk-allocation clauses'). It is clearly distinct from sibling tools such as classify_eccn or build_due_diligence_checklist, which perform analysis or checklist creation rather than contract drafting.
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?
The description makes the use case clear: drafting risk-allocation clauses, with language and riskLevel choices. It does not explicitly name alternatives or say when not to use it, but the context is strong enough to route an agent away from the analysis/checklist siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the current text of an article of the Korean Foreign Trade Act (대외무역법) or the Act on Private International Law (국제사법) from the law.go.kr Open API, falling back to a dated snapshot bundled with this server. Sub-articles are supported (제19조의2). Set the LAW_OC environment variable to a law.go.kr Open API account id to enable live retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| law | Yes | Supported statute short name. | |
| source | No | Use snapshot_only to avoid any outbound network request. | live_then_snapshot |
| article | Yes | Article label. Accepts 제19조, 제19조의2, 제20조, 제53조, 19조, 19-2. Note that the 2024-02-20 전문개정 split the old 제19조 into 제19조 (전략물자 지정·고시), 제19조의2 (수출허가) and 제19조의3 (상황허가). | |
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It reveals the network dependency on law.go.kr, the fallback to a dated bundled snapshot, support for sub-articles, and the need to set LAW_OC for live retrieval. It does not detail error handling or rate limits, but the core safety and operational behavior is adequately transparent.
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?
Three sentences, each with a distinct purpose: purpose and fallback, sub-article support, and setup requirement. No filler, no repetition of the schema's enum values, and the most important information is front-loaded.
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 retrieval tool with no output schema and no annotations, the description covers the material operational facts: what is retrieved, from which sources, fallback behavior, and required setup. It does not describe the response format or failure modes, but those are not essential for deciding whether and how to invoke the tool.
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 75%, so the baseline is close to 3. The description adds meaningful context beyond the schema: sub-article notation like 제19조의2 is explicitly supported, and the live-vs-snapshot behavior is tied to the LAW_OC environment variable, which helps interpret the 'source' parameter. timeoutMs remains undocumented, but its name and JSON schema constraints make it self-explanatory.
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 action ('Retrieve the current text') and a specific resource: articles of two named Korean statutes, with the official Korean names given. It also distinguishes itself from all 12 sibling tools, which are export-control drafting, classification, and screening tools; none retrieve statute text.
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?
The intended use case is clear: fetch a statute article for legal analysis or export-control research. It also explains the live-API vs. bundled-snapshot fallback behavior and the environment-variable requirement. It does not explicitly discuss alternatives or exclusions, but no sibling tool is a direct substitute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orientation map of the export-control regimes that bear on a Korean semiconductor or battery transaction, and — importantly — which of them this server actually models against the regulation text versus merely flags for manual review. Read the coverageInThisServer field of each regime before relying on any other tool.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | Research focus, e.g. semiconductor equipment exports to China or battery technology licensing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself discloses an important behavioral limitation: the server may not fully model all regimes and may merely flag them for manual review. It also instructs reading the coverageInThisServer field, exposing a data-quality caveat that is essential for relying on downstream tools.
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 compact and front-loaded: the first sentence defines scope and key caveat, and the second sentence gives an actionable directive. Every phrase earns its place; the 'importantly' interjection highlights the crucial limitation.
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?
Despite the lack of an output schema, the description covers the tool's purpose, key output field (coverageInThisServer), and critical usage ordering. It does not detail the full return structure, but for an overview tool with a single optional parameter, the essential information an agent needs to call it correctly is present.
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?
The single optional 'focus' parameter is fully documented in the schema with a descriptive example, so schema coverage is 100%. The tool description does not add extra semantics about this parameter beyond the schema, so the baseline score of 3 applies.
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 clearly identifies the tool as an 'orientation map' of export-control regimes relevant to Korean semiconductor or battery transactions, and distinguishes its core function from siblings by emphasizing the distinction between regimes the server actually models versus those flagged for manual review. The title and description align, and the resource and scope are explicit.
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?
The description provides a clear usage directive: 'Read the coverageInThisServer field of each regime before relying on any other tool,' which tells an agent to invoke this tool first as an orientation step. It does not explicitly name alternative tools or when-not conditions, but the 'before any other tool' instruction effectively establishes its role among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen one or more party names against the U.S. Consolidated Screening List bundled with this server: BIS Entity List, Denied Persons List, Unverified List and MEU List; OFAC SDN, SSI, CMIC, NS-MBS, PLC and Capta; State ITAR Debarred and Nonproliferation Sanctions. Returns ranked candidate matches with the operative licence requirement and the authority for each list. A no-match result is NOT clearance: ownership is not screened, so the 50 percent affiliates rule under 744.21(a)(3) can catch an unlisted entity that produces no hit here.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Party names to screen. | |
| country | No | Destination or party country. Used only to annotate matches, never to exclude them. | |
| minScore | No | Confidence floor, 0-100. Lower it for transliterated or non-Latin-script names. | |
| listCodes | No | Restrict to specific lists. Omit to screen against all of them. | |
| maxResults | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses that the data is bundled with the server, that results are ranked candidates with license requirement and authority, and most importantly that ownership is not screened and the 50% affiliates rule can catch an unlisted entity. These are exactly the behavioral caveats an agent needs before acting on a 'no match' result.
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?
Three sentences with no filler: purpose/scope, return value, and the critical false-clearance warning. The long first sentence is information-dense rather than padded, and the most important caveat is placed last where it can emphatically close the description.
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 complex screening tool with no output schema, the description covers the essential operational context: list coverage, return content, and the affiliate-rule risk. It doesn't describe the structure of a candidate match or how 'ranked' scores should be interpreted, but those are relatively minor given the detailed input schema and explicit caveat.
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 80%, so the schema already documents names, country, minScore, and listCodes. The description adds useful list-name expansion and the caveat about no-match, but it doesn't materially elaborate on parameter behavior beyond what the schema states; it therefore meets the baseline but does not exceed it.
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 opens with a specific action ('Screen one or more party names') and a specific resource (the U.S. Consolidated Screening List bundled with this server), then enumerates exactly which BIS, OFAC, and State lists are covered. It even states the output ('ranked candidate matches with the operative licence requirement and the authority for each list'), making it clearly distinct from siblings like determine_license_requirement or check_part744_enduse.
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?
The description makes the intended context clear: use it to screen party names against the bundled U.S. list set, and it explicitly warns that a no-match result is not clearance. It does not, however, name sibling tools or state when an alternative should be used instead, so it falls just short of full routing guidance.
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.
v0.4.1analyze_license_exceptionsassess_china_export_controlsassess_ear_jurisdictionbuild_due_diligence_checklistcheck_data_freshnesscheck_part744_enduseclassify_eccnclassify_transaction_riskdetermine_license_requirementdraft_export_control_clauseget_korean_law_articleregime_overviewscreen_restricted_partyScored across 13 tools
The tools map to distinct workflow stages—jurisdiction, CCL text search, license requirements, exceptions, end-use, restricted-party screening, China controls, and drafting—so their purposes are largely separable. A few names could still be conflated: classify_eccn does not actually classify an item, and determine_license_requirement versus analyze_license_exceptions are both license-stage analyses, though their roles are ultimately distinct.
Almost all tools follow a snake_case verb_noun pattern such as draft_, build_, get_, check_, screen_, assess_, determine_, and analyze_. regime_overview breaks that pattern as a bare noun phrase, and classify_eccn uses an abbreviation rather than a full noun, but the naming is otherwise predictable and readable.
Thirteen tools is well suited to a compliance domain spanning U.S. EAR jurisdiction, Part 744 end-use rules, the Country Chart, license exceptions, restricted-party screening, Chinese export controls, Korean law retrieval, and compliance drafting. Each tool has a distinct purpose, and the count stays within the coherent range without redundant utilities.
The set covers the main transaction workflow: EAR jurisdiction, CCL text search, license requirement determination, license exception analysis, end-use checks, restricted-party screening, China controls, and Korean law access. Minor gaps remain around true ECCN classification, direct retrieval of full CCL entries, and Korean or Chinese restricted-party screening, but agents can work around these using the provided search and regime-coverage tools.
Contract drafting, statute-cited US state law requirements, non-compete checks, risk analysis.
Korea AI Basic Act compliance MCP — in force 22 Jan 2026. High-impact AI + GenAI labelling + MSIT
Korean tax-office and fair-trade registries, HS codes, landed cost. Two tools need no API key.
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
