HG Intent

Use intent as a "why now" trigger, never as a fact about what an account owns or will buy.

When to use

• A workflow needs a fresh signal that something is happening at a known account.
• A prompt is generating outreach openings and needs the "why now".
• An author is tempted to lead with intent. Read the "trigger, don't ground" rule first.

Tools you'll touch

• list_intent_topics: resolve a topic keyword to its hex id. Cost: free.
• company_intent: intent topics and TrustRadius activity for one company. Cost: 0.1 credits per call. Cached 30 days org-wide; there is no way to force a refresh inside the window.
• search_companies (intent.topics.ids, intent.signal_score): find which companies show intent on a topic. Cost: 1 per 100 companies returned.

Resolve topics first

Intent without resolved topics is almost never usable.

1. Call list_intent_topics with one short lowercase keyword (name:"observability", not "cloud observability platforms"). It is a literal substring match; a phrase returns nothing. It returns 10 rows by default, so pass limit (for example 25).
2. Pick the matching data[].id values. Never guess an id: a bad id matches nothing and looks like "no intent".
3. Pass them as topic_ids to company_intent.

The call shape

{
  "company_domain": "acme.com",
  "fields": ["topics"],
  "granularity": "global",
  "topic_ids": ["<id from list_intent_topics>"],
  "signal_level": ["HIGH", "MEDIUM"],
  "signal_date": { "from": "2026-07-01" },
  "limit": 50
}

Parameter	Rule
fields	Default is summary only. Pass ["topics"] for HG topics, ["activities"] for TrustRadius activity, or both.
granularity	Pass "global" (one row per topic). Accepted only when "topics" is in fields; never send it with summary or activities alone. The default is one row per state.
topic_ids	From list_intent_topics only.
vendor_ids, product_ids	Server-side filters across topics and activities. Resolve via get_vendor_information or company_technographic.
context_type_names	Server-side, topics only. Valid values: Displacement, Whitespace, Expansion, Complementary. Anything else fails.
signal_level	HIGH (score 85 to 100), MEDIUM (65 to 84), LOW. Topics only.
buyers_journey_names	Researching or Evaluating, the only two stages. Topics only.
signal_date	No default window. Pass from (and to if needed) whenever recency matters.
limit / offset	Count rows per section (1 to 200, default 50).
Selector	company_domain or hg_id. Pass hg_id only when it came from a prior result.

What comes back

• summary (HG and TrustRadius combined): active_topics_count, high_signal_topics_count, latest_signal_date, sources, top_context_types.
• topics (HG only): per topic name, score (0 to 100), signal_level, trend, last_seen_at, buyers_journey_names, context_type_names, vendor_names, product_names.
• activities (TrustRadius only): activity_label, activity_date, daily_views, products, vendors, intent_signal_url. No score, level or stage.
• data_available:false with no_data_reason is a definitive "no coverage" answer. Report it; don't retry.

Reading the signal

Saturation. Large companies carry thousands of HIGH topics tied at score 100, and the order among ties changes between calls. "Top N topics" without a topic filter is noise. Filter by resolved topic_ids, then read score and recency.

No topics. Smaller companies often have no intent topics at all. That means no coverage, not no interest.

Buyer journey. buyers_journey_names is an array and usually holds both Researching and Evaluating, so the stage rarely separates accounts. Use it as a modifier, not a gate. "Evaluating" means pricing, comparison or review-page activity, never a trial.

Trend (provisional; the unit is unconfirmed and observed values sit around -3 to +7):

Trend	Reading
≥ +2	Strong rise
+1 to +2	Weak rise
-1 to +1	Flat
-2 to -1	Weak decay
≤ -2	Strong decay

Recency. Read last_seen_at per topic and summary.latest_signal_date. A score-100 topic last seen months ago is stale.

The "trigger, don't ground" rule

Intent is a temporal signal ("something is happening"), not a factual one ("this is what they have").

1. Leading prose with intent. "Acme is evaluating BI alternatives" claims more than the data shows. You don't know the current stack or budget. Pair intent with company_technographic and company_spend.
2. Replacing technographic with intent. "They're researching a data warehouse" can land at a company already running one at scale. Check installs first.
3. Displacement needs an install. context_type_names:["Displacement"] plus vendor_ids scopes the signal to a competitor, but only a confirmed install in company_technographic makes it a displacement story.

Canonical pattern: intent triggers the play, technographic and spend ground the open, FAI names the buyer. See hg-tool-chain-account-research.

Citation rules

Cite score and date every time: "HG intent: data observability (score 92, HIGH, last seen 2026-09-26)". For TrustRadius activity, cite the label and date: "TrustRadius: comparison-page activity, 2026-09-30". Stale intent is the most common offender in workflow output.

Common pitfalls

1. Reading score as a forecast. Score 100 means heavy research activity, not a purchase.
2. Omitting fields. You get the summary only and conclude there are no topics.
3. Sending granularity without "topics". The call fails; the fix is to drop granularity, not to change the domain.
4. Assuming a 30-day window. There is no default; pass signal_date.from.
5. Quoting a topic name as a vendor. A vendor-named topic includes alternative research. Read context_type_names.

Reference

• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-intent
• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/list-intent-topics
• Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
• Related skills: hg-mcp-calling-rules, intent-data-calibration, hg-technographic, hg-tool-chain-account-research, hg-recent-signals