See how often any e-commerce brand sends marketing emails: counts, send dates and recent subject lines for 750+ brands, mostly in the Nordics and Germany. Read-only, no login.
Scored across 3 tools
Each tool has a distinct role: find_brands discovers/ranks brands, get_brand_email_frequency reports sends in a specific period, and get_brand_summary returns a profile of aggregates. The main overlap is that get_brand_summary also returns 'current frequency (average emails per week over 90 days)', which partially duplicates what get_brand_email_frequency reports, so an agent may occasionally hesitate between the two.
All three names are snake_case verb_noun constructions (find_brands, get_brand_email_frequency, get_brand_summary) that read predictably and map cleanly to their resources. The find vs. get variation is semantically justified (discovery vs. retrieval) rather than inconsistent.
Three tools is on the thin side but fits a narrow read-only analytics purpose: discover brands, inspect a period, inspect a profile. Nothing feels redundant, though the surface is small enough that one more capability (e.g. cross-brand comparison or market/category listing) would round it out.
For a read-only email-observation service, the three tools cover discovery, time-bounded send history, and profile aggregates, with clear documentation of what is deliberately out of scope (opens, clicks, revenue, creative). Gaps are minor: no direct brand-name lookup tool, no cross-brand or category-level aggregation, and per-send detail is capped at 31-day windows.
Ecommerce brands StackEnhance Signal tracks in one market, ranked by current email frequency (average marketing emails per week over the last 90 days), optionally within a category such as "Fashion & Apparel" or "Home & Interior". Use for questions like "Which brands email most frequently in Swedish ecommerce?" or to find a brand when the user names a kind of brand ("a Swedish fashion brand"). Rankings are available for SE, NO, DK, FI and DE. Brands with too little observed data are left out of rankings. Returns brand names, categories and emails per week only. Each brand has a details_url to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many brands to return (1-10, default 10). | |
| market | Yes | Country as a two-letter code (SE, NO, DK, FI or DE) or its name ("Sweden"). | |
| category | No | Optional category, e.g. "Fashion & Apparel", "Home & Interior", "Beauty & Cosmetics", "Sports & Outdoor". |
| Name | Required | Description |
|---|---|---|
| brands | Yes | |
| market | Yes | |
| category | Yes | |
| window_days | Yes | |
| brands_tracked | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world behavior, so the safety profile is covered. The description adds real behavioral context beyond that: brands with insufficient observed data are dropped from rankings, results are capped by limit, only brands/categories/emails-per-week are returned, and each brand carries a details_url for citation.
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-loads what the tool does and what it ranks by, then layers usage examples, coverage, exclusions and return shape. Dense but each sentence carries information; only the return-field sentence is partly redundant with the output schema.
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?
An output schema exists, yet the description still summarizes return contents and citation practice, plus ranking window, supported markets and data thresholds. Nothing needed to call the tool correctly is missing.
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 schema already documents limit, market and category, including the same country codes and category examples the description repeats. The description adds no syntax or format meaning beyond the schema, making the baseline 3 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 and resource (find ecommerce brands), the ranking metric (average marketing emails per week over 90 days), and the market scope. It is clearly distinguishable from siblings like get_brand_email_frequency and get_brand_summary, which return per-brand detail rather than a ranked list.
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 concrete usage contexts with example questions ("Which brands email most frequently in Swedish ecommerce?", finding a brand when the user names a kind of brand) and notes markets and data-sufficiency exclusions. It does not explicitly name the sibling tools or state when to prefer them, so routing guidance is contextual rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many marketing emails a brand sent in a calendar period, and when, as observed by StackEnhance Signal (ecommerce brands, mostly in Sweden, Norway, Denmark, Finland and Germany). Use for questions like "How many emails did Newport send in August 2026?", "What did Newport send last week?" or "What has X sent recently?". Without a market, a brand tracked in several countries gets one result per market. Resolve relative dates yourself to YYYY-MM-DD: "last week" is the previous Monday–Sunday, "last month" the previous calendar month, "recently" the last 14 days. Dates are the brand's local calendar dates and a period may span up to two years. Returns the count; for periods of up to 31 days also the date of each send; and at most two subject lines, only ones already shown on the brand's public StackEnhance page and sent in the period. Every listed send was captured in full; a send without a quoted subject is listed in sends_with_subject_in_signal because its subject is withheld by that limit, not missing. Counts are de-duplicated marketing sends (welcome, birthday and transactional emails excluded). There is no open, click or revenue data. Full campaigns, other subject lines, offers, products and creative analysis are not available through this tool. Cite each result's details_url as the source and as where the full campaigns are.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Last day of the period, inclusive, YYYY-MM-DD. | |
| from | Yes | First day of the period, YYYY-MM-DD. | |
| brand | Yes | Brand name as the user wrote it, e.g. "Newport" or "IKEA". A domain such as newport.se also works. | |
| market | No | Country of one storefront as a two-letter code (SE, NO, DK, FI, DE) or its name ("Sweden"). Omit it to get every market the brand is tracked in. |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| unavailable | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on substantial behavioral detail: de-duplicated counts with welcome/birthday/transactional excluded, a two-subject-line cap, the sends_with_subject_in_signal explanation for withheld subjects, local calendar dates, and a two-year period ceiling. This is exactly the kind of beyond-annotation context the dimension rewards.
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?
Purpose and scope are front-loaded, and the dense multi-clause sentences each carry distinct rules rather than filler. It runs long, and the illustrative example questions plus the repeat of return contents could be trimmed, but nothing is genuinely wasted.
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?
An output schema exists so return values need not be re-explained, yet the description still frames them usefully (count, per-send dates up to 31 days, subject-line limit) and covers periods, dedup rules, market fallback and geographies. 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 coverage is 100%, so the baseline is 3, but the description adds real semantics: it explains that omitting market yields one result per tracked market, and it spells out how to resolve relative dates into YYYY-MM-DD ("last week" = previous Monday–Sunday, "recently" = last 14 days). Those rules are not derivable from the schema patterns.
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 (how many marketing emails a brand sent, and when) plus the observing source and its geographic coverage. The scope is so precisely bounded that an agent can distinguish it from find_brands and get_brand_summary without opening either 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 concrete trigger phrasing ("How many emails did Newport send in August 2026?") and explicit when-not guidance (no open/click/revenue data, no full campaigns, other subject lines or creative analysis available through this tool). It routes the agent onward to details_url for the full campaigns, though it never names the sibling tools as alternatives, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A brand's email-marketing profile as observed by StackEnhance Signal: market, category, the date Signal first observed it, total marketing emails observed, current frequency (average emails per week over the last 90 days) and the date of the latest observed campaign. Use for questions like "How often does Newport email customers?" or "Is IKEA still sending newsletters?". Without a market, a brand tracked in several countries gets one summary per market. Returns aggregates only — no campaign list, subject lines, offers or creative analysis. Cite each result's details_url as the source.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand name as the user wrote it, e.g. "Newport" or "IKEA". A domain such as newport.se also works. | |
| market | No | Country of one storefront as a two-letter code (SE, NO, DK, FI, DE) or its name ("Sweden"). Omit it to get every market the brand is tracked in. |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| unavailable | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false). The description adds real context beyond them: the response is aggregate-only with no campaign-level content, multi-market calls fan out into one summary per market, and results should be cited via details_url.
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?
One dense paragraph, front-loaded with the resource and its contents, followed by usage examples, the multi-market caveat, the scope exclusion, and the citation instruction. Every sentence carries information, though the enumerated field list makes it longer than strictly necessary.
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?
An output schema exists, so return values need no further explanation, and the description still helpfully flags the aggregates-only nature and the details_url citation requirement. The only real omission is sibling differentiation against get_brand_email_frequency, whose overlap with this frequency-reporting tool is left for the agent to infer.
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 both parameters are already documented in the schema, including the two-letter-code/name format for market and domain-as-brand-name for brand. The description's note about omitting market and receiving one summary per market largely restates the schema field text, adding little beyond the baseline.
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 gives a specific resource ('a brand's email-marketing profile') and enumerates exactly which aggregates are returned: market, category, first-observed date, total emails, 90-day weekly frequency, and latest campaign date. It also states what the tool is not ('Returns aggregates only — no campaign list, subject lines, offers or creative analysis'), letting an agent separate it from a campaign-listing tool without opening a 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?
It supplies concrete trigger questions ('How often does Newport email customers?', 'Is IKEA still sending newsletters?') and explains the multi-market case ('Without a market, a brand tracked in several countries gets one summary per market'). It stops short of explicitly routing to the sibling get_brand_email_frequency, which appears closely related and is never named.
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.
find_brandsget_brand_email_frequencyget_brand_summary
Add one secure layer between your agents and this server.