CS AI Tools Management: Extend "Quick Insights" functionality to Copilot/MCP Server

Report access through the Gainsight CS MCP server is all-or-nothing today. In Administration > AI Settings > AI Tool Management, report_search_tool and fetch_report_data can only be toggled Active or Inactive.

The admin has no say in which reports are eligible. I’ve currently got both report tools disabled in my tenant. That’s not a preference — it’s the only option when you can’t scope them. And it costs users real capability, because the MCP tool instructions tell the model to prefer saved reports over dedicated tools, on the reasoning that reports encode the customer’s own business definitions. That’s a lot of trust to place in a library the admin can’t curate.

As noted in this post, there are a number of reasons why broad report access could be problematic. Admins need a way to designate which reports are eligible for consideration by Copilot and the MCP Server

A marker already exists

“Mark as Quick Insight” was built to designate which reports are fit for consumption through an AI surface. That is exactly the control we need.

Today it only applies to Sally in Slack. Sally within Gainsight CS was retired in November 2025. Sally in Slack remains supported, but Gainsight AI Agent in Slack and Copilot are plainly where the product is heading.

So Quick Insight is a working flag attached to a legacy surface. Rather than let it age out, repurpose it. 

Per-report gating already exists here — the report tools branch on a user_accessible flag today. This is a second flag on an existing gate, not new architecture.

What I’m asking for

1. Redefine Quick Insight as a general marker meaning “this report is approved for AI surfaces.”  Honor it across Copilot, Gainsight AI Agent in Slack, and Gainsight CS MCP — not just Sally.
2. Add a toggle in Tool Management: “Restrict report tools to Quick Insight reports only.” allowing admins to choose whether or not to leverage this restriction
3. When on, non-approved reports are excluded from both report metadata search and report fetch.
4. When off, behavior is unchanged.
5. Default the toggle off, so nothing changes for existing tenants on release.

That gives admins a curated allowlist. We approve the reports that are accurate, stable, and safe. Everything else is invisible to the LLM — without touching report sharing and without disabling report tooling entirely.

The restriction has to cover metadata, not just fetch

Today’s user_accessible gate in the MCP server report tools stops a report from being run, not from being read. When a report is flagged inaccessible, the model appears to be instructed that its structure “still encodes genuine tenant conventions” — the objects it queries, the lookup chains it traverses, the filter logic it applies, the GSIDs it has resolved — and told to carry those forward.

Row data stays permission-bound. Structural knowledge doesn’t. A toggle that only gates fetch would leave unapproved reports still shaping answers.

Benefits

• Improved Accuracy - MCP picks reports by matching your question against report names and descriptions. With hundreds of reports, several will look like plausible matches. A curated set means it’s choosing from reports you’ve vouched for.
• Consistency - Today the report pool varies by user. Same question, different people, different answers. A shared approved set narrows that.
• Less prompt effort - Gainsight’s guidance is to spell out your business logic in the prompt. Good reports already encode that logic in their filters, so users write less to get the same result.
• Predictability - “It draws on this set of reports” is something users can understand and admins can explain. “It searches your entire report library” is not.
• Trust - This is the one that compounds. Users decide early whether the assistant is reliable. Curated sources make the early answers better, which is when it matters most.
• Better Admin QOL - Today when someone reports faulty results, you don’t know which of the hundreds of reports produced it. You have to reconstruct what the LLM probably matched on before you can even tell whether it’s a bug, a stale report, or the user misreading the answer. With a curated set, the suspect list is small and you own every report on it. Triage goes from “investigate the library” to “check these reports.”  It also cuts ticket volume at the source, since most of those tickets come from the LLM picking a report nobody maintains.

Dependency: make the “Mark as Quick Insight” flag usable at scale

Today a report can only be marked as Quick Insight by opening the individual report itself, which makes curating an allowlist impractical when governing hundreds of reports.

Please add Mark as Quick Insight to the row-level settings menu in the report list view. That menu already has Edit Report, Rename Report, Delete Report, Manage Permissions and Enable Add Record. The flag belongs beside them.

Bulk select would be better still. The row menu alone makes this workable.

One behavior to revisit

Marking a report as Quick Insight currently exposes it to all Sally users. If the flag becomes a general AI-surface marker, that blanket exposure should be reconsidered — ideally the flag governs eligibility, with each user’s existing report permissions still applying on top.