Clarify audit fields for runtime MCP dynamic tool discovery

[caioribeiroclw-pixel]

The new dynamic discovery page says MCP plugin tools can change at runtime, that the platform diffs current tool definitions against the last known set, validates newly discovered/modified tools with runtime RAI/XPIA checks, and records interactions in Purview under the Copilot workload.

One thing that would help tenant admins and MCP server developers is a clearer audit boundary for the discovery step itself:

• does the Purview record include which MCP tool definitions were newly discovered, changed, removed, or blocked during that session?
• is there any low-cardinality field for the runtime validation outcome/reason, e.g. accepted, blocked_by_rai, blocked_by_xpia, schema_invalid, entitlement_filtered?
• if full tool schemas are intentionally not logged, is there a supported way to audit a hash/version/diff summary of the activated tool surface?
• can admins correlate the TargetAgentName event with the MCP server/tool catalog version that was active for that turn/session?

I would not expect raw schemas, prompts, args, or results to be logged. The useful doc clarification is whether admins can prove the runtime discovery boundary: what changed, what was activated, what was withheld/blocked, and why, without leaking sensitive tool details.

This matters more with dynamic discovery than static manifests because the tool surface is no longer fixed at publish time.