Gemini CLI connects to MCP servers through the same settings.json mechanism used for every other tool integration, and Gemini's long context window (1M tokens on the 1.5/2.x Pro line) is a genuine advantage for this specific module: you can pull a much larger slice of ticket and deal history into one session before needing to paginate manually. This topic covers setup, then two workflows — trend aggregation and revenue-weighted ranking — that lean on that context headroom.
Installing and Connecting HubSpot MCP to Gemini CLI
Gemini CLI reads MCP definitions from .gemini/settings.json (project-level) or ~/.gemini/settings.json (user-level). Add the HubSpot server under mcpServers:
{
"mcpServers": {
"hubspot": {
"command": "npx",
"args": ["-y", "@hubspot/mcp-server"],
"env": {
"HUBSPOT_ACCESS_TOKEN": "$HUBSPOT_ACCESS_TOKEN"
},
"timeout": 30000
}
}
}
The timeout field matters more here than with other clients — Gemini CLI's default MCP tool-call timeout can be tight for hubspot-search-objects calls against large ticket volumes with association expansion, and a timeout mid-call surfaces as a generic tool error that's easy to misdiagnose as an auth problem. 30 seconds is a reasonable floor for CRM workloads; raise it further if you're regularly running association-heavy queries.
Export the token before launching:
export HUBSPOT_ACCESS_TOKEN="pat-na1-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
gemini
Inside the CLI, run /mcp to list connected servers and their tools — Gemini CLI's /mcp output includes a description string per tool pulled from the server's own tool metadata, which is a fast way to double check you're looking at the official HubSpot server and not a stale or forked package if you ever install from a non-npm source.
/mcp
Connected MCP servers:
hubspot (8 tools)
- hubspot-list-objects: List CRM objects of a given type...
- hubspot-search-objects: Search CRM objects with filters...
- hubspot-batch-read-objects: Read multiple objects by ID...
- hubspot-list-associations: List associations between objects...
- ...
If hubspot doesn't appear at all, check that .gemini/settings.json is valid JSON — Gemini CLI, like most of these clients, fails to load a malformed MCP block without always surfacing a clear parse error in the default log level; run with gemini --debug to see the raw startup errors if the server silently doesn't appear.
Tips
- Raise the MCPtimeoutfor the HubSpot server specifically — default timeouts tuned for lightweight tools are often too tight for association-heavy CRM search calls.
- Use/mcpat the start of every new session to confirm which HubSpot tools are live — don't assume a config that worked yesterday is still connected today, especially after anpxcache eviction changes which server version loads.
- Rungemini --debugif a configured server doesn't appear in/mcp— it's the fastest way to see JSON parse errors or process-spawn failures that the default output swallows.
Aggregating Deal and Ticket Data for Trend Analysis in Gemini CLI
Gemini's context headroom changes the shape of a good prompt: instead of narrowly filtering to avoid blowing the context window, you can pull a genuinely wide slice of data and ask for trend analysis across it in one pass.
> Search all deals closed (won or lost) in the last 12 months.
Properties: dealname, amount, dealstage, closedate, hs_analytics_source.
Paginate through all results using the `after` cursor until total is
exhausted. Then break down: win rate by month, average deal size by
month, and win rate by hs_analytics_source.
With a 1M-token context window, pulling several thousand deal records with five properties each is realistic in a single session without needing to summarize-and-discard intermediate pages the way you would with a smaller-context client. That said, "realistic" doesn't mean "free" — every deal record still costs tokens, and a genuinely large HubSpot instance (50,000+ deals) will still need chunked processing even here. Ask the agent to report progress explicitly so you can tell whether it's actually completing full pagination or stopping early to save its own context:
> After each page of 100, report: page number, cumulative record count,
cumulative token estimate. Stop and ask me before continuing past
page 20 (2000 records).
For ticket trend analysis specifically, the most useful aggregation is usually priority-over-time, since it's a direct proxy for support load trending up or down by product area:
> Search tickets created in the last 6 months. Properties: subject,
hs_ticket_priority, product_area, createdate. Group by month and
product_area, count by priority level. Render as a markdown table:
rows = month, columns = product_area, cell = count of HIGH+URGENT
tickets that month.
This produces a genuinely useful early-warning table — a product area with a rising HIGH/URGENT count month over month is a stronger prioritization signal than any single week's ticket volume, and it's the kind of cross-tabulation that's tedious to build in HubSpot's native reporting without a custom dashboard.
Tips
- Ask for explicit pagination progress reporting on large pulls — a large context window makes it easy to assume completeness without verifying it, which is the opposite failure mode from a small-context client that visibly truncates.
- Cross-tabulations (month × product area, stage × source) are where Gemini CLI's context headroom earns its keep — these need the full dataset in context at once to compute correctly, not a page-by-page running summary.
- Set an explicit stop-and-confirm checkpoint on very large pagination loops — "ask me before continuing past N records" avoids runaway API usage against HubSpot's rate limits, even with generous context on the client side.
Practical Example: Ranking Feature Requests by Revenue Impact
This is the workflow that most directly serves the "customer-driven requirements" framing of this module: take unstructured feature mentions scattered across deals and tickets, and rank them by actual dollars at stake, not by how loudly the most recent customer complained.
> Step 1: Search closed-lost deals from the last 4 quarters with
amount > 10000. Properties: dealname, amount, closedate,
closed_lost_reason. Pull associated notes for each.
Step 2: Search open tickets tagged with any product_area value,
properties: subject, content, product_area. Pull associated deal
for each ticket where one exists, with its amount property.
Step 3: From both sources, extract every distinct feature request
or missing-capability mention. For each distinct feature, sum: lost
ACV from closed-lost deals mentioning it, plus at-risk ACV from open
deals whose ticket mentions it. Rank descending by total dollar
figure. Output a table: feature | lost ACV | at-risk ACV | total |
mention count | example quote.
A realistic output:
| Feature | Lost ACV | At-Risk ACV | Total | Mentions | Example Quote |
|---------------------------|---------:|------------:|---------:|---------:|---------------|
| SSO / SAML | $340,000 | $210,000 | $550,000 | 11 | "security team blocked procurement without SAML" |
| Bulk CSV export | $190,000 | $95,000 | $285,000 | 9 | "export times out above 50K rows" |
| Custom role permissions | $80,000 | $140,000 | $220,000 | 6 | "need field-level access control for finance team" |
This is a materially better prioritization input than a feature-request count alone, because it's weighted by what's actually at stake financially — a feature with 3 mentions worth $400K should usually outrank one with 15 mentions worth $60K, and a raw ticket tally hides that completely. Be honest with stakeholders about the method, though: this is directional, not audited-grade revenue attribution. closed_lost_reason is free text a rep chose to fill in (or didn't), and correlation between "customer mentioned X" and "customer left because of X" isn't causation — a deal can mention five things and lose for a sixth, unstated reason.
Tips
- Present revenue-ranked feature tables with the caveat that they're directional signal from CRM text, not verified causal attribution — a rep's free-text reason field is not a controlled experiment.
- Keep lost and at-risk ACV as separate columns, not blended into one number — a stakeholder needs to know how much is "already gone" versus "still recoverable," and blending them loses that distinction.
- Sanity-check the top 2-3 ranked features by reading a handful of the underlying source quotes yourself — an LLM summarizing dozens of notes can occasionally conflate two related-but-distinct complaints into one feature bucket.
Comparing HubSpot MCP Output Between Gemini CLI and Claude Code
Running the same query through both clients on the same HubSpot portal is a useful calibration exercise before you standardize on one for a team workflow. Differences worth knowing about:
Tool-call transparency. Claude Code's default UI collapses tool calls into a compact approval card; Gemini CLI's default output tends to show more of the raw JSON response inline unless you're in a quieter output mode. For learning the API shape, Gemini CLI's default verbosity is closer to OpenCode's than to Claude Code's.
Pagination discipline. In side-by-side testing on identical prompts, Gemini CLI's larger context window makes it more likely to attempt full pagination without being asked, while Claude Code more often stops at the first page and reports a partial count unless the prompt explicitly asks for exhaustive pagination. Neither behavior is "correct" by default — both need the explicit instruction from the earlier sections if completeness actually matters for the analysis.
Handling of ambiguous property names. When a HubSpot property doesn't exist under the guessed name (e.g., asking for deal_owner when the actual property is hubspot_owner_id), both clients recover by calling a schema/properties tool, but Claude Code's tool-call sequence tends to surface the correction more visibly in the transcript, which makes it easier to catch a wrong assumption before it propagates into a summary.
Cost and latency trade-off. Gemini's larger context window changes the calculus toward fewer, bigger queries; Claude Code and Cursor's more constrained defaults push toward more, smaller queries with intermediate summarization. Neither is strictly better — a wide pull with Gemini CLI risks a slow single request against HubSpot's rate limits, while a chunked approach risks losing cross-record correlation that only shows up when everything's in context at once.
For this module's use case — CRM research feeding product decisions — the practical recommendation is: use Gemini CLI for the wide aggregation pass (the revenue-ranking table above, the month-over-month trend table), then switch to Claude Code or Cursor for the narrower, code-adjacent step of turning a validated finding into a linked backlog item, where tighter tool-call visibility and IDE integration matter more than raw context headroom.
Tips
- Don't standardize on one client for every HubSpot MCP task — match the client's strength (Gemini's context width for aggregation, Claude Code's tool-call transparency for precision editing) to the specific step in your workflow.
- When a finding matters enough to act on, reproduce it in a second client before committing to it — a discrepancy between Gemini CLI's and Claude Code's output on the same prompt is a fast, cheap way to catch a hallucinated aggregation.
- Log which client and which prompt produced a number you're putting in a roadmap doc — "Gemini CLI, full pagination, 2026-08-21" is a reproducibility trail that costs one sentence and saves an argument later.
Tips
Tips
- Raise the default MCP tool timeout for HubSpot specifically in.gemini/settings.json— CRM search calls with association expansion routinely run longer than lightweight tool calls the default timeout was tuned for.
- Lean on Gemini CLI's context width for genuinely wide aggregations (full-year trend tables, cross-tabulations) rather than for tasks that don't need the full dataset in view at once.
- Cross-validate any revenue-ranked or trend-based finding in a second client before it lands in a planning document — the cost of a second query is trivial next to the cost of a wrong prioritization call.