Skip to main content
Glama

Go-to-market context graph: every job in one market (video, creators, listings, buyers)

context_graph
Read-onlyIdempotent

The context graph for one product in one market, for every go-to-market job beyond the buyer list: short-form video ads, creator seeding, marketplace listings and images, trends and social listening, buyers, pricing and the rules before sale (industrial goods: buyers, trade shows, search demand, pricing, rules). One read is meant to be enough to do the job correctly. How to read it: (1) shared_brief holds the lines that bind several jobs, said once (the sale gate, the trademark, wording to change, duty and proof of origin); each job lists their keys in shared. wait_for_gate on a job means nothing is published, listed, sent or pitched before the gate clears; gate.ban means no approval lifts it and the product as it is cannot be sold there. blocked_by on a job means that job is prohibited in this market (advertising alcohol other than beer in Poland, selling alcohol online in Taiwan): the brief says so instead of how to do it, and nothing is made. (2) A job's brief holds that job's own instructions; a rule or node id named in a line is a node whose text says what to do. needs_prior_consent means sales email there goes only to buyers who agreed to it. (3) uses lists the nodes the job reads. Rule nodes carry the gist (text), who must act, the status and start date, lead_time for approvals and the official source with the date it was checked; deadlines lists the rules that start within 13 weeks. (4) Calls: read_first_calls before creating (or reuse a fresh last_read), then next, then then. Every call passes its tool's input schema as given; fill lists the arguments to ask the user for ({arg, ask, example}); needs: account marks tools that exist only when signed in. Money: a call with paid: true charges credits itself (find_buyers). A job with paid: true costs est_cost_usd in total for cost_for, charged by charged_by (live_call = the paid data and generation steps that the job's next call lists); a job with paid: false has no cost fields. Show the cost and get approval before either. Evidence: reply figures name their yardstick. The market node's reply_vs_avg is measured on the product's industry (reply_scope industry, reply_basis says what 1.0 means, with the 90% interval and the buyers contacted); buyer-type nodes are ranked on all industries' emails (reply_scope all), because the data has no cell for an industry by buyer type. When the market's confidence is stronger than any buyer type's, the market node says why in buyer_evidence, and the buyers brief leads with the product's own expected replies (the same figure as gtm_plan's reply_target). Nodes come from the same sources as gtm_plan, video_studio, image_studio, channel_plan, price_ladder and blind_spots (same sale gate, claims_check and, signed in, the same company): the market (UN Comtrade imports, growth, Korea's share), buyer types and the channels buyers answer on (rank), the creator platforms in order with the first one's video format, the marketplaces in order with the first one's main-image rule, language, everyday scene, claims, disclosure and AI-content rules, product rules and easy-to-miss requirements, the price ladder multiple, and the live-data signals to read first (motion names the channel_plan call that returns their endpoints and prices). There are no edges: order is each node's rank. Each job reads the requirements that bind it, the easy-to-miss ones included: ad rules for video and seeding, rules for sending samples to creators and buyers (e.g. US Prior Notice covers food samples, alcohol cannot go by US mail), listing and label rules plus what you take on when you sell direct by parcel without an importer (e.g. Japan's 24 units per item, packaging EPR), prior consent for sales email, approvals a buyer asks about first, and extra duties or taxes for the price. Korea-only lines (Korean FTAs, KOTRA pavilions) are left out for products made outside Korea. rules_coverage says how much TradeGraph knows for that market (national, bloc, pointers or none: none is not a clearance); rules_page links the public page with the same rules when there is one. Signed in, it starts from the company's own records (learned): the last market reads saved with company_context (kind=signal) sit on the signal nodes with their age and whether they are stale, so a fresh read is reused instead of paid for again; seeding_list results per platform sit on the platform nodes and the seeding brief; hook tests (kind=result) sit on the video format and brief, so the next video starts from the angle that held best. Save what you learn the same way so the next graph starts from it. These are the company's own numbers only; nothing is shared with other companies. Call it after gtm_plan when the user wants to launch in a market ("what do we need for Japan", "make videos for TikTok in Vietnam", "list on Qoo10"), or before video_studio and image_studio so hooks and frames start from the market. Omit country to use the data's first market. job returns one job only, with the nodes and shared lines that job needs. Free, read-only.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "item": "<item>"
    },
    "name": "context_graph"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobNoOptional: one job only (smaller answer). Default all.
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.
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, industrial or household (for HS codes that hold both, such as 8414 fans, compressors and vacuum pumps: picks machinery rules, trade fairs and buyer searches, or household-appliance ones). 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 use the market the data picks first (the same as gtm_plan).
productNoOptional: the product in plain English as it looks or is sold (e.g. 'vegan sunscreen SPF50, 50 ml white tube'), passed on to the next calls.
descriptionNoOptional: the product as the user describes it, any language (e.g. '비건 선크림 SPF50', '할랄 인증 저가 립스틱', 'premium anti-aging ampoule already on Amazon US'). Used to detect product traits that change the rules within one HS code (see traits) and the concepts, price tier, certifications and markets already selling that change which market fits (product_profile, entry_paths).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Well beyond the readOnly/idempotent/openWorld annotations, it discloses that the call is free, that some downstream calls charge credits and require approval before spending (paid, est_cost_usd, charged_by), that signed-in users get company-scoped learned data with staleness tracking, and that nothing is shared across companies. It also explains evidence semantics (reply_scope industry vs all, reply_basis) and rules_coverage limits, which the annotations cannot carry.

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 description is a single enormous block that documents output structure, cost accounting, evidence methodology, signed-in reuse and call ordering all at once. The most actionable line for tool selection (when to call it, relative to gtm_plan) is buried at the very end rather than front-loaded. Numbered markers (1)-(4) help somewhat, but the volume far exceeds what an agent needs to choose and invoke the tool.

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 complex, multi-job, no-output-schema tool, the description covers what a returned job contains (shared_brief, shared keys, wait_for_gate, blocked_by, needs_prior_consent, uses, rule node fields, deadlines), how ordering works (rank, no edges), and how coverage and paid cost are signaled. An agent has enough to interpret the response without an output schema.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema descriptions already explain item formats, trait detection, country fallback and product/description passthrough in detail. The description only adds the framing that 'job returns one job only, with the nodes and shared lines that job needs', which is largely a restatement of the schema's 'one job only (smaller answer)' note. Baseline 3 is appropriate since the schema does the heavy lifting.

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

Purpose4/5

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

The first sentence names the resource and its scope precisely: a context graph for one product in one market, covering video, seeding, listings, listening, buyers, pricing and sale rules. It also distinguishes itself from siblings by positioning relative to gtm_plan, video_studio and image_studio. The core verb ('read the graph') is only implied by 'One read is meant to be enough', so it falls just short of a clean 5.

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

Usage Guidelines5/5

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

Explicit when-to-use with concrete trigger utterances ('what do we need for Japan', 'make videos for TikTok in Vietnam'), an explicit ordering rule (after gtm_plan, before video_studio and image_studio), and a fallback behavior (omit country to use the data's first market). It also states that job returns one job only, which tells the agent when to narrow the call.

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.