get_ai_conversation_details drops user.email from transcript; search_events omits user identity from default error fields

[sentry-junior]

Problem

When using the MCP to debug AI agent runs (e.g. Seer), you can't tie failures back to specific users or prompts. Josh Ferge ran into this directly: "Sentry MCP dropped user_email / user_message from results, so I couldn't tie specific failures to user prompts."

There are two independent bugs causing this, both traceable to specific lines of code.

---

Bug 1: get_ai_conversation_details collects user.email but never renders it

Root cause

extractTurns() correctly reads user.email from each span and stores it in ConversationMessage.userEmail:

// get-ai-conversation-details.ts ~line 261
user: userContent
  ? {
      role: "user",
      content: userContent,
      timestamp: span["precise.start_ts"],
      spanId: span.span_id,
      userEmail: span["user.email"],  // ← collected ✓
    }
  : undefined,

But formatTurn() never renders it:

// get-ai-conversation-details.ts ~lines 349-352
turn.user ? "**User**" : null,
turn.user ? "" : null,
turn.user ? truncate(turn.user.content) : null,  // content only
turn.user ? "" : null,
// userEmail is silently dropped ✗

The email IS present in the raw artifact JSON blob appended at the end of the response — but that's buried in a ~1200-char code block agents have to parse to find a single field. The transcript, which is what agents actually read turn-by-turn, has no user identity.

Impact

An agent debugging Seer runs can see the full conversation transcript but has no way to answer "which user triggered this run?" without separately parsing the JSON artifact blob at the bottom.

Fix

One-line change in formatTurn():

turn.user ? `**User**${turn.user.userEmail ? ` (${turn.user.userEmail})` : ""}` : null,

Plus snapshot test update.

---

Bug 2: search_events default error fields don't include user identity

Root cause

The recommended field set for error queries (RECOMMENDED_FIELDS.errors.basic in search-events/config.ts) is:

errors: {
  basic: ["issue", "title", "project", "timestamp", "level", "message", "error.type", "culprit"],
}

No user fields. The search sub-agent's default error query returns events with zero user identity context.

user.email and user.id ARE in BASE_COMMON_FIELDS (surfaced to the sub-agent via datasetAttributes), so the agent can request them if the user explicitly asks. But recommended fields are the fallback default — and they omit user identity entirely.

Net result: "show me recent Seer errors" returns a list of failures with no indication of who triggered them.

Fix

Add user fields to the recommended set:

errors: {
  basic: [
    "issue", "title", "project", "timestamp", "level",
    "message", "error.type", "culprit",
    "user.email",  // add
    "user.id",     // add
  ],
}

---

What's Out of Scope Here

The deeper gap is that Seer Celery task error events may not carry user context at all. If the Seer task doesn't attach user.email and the original prompt to the Sentry error event when it crashes or gets SIGKILL'd, no MCP fix can recover that data. That's a Seer instrumentation gap in getsentry/sentry: the Seer task execution scope should set Sentry user context and include the originating user message as a tag/extra, so error events carry it.

The two fixes above address what the MCP can control: surfacing data that is present in spans, and requesting it by default.

---

Acceptance Criteria

• get_ai_conversation_details transcript shows user.email inline on the User line (e.g. **User** (alice@acme.com)) when the field is set on the span
• RECOMMENDED_FIELDS.errors.basic includes user.email and user.id
• Snapshot tests updated
• Manual test: querying errors returns user email without needing to specify the field explicitly

---

References

• Discussion: https://sentry.slack.com/archives/C089L9UUJDV/p1779997855795739
• Josh Ferge's Seer debug run: https://sentry.slack.com/archives/C091QF41ULT/p1778159743300829
• Related (prompt injection warnings): Tool results contain assistant-facing instructions that trigger prompt-injection warnings in MCP clients #1019

---

View Session in Sentry

[linear-code]

MCP-968

[github-actions]

Triage bot here.

I confirmed this maps to the current code:

• get_ai_conversation_details stores userEmail from user.email, but the transcript renders a plain **User** heading.
• search_events has user.email/user.id in common fields, but not in the default error field set.

I also tried the focused test files, but this checkout failed before test execution because @sentry/mcp-server-mocks could not be resolved. This is actionable for maintainer review.