MCP: how to record params and result

[lmolkova]

Extracted from open-telemetry/semantic-conventions#2083 (comment). Need to decide how to record them

• we record some of the params as dedicated attributes, e.g. mcp.resource.uri - should we record all of them as such?
• we can record params one-by-one assuming they are orthogonal (e.g. mcp.input.param.location = Seattle, WA) or as a single complex attribute. It really depends on the usage pattern and whether people want to query by individual params
  • params._meta contain some things like progress report token that might not be interesting on telemetry
  • users might want to record some params/result but not all of it, instrumentations might support it via config in both cases (single params/result attribute vs multiple)

[Necmttn]

For MCP params/results, I would separate queryable metadata from captured content.

Dedicated attributes should cover protocol fields people actually filter on: tool/resource name, URI, schema hash, result status, and maybe selected typed params. Then add an opt-in redacted param/result bag plus a content reference for large or sensitive payloads.

The capture config should be visible on the span: captured keys, omitted keys count, redaction policy, and size/truncation state. That makes absence distinguishable from "captured then removed."

---

Generated with ax.