Assess PRC export controls (MOFCOM)

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.