No mechanism on MCP and LangChain exceptions

[alexander-alderman-webb]

Errors captured by automatic instrumentation should have a mechanism so capture data is available, and the popularity of integrations can be determined.
See

sentry-python/sentry_sdk/integrations/mcp.py

Lines 425 to 430 in e275c9e

	except Exception as e:
	# Set error flag for tools
	if handler_type == "tool":
	span.set_data(SPANDATA.MCP_TOOL_RESULT_IS_ERROR, True)
	sentry_sdk.capture_exception(e)
	raise

and

sentry-python/sentry_sdk/integrations/langchain.py

Lines 222 to 231 in e275c9e

	def _handle_error(self, run_id: "UUID", error: "Any") -> None:
	with capture_internal_exceptions():
	if not run_id or run_id not in self.span_map:
	return
	span_data = self.span_map[run_id]
	span = span_data.span
	set_span_errored(span)
	sentry_sdk.capture_exception(error, span.scope)

[linear]

PY-2016

[gmassello]

Opened a draft PR for this: #7226

One correction worth flagging: the mechanism isn't missing, it's the default
{"type": "generic", "handled": True} from utils.py:692. The handled: True
half is arguably the bigger problem — all six MCP call sites re-raise, so these
errors do reach the user's code, but they don't count as unhandled and don't
affect the crash-free rate.

While extending the tests I also found that under fastmcp==4.0.0b2 +
mcp==2.0.0 a failing tool never reaches any of the six MCP capture sites
(measured with coverage: zero executed). fastmcp catches and logs it itself, and
the only event Sentry gets comes from LoggingIntegration, with
mechanism.type == "logging". That also means test_fastmcp_tool_with_error
isn't currently exercising MCP error capture on that env. I left it out of the
PR since it's a separate problem — happy to open an issue for it if useful.