CS: Give Admins Explicit Control Over Gainsight CS MCP Data Scope and Context

​I attempted to post this to the comments thread on this post, but I feel it warrants its own idea post.

After reviewing the June 2026 on-demand release notes for both MCP enhancements, I want to respectfully share some honest concerns because, based on what I’m reading, I think both designs seem to share the same structural problem.

THE CORE ISSUE

The release notes describe this directly:

"Existing reports now serve as a knowledge layer for Gainsight CS MCP" because "reports encode your organization's terminology."

There's an important distinction here: a knowledge layer describes what exists. A semantic layer — what's actually needed to ground an LLM — governs what data means, and who can see it. 

Reports provide the former. This design, however, assumes to provide the latter.
 

FEATURE 1: QUERY USING EXISTING REPORTS

What the docs appear confirm

• MCP searches reports you have access to, matching on names, descriptions, and filter logic
• Once a report is identified, MCP can dynamically: incorporate fields not in the report, add/modify/remove unlocked filters
• Only MDA-connection reports are included (SFDC and external connections excluded)
• Only reports run in the last 90 days qualify
• Reports without meaningful names or descriptions may not surface at all

Why this creates a potential governance risk

• The report isn't a boundary — it's a discovery hint. Because MCP can add fields and strip unlocked filters at query time, a deliberately narrow report becomes an unscoped query template. Locked filters are honored (a real control worth acknowledging), but locked/unlocked filter status was designed for usability, not as a security perimeter. Few orgs have audited this with "an LLM can remove unlocked filters" in mind.
• Data and metadata hygiene becomes a functional dependency. Report naming, descriptions, field selections and filter quality now directly determine AI accuracy. In environments with reporting sprawl — inconsistent naming, legacy artifacts, overlapping definitions or (heaven forbid) self-service reporting access — the matching surface becomes both unpredictable and high-maintenance.
• The 90-day heuristic is a poor proxy for curation quality. Frequently run doesn't mean accurate.  QBR and annual planning reports — often the most carefully curated assets — can fall out of scope. What counts as a "run" is also undefined in the docs (dashboard render? scheduled export? any user?), making the effective discovery surface hard to predict.
• Cross-team report access is additive, not clarifying. Different teams may hold reports built with different filter logic, field selections, and naming conventions. MCP matching across that surface doesn't neutralize those differences — it inherits them.

FEATURE 2: QUERY YOUR PORTFOLIO DATA

What the docs appear to confirm

• Portfolio scope is determined exclusively from Gainsight Home filters
• No other Gainsight surface or configuration is read
• At least one Home filter must be configured — or the feature doesn't work

Why this creates a potential governance risk

• Filter state is invisible in the query interface. Results change silently when Home filters change, with no documented indication to the user that a filter is shaping the response
• False negatives are a design outcome, not a bug. Relevant accounts outside the current filter simply don't appear.
• Not every team uses Gainsight Home. For those that don't, the feature is inert.
• A UI personalization preference is not a book-of-business definition. Using Home filter state as the ownership model is a fragile abstraction for anything downstream that matters.

BOTH FEATURES CAN FAIL IN OPPOSITE WAYS — FOR THE SAME REASON

In both cases, admins have no surface to adjust the behavior to their environment.

ADDITIONAL POTENTIAL GAPS WORTH FLAGGING

• Derived field behavior under dynamic modification is undocumented. In-report formula fields exist only at render time. What happens when MCP modifies the report's logic first is unclear. Data Designer outputs that overlap with base fields have no documented precedence model.
• Associated record resolution is an open question. Associated Record WHOID/WHATID lookup relationships aren't consistently resolved even across core Gainsight features today. How MCP would handle this when those objects become relevant is undefined. 
• Absence of inclusion on a Gainsight report is not evidence of unimportance.

It's often evidence of the opposite — the analysis mattered enough to do properly (or with broader visibility) which meant doing it outside Gainsight. GS data is exported and surfaced in a BI tool because Gainsight's reporting layer couldn't handle the logic required. Those are often the highest-stakes analyses: compliance rates, portfolio-level KPIs, multi-source metrics. No Gainsight report exists precisely because the answer required something more capable. The MCP's discovery model inverts this. It treats a Gainsight report as the signal of relevance. So the analyses your org trusts most — the ones sophisticated enough to require a BI tool — are systematically invisible to it, while simpler, natively-built reports qualify.

• No audit trail. Neither the release notes nor the admin guide indicates who to know which report was matched, or what filter/field modifications MCP applied to produce a given answer.
• The tool surfaces changes outside admin change management. This release alone requires users to disconnect/reconnect (Claude) or an admin app refresh (ChatGPT). MCP capabilities shift between releases, outside any change process the admin controls.

And these are just the things that came to mind for me. 

WHAT'S ACTUALLY NEEDED

The release notes describe, at a high level, what each feature does — reports are matched on names, descriptions, and filter logic; locked filters are honored; only MDA-sourced reports run in the last 90 days qualify. However, it falls short on important details like how matches are ranked when multiple reports qualify, what counts as a "run," and how filter modification decisions are made at query time.

Admins are being asked to govern a surface they can observe but neither directly affect nor predict.

What's needed is a purpose-built MCP configuration layer where admins can:

→ Explicitly define which objects and fields are exposed

→ Attach business meaning to fields — definitions, context, caveats

→ Designate authoritative sources (Data Designer or otherwise) rather than inheriting whatever reports

exist

→ Declare ownership logic directly, rather than inheriting Home filter state

→ Decouple AI context from UI state and report library condition entirely

The MCP Server has real potential; however until admins can explicitly define context and tune it to our own unique business requirements — rather than inherit it from artifacts that require  that business context to understand and interpret — the orgs with the most mature and customized environments are the ones who will trust it the least.

​