Skip to main content
Glama

Are my replies on track?

reply_pace
Read-onlyIdempotent

Weekly pace check for one market: pass the buyers emailed so far (each buyer once, first emails only), the buyers who replied (any reply, a no counts) and, if known, the week of the 13-week schedule and how many replies were interested (warm). Call it first in the weekly routine and act on it before anything else: relay risk_note first when present (sanctions or export controls on that market), then status_text, advice (or decision_text once the target is reached) and send_this_week as they are; find_buyers_type is this week's buyer type and email_draft the first email to use (first_email or a key of gtm_plan first_email_variants); changed lists the changes made so far, to pass back next week; they agree with each other and with the web plan, and each gives one change to make, not a choice. Returns: status (one of too_early, no_replies, below, change_now, decision_moves, behind_schedule, normal_range, few_interested, above, on_track, or the decision next_market, change_and_retry, keep_going; on_track only when the current rate reaches 10 replies at the target, sends are on schedule and the interested share is not low), status_text, advice, send_this_week (new buyers to add this week: the catch-up number when more than a week behind; at next_market the first 200 in send_this_week_in), the rate Korean exporters of this product usually get there (the same industry × market rate as gtm_plan reply_target, from 2.2M real export emails), the normal range for that many sends (Poisson 5–95%), projected_replies_at_target, alternative_buyer_type, behind_schedule (weeks 2–12), decision_moves (week 13 or later before the target: the week to decide), and from 95% of sends_for_10_replies the decision with decision_text (fewer than 5 replies → next_market, named only then; 5–9 → same market once more, the next buyer type with a new subject line for retry_batch.send more, then 10 or more in total keeps going and fewer moves on; 10 or more → keep going). Pass exclude with markets already tried. With warm it adds warm_share against the usual share; when low (from 5 replies, under half the usual share) the status or decision says to change the offer and warm_note explains. Called signed in (/mcp/account) for a market with a saved buyer list, it adds account_note (the list's size, list_unsent — how many on it are not emailed yet by the sent number passed, counted from the front of the list — and the buyer types whose map searches have all run) and points to my_progress, which plans the week with that list. 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.
sentYesBuyers emailed so far in this market (count each buyer once; follow-ups don't add).
warmNoOptional: of the replies, how many were interested (a question, a sample request or a meeting; not a no). Compared with the usual interested share of replies; from 5 replies a low share adds warm_note.
weekNoOptional: the week of the 13-week schedule they are in (1 = the week of the first 200 emails), to flag sends behind schedule or a decision that moves past week 13.
changedNoOptional: changes already made in earlier weeks, as last week's changed (comma-separated: next_type, new_subject, new_subject_2, offer, retry, retry_type). A change once made is kept: the same verdict again keeps it instead of flipping back, a retry uses a subject line not sent yet, and retry (a retry batch already started) keeps that subject line in the following weeks; retry_type (the retry switched to a buyer type not tried yet) keeps that type's email. my_progress does this from the saved log.
countryYesTarget country as ISO 3166-1 alpha-2 (e.g. 'US', 'JP') or an English/Korean name.
excludeNoOptional: markets already tried, comma-separated ISO codes or names (e.g. 'DE,PL'), skipped when naming the next market.
repliesYesBuyers who replied so far (any reply, including a no).
buyer_typeNoOptional: the buyer type the user sent to last week (last week's find_buyers_type); after a switch to the next type the check keeps it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

The annotations already declare read-only, idempotent, non-destructive, closed-world behavior, but the description adds real context beyond them: status meanings, decision thresholds at 10 replies, warm-share rules, statistical backing from 2.2M emails, and the account_note behavior when signed in. The disclosure is rich, though it is delivered in a dense and sometimes confusing run-on form.

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 sprawling paragraph with semicolon-chained clauses and nested return-value enumerations. It is front-loaded with the purpose, but the size and density make it hard for an agent to parse quickly, and many details duplicate the schema.

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

Completeness4/5

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

Because there is no output schema and the tool returns many status values and advice fields, the description must explain return semantics, and it does so thoroughly. It covers status thresholds, decision logic, warm-note behavior, and account-note additions, leaving little functionally missing even if the presentation is poor.

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%, so the schema already documents all nine parameters. The description adds some meaning, such as 'each buyer once, first emails only,' 'a no counts,' and how exclude is used, but much of this repeats the schema rather than extending it.

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 opening line states a specific computation for a specific resource: a weekly pace check for one market based on sent/replies. It distinguishes itself from nearby tools by naming find_buyers_type, email_draft, gtm_plan, and my_progress, though the surrounding sprawl makes the core purpose less crisp than it could be.

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?

It explicitly says to call this first in the weekly routine and act on it before anything else, and it points to my_progress as the alternative for a saved buyer list. It does not state exclusions or prerequisites in a clean when-not form, but the sequencing guidance is unusually explicit.

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