Which certificate (CPC, GCC, FCC, FDA), what marketplaces ask, supplier blacklists, customs holds.
Scored across 5 tools
The five tools target distinct seller-compliance queries: channel selling permission, supplier blacklist screening, CBP shipment holds, recent rule changes, and certificate requirements. Some overlap exists between marketplace_asks and which_certificate around product documentation, but descriptions provide clear triggers and exclusions.
All names use snake_case with a consistent seller_compliance. prefix, but the second segment mixes verb_noun (screen_supplier), noun_verb (shipment_held), and question phrases (what_changed, which_certificate). This is readable but not a single predictable pattern.
Five tools cover the major compliance question types without redundancy, and each tool has a clear, non-overlapping purpose. The count is well within the typical 3–15 range for a focused domain server.
The surface covers core US seller-compliance workflows: selling eligibility, supplier screening, held shipments, rule updates, and certificates. Intentional exclusions (tariffs, non-US rules, response writing) leave minor gaps for adjacent needs, but no critical dead ends within the stated scope.
Use this when a seller asks whether they can sell a product on Amazon, Walmart, TikTok Shop or Etsy, to stores, or on their own website, and what each will ask for: "can I sell toys on Amazon?", "requirements for selling supplements on Amazon", "how do I get approved (ungated) to sell kids' clothes?", "Amazon asked for compliance documents, what do I send?", "can I sell a stroller on Etsy?". Give the product in the seller's words and the channels. It returns closed or restricted doors first, then each channel's own rules for that product and the US federal law that applies everywhere, each line numbered to its source with the page's date and the day it was read. It first needs the certificate answer for the product, so it may return questions instead: ask the seller all of them and call again with their answers. Do not use for duties, tariffs or customs classification (HS or HTS codes), for marketplaces outside the US (Amazon UK, Amazon.ca or EU sites, for example), or to promise that a listing will be approved.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | No | The seller's answers to the questions an earlier call listed: answer key → one of that question's values, exactly as listed. Only pass what the seller actually said. | |
| product | Yes | The product in the seller's own words, e.g. "plush teddy bear", "kids rain boots", "bluetooth speaker", "ceramic coffee mug". | |
| channels | No | Where the seller will sell, in the United States only: amazon (amazon.com, not Amazon UK, Amazon.ca or other countries), walmart, tiktok (TikTok Shop US), etsy, wholesale (to US stores), own (their own website, selling in the US). If the seller is selling outside the US, do not call this tool. | |
| fda_kind | No | Only when an earlier call listed the answer key `fda_tap`: the value the seller chose. | |
| other_kind | No | Only when an earlier call listed the answer key `other_tap`: the value the seller chose. | |
| made_for_children | No | Whether the product is made mainly for children 12 or under. Leave it out unless the seller said. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world). The description adds substantial behavioral context beyond that: results are ordered with closed doors first, each line is numbered to its source with page date and read date, and the tool may return clarifying questions requiring a second call with answers. That multi-turn contract is the most valuable disclosure. Rate limits or failure modes are not mentioned, so not a full 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 'Use this when...' clause, then return behavior, then exclusions, which is good structure. The five inline example queries are long but serve trigger-matching. Slightly dense; a couple of examples could be trimmed, so not a 5.
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, the description carries the return-shape burden and does so: result ordering, per-line source citation with two dates, and applicable federal law. Combined with the clarifying-question loop and the answers flow, an agent has everything needed to call, re-call, and interpret results.
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 3. The description earns extra credit by explaining the two-phase input flow: the first call may return questions, and answers/fda_kind/other_kind exist to feed that back, with 'ask the seller all of them and call again with their answers.' That framing adds meaning the schema alone does not convey.
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 subject (whether a seller can sell a product on named US channels), what it returns (closed/restricted doors first, then per-channel rules and applicable US federal law), and its sourcing behavior. An agent can instantly distinguish it from which_certificate or screen_supplier.
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 gives concrete trigger phrasing ("can I sell toys on Amazon?", "Amazon asked for compliance documents...") plus explicit exclusions: no duties/tariffs/HS-HTS classification, no non-US marketplaces, no promises of listing approval. When-to-use and when-not-to-use are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a seller wants to check a supplier or factory against US government blacklists before paying it: "is this factory on the UFLPA list?", "is my Alibaba supplier sanctioned?", "check this supplier for forced labor". Give the company name as the seller has it, for example from the invoice or the store page. It searches the UFLPA Entity List and CBP Withhold Release Orders (forced labor) and the OFAC SDN and Consolidated lists and the US Consolidated Screening List (sanctions), and returns, per list, match, possible match, no match or not searched, with the list's size and date. It checks the name as typed, not a confirmed company, and it is not a record: no listed names, no citations. Do not use to check a person, to judge a supplier's quality, honesty or fraud risk, for lists outside the US, or as proof for customs.
| Name | Required | Description | Default |
|---|---|---|---|
| supplier_name | Yes | The supplier's company name as the seller has it, e.g. from the invoice or the store page. A company only: if the seller names a person, do not call this tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: it checks the name as typed rather than a confirmed company, is not a record (no listed names, no citations), and describes per-list return states (match/possible match/no match/not searched with list size and date). This is rich, non-redundant behavioral disclosure.
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 trigger ('Use this when...') followed by examples, list coverage, limitations, and exclusions. Dense but each sentence carries purpose; the example phrasings aid matching. Slightly long, but no filler.
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?
No output schema exists, yet the description explains the return structure per list. Combined with annotations covering safety and the description covering scope, limitations, and exclusions, an agent has everything needed to call 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 single parameter's guidance ('as the seller has it, e.g. from invoice or store page; company only') largely mirrors the description. The only added nuance is 'checks the name as typed, not a confirmed company,' so the description does little beyond what the schema already documents. Baseline 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?
States a specific verb+resource: checking a supplier/factory against named US government blacklists (UFLPA, CBP WRO, OFAC SDN/Consolidated, Consolidated Screening List). It also distinguishes its scope from neighboring concerns (person checks, quality/fraud judgment, non-US lists), so an agent can identify it without opening 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?
Opens with explicit trigger conditions and example phrasings ('is this factory on the UFLPA list?'), and gives concrete exclusions: do not use for a person, supplier quality/honesty/fraud, non-US lists, or customs proof. When-to-use and when-not are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a seller's shipment is held, detained or under review by US Customs (CBP) and they want to know what kind of hold it is, how long they have, and which documents are usually needed: "customs is holding my shipment, what does the detention notice mean?", "I got a CBP Form 4647", "my container has a CPSC hold", "my shipment says under CBP review", "CBP detained my goods under the UFLPA, how long do I have?". It works from the seller's answers to up to three questions about what the notice says (forced labor, another agency such as CPSC, FDA or FCC, or the stated reason, such as a CF-28 or CF-29), and it never sees the notice itself. It returns the hold type, the response deadline or where to find it on the notice, the usual path and who leads it, and the documents usually needed, each cited to its CBP or federal source with the date it was read. When questions are still open, it lists them with their answer keys: ask the seller, then call again with their answers. Do not use it to read or summarize the notice itself: point the seller to the customs-hold check on tiana-co.com, which reads a notice only after the seller agrees to send it. Do not use it to classify goods or give duty rates, to say whether a shipment will be released, or for customs outside the United States. If the seller asks you to write, argue or file a response to CBP or another agency, do not call this tool: a licensed customs broker or a customs attorney handles the response.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | No | The seller's answers about the notice, by answer key. Leave out any question the seller has not answered: never fill in "no", "unsure" or "none" for the seller, even when the form named seems to make the answer obvious. The tool then asks it. | |
| notice_date | No | The date printed on the notice, YYYY-MM-DD, only if the seller gives it. Used only for a forced-labor (UFLPA) detention, whose response window is counted from it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-open-world), and the description adds substantial context they cannot convey: it operates only on the seller's answers to up to three questions, never sees the notice, returns hold type plus the response deadline or where to find it, the usual path and lead party, and documents each cited to a CBP or federal source with a read date, and it lists unresolved questions with answer keys for a follow-up call.
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 trigger condition, then the mechanism, return shape, exclusions and escalation path in a logical order; every sentence carries information. It is dense and long for a single paragraph, and the quoted sample utterances could be trimmed, but the verbosity tracks genuine tool complexity rather than padding.
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?
No output schema exists, so the description must describe returns — and it does (hold type, deadline or its location on the notice, path and lead, cited documents, open questions with answer keys). Combined with the retrieval-then-recall workflow and clear scope limits, an agent has everything needed 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%, so the enum values and the notice_date UFLPA-window rule are already documented, giving a baseline of 3. The description adds meaning the schema alone does not: the 'up to three questions' framing, the fact that unanswered keys are surfaced as open questions, and the call-again loop that ties the answers object to a repeat invocation.
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: interpreting a customs hold (detention/deadline/documents) from a seller's description of a CBP notice. It is immediately distinguishable from siblings like screen_supplier, which_certificate, marketplace_asks and what_changed, and the opening clause names the exact triggering situation.
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 enumerates when to use it (held/detained/under CBP review, multiple concrete utterances) and when not to: reading the notice itself (routes to the customs-hold check on tiana-co.com), classifying goods, giving duty rates, predicting release, non-US customs, and writing/arguing/filing a response (routes to a licensed broker or attorney). Alternatives and exclusions are named, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a seller asks what changed recently in US selling rules: Amazon, Walmart, TikTok Shop or Etsy policy updates, or new federal rules ("did Amazon change anything for toys this week?", "any new seller rules?"). It returns this week's changes, each with its source, the page's own date and the day it was checked, and names the pages that could not be checked. Do not use for tariff or duty changes, or for rules outside the US.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral value by disclosing the return shape (source, page's own date vs. day checked) and, importantly, that some pages could not be checked and are named as such — useful for interpreting partial coverage.
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 usage condition and examples are front-loaded, and the exclusions close the description. It is a single dense sentence, but every clause (examples, return contents, unchecked pages, exclusions) carries routing or behavioral information rather than filler.
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?
There is no output schema, so the description must carry the return semantics itself — and it does, describing the fields returned and the caveat about uncheckable pages. Combined with the explicit scope boundaries, an agent has everything needed to call 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming that no input is required. Baseline 4 applies for a parameterless tool.
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: it returns this week's changes in US selling rules across four named marketplaces plus federal rules. The scope is precise and an agent can tell it apart from siblings like which_certificate or shipment_held, which answer different seller questions.
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?
Explicit trigger conditions are given with sample user phrasings ('did Amazon change anything for toys this week?', 'any new seller rules?'), plus two hard exclusions: tariff/duty changes and non-US rules. The agent knows both when to call and when to route elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a seller asks which US safety certificate or import paperwork a product needs: a CPC (Children's Product Certificate) for children's products, a GCC (General Certificate of Conformity) for other regulated products, FCC authorization for electronics, or FDA's import steps for food, supplements, cosmetics, drugs and medical devices (facility registration, prior notice, FSVP). For example: "does my kids' raincoat need a CPC?", "do I need a GCC for a coffee mug?", "Amazon wants a certificate for my toy, which one?", "do I need FDA prior notice to import snacks?". Give the product in the seller's own words. It answers from US federal rules and returns the rule each answer rests on, the date that rule was read, and a link to the free plan. When questions are still open, it lists them with their answer keys: ask the seller all of them, then call again with the same product and their answers. Do not use for duties, tariffs or customs classification (HS or HTS codes), for rules outside the United States, or to fill out, file or declare anything at customs. If the seller asks you to fill out or file a customs entry, do not call this tool: a licensed customs broker files the entry.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | No | The seller's answers to the questions an earlier call listed: answer key → one of that question's values, exactly as listed. Only pass what the seller actually said. | |
| product | Yes | The product in the seller's own words, e.g. "plush teddy bear", "kids rain boots", "bluetooth speaker", "ceramic coffee mug". | |
| fda_kind | No | Only when an earlier call listed the answer key `fda_tap`: the value the seller chose. | |
| other_kind | No | Only when an earlier call listed the answer key `other_tap`: the value the seller chose. | |
| made_for_children | No | Whether the product is made mainly for children 12 or under. Leave it out unless the seller said. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds traits annotations cannot: the tool returns the rule each answer rests on, the date that rule was read, and a link to the free plan. It also discloses the two-phase behavior when questions remain open — the response lists open questions with answer keys, and the agent must collect the seller's answers and call again with the same product.
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 use case and answer taxonomy, then examples, then exclusions — a sensible order with little filler. The four example questions are mildly redundant with the enumerated certificate types but earn their place as trigger-phrase anchors for an agent matching user phrasing.
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?
No output schema exists, so the description carries the return-value burden and does so (rule, rule read date, free-plan link, open questions with answer keys). For a read-only, multi-turn advisory tool with a nested `answers` object, everything an agent needs to call it correctly across both turns 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 100%, so the baseline is 3. The description goes beyond the schema by explaining the round-trip contract for `answers` (ask the seller all listed questions, then re-call with the same product plus their answers) and by instructing 'give the product in the seller's own words', which reinforces the free-text intent of `product`.
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+resource (tells a seller which US safety certificate or import paperwork a product needs) and enumerates the exact answer space: CPC, GCC, FCC authorization, FDA import steps. It is clearly distinguishable from siblings like screen_supplier or marketplace_asks without opening any 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 explicit trigger phrases and four worked example questions, plus explicit exclusions (not for duties/tariffs/HS-HTS classification, not for non-US rules, not for filling out or filing customs entries) and names the alternative actor (a licensed customs broker files the entry). Both the when and the when-not are spelled out.
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.
seller_compliance.marketplace_asksseller_compliance.screen_supplierseller_compliance.shipment_heldseller_compliance.what_changedseller_compliance.which_certificateHelps a small importer get the US safety certificate for a consumer product ready before it ships.
Source-cited EU/UK/US/AU market-access checks for Amazon and cross-border product compliance.
Deterministic China trade compliance: GACC customs, CCC clearance, and PIPL transfers.
Is a foreign supplier on an FDA import alert red list, detained at the US border? 14,000+ listings.
Add one secure layer between your agents and this server.