Skip to main content
Glama

Export GTM plan for a product

gtm_plan
Read-onlyIdempotent

START HERE. One call returns the export go-to-market plan for a product: which countries to sell to (UN Comtrade imports × reply rates from 2.2M real export emails, compared within the product's industry, plus the next-best markets to compare), which buyer types reply there, how many follow-ups to send, the channels (creator seeding and marketplaces for consumer goods; buyer lists and trade shows for industrial goods; see motion), compliance flags with an official source link (compliance_gate marks approvals that block the market until they pass; channel_plan.packaging adds EU packaging EPR), a before_you_sell checklist (sanctions, FTA and proof of origin, trademark, payment terms, holidays, re-export hubs), the official tariff lookup (tariff_by_market compares the markets side by side), data_first (where the data would start even when you pass a country), gated_markets (compared markets with such a gate), banned_markets (those of them closed outright by an ingredient ban, such as ingredients of human origin: no approval opens them, so data_first, the market the data picks and next_markets skip them), next_markets (where to move at week 13, by the same rule as data_first, skipping gated markets and exclude), English email drafts (first email, follow-ups, week-3 sample check-in, and quote_reply_email for when a buyer asks for a price first; for Japan the same drafts in Japanese as local_emails, first_email_variants included), reply_target (expected replies from the product's own industry in that market, sends for 10 replies, the week-13 rule; reply_pace checks your numbers against it each week), a 13-week schedule, buyer_sources (trade fairs with the next edition's dates, city and book_meetings_from, 6 weeks before; BuyKOREA, KOTRA), and the exact treg.to endpoints (ids + prices) to execute it. blind_spots lists what exporters miss in the focus market beyond the category's compliance pointer, triggered by the exact HS code and product traits (product_traits; pass description or traits): rules that can stop the sale, approvals before import, extra duties or charges and filings, each with who acts, the date it applies from, the official source and the date checked; blind_spots_by_market names them for the other markets in the table, blind_gate is the one that blocks the sale when the compliance pointer has no gate, and gated_markets includes markets with such a blocker. Called signed in (/mcp/account) for a plan the account has not saved, save_plan gives the my_progress call (start = the coming Monday) that puts it on the user's dashboard. Sanctioned markets are never picked and are flagged. The full answer (default) runs 40,000-80,000 characters; detail=brief keeps the plan and leaves out channel_plan.steps (call channel_plan for endpoint ids, prices and request bodies) and the alternative first-email drafts (first_email_variants, the Japanese ones too), listing what it left out in omitted: use it for a first answer or to compare markets, and the full answer when picking drafts in the weekly routine. The first line of the answer leads with the market and why (reply multiple, imports, growth); when country is given and the data would start elsewhere it says so. plan_url opens the same plan as a one-page web page to print, save as PDF or share (with weekly tracking); ask_next lists the next questions to offer the user. Free, read-only.

Input Schema

NameRequiredDescriptionDefault
itemYesProduct as an HS4 code (e.g. '3304') or a name in English or Korean (e.g. 'sunscreen', '라면'). Names cover TradeGraph's 35 items; any other product works as a 4-digit HS code (e.g. '1905' biscuits, '2005' kimchi, '3305' shampoo) with live UN Comtrade imports.
detailNoOptional: brief (about half the size, for chat clients with a result size limit) or full (default, every draft).
originNoOptional: where the product is made, ISO alpha-2 (default KR, or the signed-in company's origin). TradeGraph's reply data comes from Korean exporters: another origin is left out of the markets and origin_check says what applies.
traitsNoOptional: product traits, comma-separated, that change the rules within one HS code: sunscreen, whitening (also arbutin, kojic acid), vitamin_a (retinol), gel_nail (UV/LED gel, semi-cured strips), contact_lens (HS 9001: contact lenses, colour lenses), hair_dye, hair_loss, acne, antiperspirant, dandruff, fluoride (toothpaste), human_derived (human stem cell culture media, human placenta, cord blood: a ban in the EU, UK, China and ASEAN), stem_cell (stem cell culture media whose source is not named: check it), exosome, radio (Bluetooth, Wi-Fi, cellular), battery, meat, dairy, egg, aerosol, flammable. Also detected from item, product and description; the answer lists them in product_traits.
countryNoTarget country as ISO 3166-1 alpha-2 (e.g. 'US', 'JP') or an English/Korean name. Optional: omit to let the data pick the market.
excludeNoOptional: markets already tried, comma-separated ISO codes or names (e.g. 'DE,PL'); next_markets skips them.
productNoOptional: the product's own name in English for the first-email draft (e.g. 'kimchi', 'sunscreen'), up to 60 characters. Defaults to the item name; for a live HS code without it the draft says 'products under HS 2005'. A name not in English is not put in the English drafts (product_note says what they use).
descriptionNoOptional: the product as the user describes it, any language (e.g. '비건 선크림 SPF50', 'Bluetooth speaker with a rechargeable battery', 'ramen with beef broth'). Used only to detect product traits that change the rules within one HS code (see traits).
product_localNoOptional, Japan: the product's name in Japanese for the Japanese drafts (local_emails), e.g. 'カシミヤ混ニット'. A product written in Japanese is used there too.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, it discloses what annotations cannot: the 40,000-80,000 character output size, exactly what detail=brief drops (channel_plan.steps, first_email_variants) and that omissions are listed in `omitted`, the auth requirement, that sanctioned markets are never picked, and what the first line of the answer contains. This is the kind of behavioral context that materially changes how an agent calls the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the rest is a single sprawling paragraph of nested parentheses enumerating output fields (reply_target, blind_spots, gated_markets, banned_markets, next_markets...) with no headings or ordering. Most of it is schema-redundant enumeration that an agent must wade through to find the actionable constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema, the description covers inputs, output shape, sizing, auth and follow-up calls thoroughly. Nothing an agent needs in order to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 still adds consequences beyond schema text, e.g. that passing `country` does not prevent data_first from starting elsewhere, that `exclude` is consumed by next_markets, and what brief mode does with `detail`. It does not add much for `traits`/`description` beyond what the schema already enumerates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening ('START HERE. One call returns the export go-to-market plan for a product') names a specific verb and resource, and the body distinguishes the tool from siblings by delegation (channel_plan for endpoint ids/prices, blind_spots, reply_pace, save_plan). An agent can tell what this call returns without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit guidance exists: 'START HERE', use detail=brief 'for a first answer or to compare markets', use the full answer 'when picking drafts in the weekly routine', sign in required for unsaved plans, and save_plan/plan_url as follow-ups. It lacks any exclusion against near-siblings like market_picks, market_scan or export_rank, so the agent must infer when this tool is the wrong choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources