OTEL_LOG_TOOL_CONTENT with MCP tool output: what Sume logs could leak
Claude Code 2.1.283 can put MCP tool output on an OTEL span when OTEL_LOG_TOOL_CONTENT=1. With Sume, check that output for signed URLs and keys first.

With Claude Code 2.1.283 and OTEL_LOG_TOOL_CONTENT=1, MCP tool outputs are recorded in the tool.output span event of your OpenTelemetry traces. If you connect Sume, that means whatever a Sume tool returns can land in your telemetry backend, so decide first what you are willing to store there.
What does the Claude Code change say?
The changelog entry for 2.1.283, dated Sep 25, lists MCP tool outputs in the OTEL tool.output span event with OTEL_LOG_TOOL_CONTENT=1. The changelog line is short. Check it for the release you run.
Which Sume outputs are sensitive?
Sume's docs list unsafe log content: API keys, signed URLs, raw private media URLs, and excessive user content or transcripts. The authentication page says to treat signed upload and download URLs as temporary secrets.
Hosted MCP includes assets_download_url and assets_upload_url among its tools, so a session that calls them can produce such URLs in a tool result.
| Kind | Sume's guidance |
|---|---|
| Request ids | Safe |
| Job ids when needed | Safe |
| High-level status | Safe |
| Sanitized media metadata | Safe |
| API keys | Unsafe |
| Signed URLs | Unsafe |
| Raw private media URLs | Unsafe |
What should the agent report instead?
The playbook for paid creates says to prefer Sume public ids and media.sume.com URLs in agent reports, and not to paste signed URLs, OAuth tokens or API keys into chat logs. The same habit keeps tool output cleaner in a trace.
What if a secret already reached the backend?
Sume's docs say to rotate API keys if they appear in logs or chat history. Signed URLs are temporary, but treat them as secrets until they expire, and limit who can read the trace store. Leave OTEL_LOG_TOOL_CONTENT unset unless you need tool content. If you do enable it, review who can query the collector and how long spans are retained, since a tool result is then stored beside the rest of your trace data.
Which outputs are worth keeping?
Job ids, request ids and status strings are the useful parts of a Sume trace, and Sume's docs list them as safe. A trace that carries jobs_status results is enough to explain what happened without storing any media URL.
If you do need content for debugging, capture it in a short-lived environment and switch it off afterward. That keeps the default trace free of anything on Sume's unsafe list.
Does this affect other Claude Code settings?
The same 2.1.283 entry lists a gateway hint header, x-claude-code-prompt-id, behind CLAUDE_CODE_GATEWAY_HINT_HEADERS=1. It is separate from tool content. Read the changelog entry before enabling either, and confirm what your collector stores.
Sources
Related posts
More in Developers
- Claude Code PreToolUse hook example: gate paid Sume tools
A PreToolUse hook that lets dry_run previews through, denies paid Sume MCP calls with no max_spend_usd, and asks you before the rest. Script and settings.
- Claude Code MCP server connected twice: duplicate connector fix
Claude Code 2.1.281 stopped connecting one MCP server twice when a plugin or connector spells its URL differently. What it means for Sume's single MCP URL.
- Claude Code subagent MCP server: scope Sume tools to one
Put a Sume MCP server in one subagent's mcpServers field so video and image tools stay out of the main chat. Frontmatter for both routes, plus limits.
- MCP URL mode elicitation in Claude Code vs OAuth consent
Claude Code 2.1.281 added MCP URL-mode elicitation, a browser flow a server can request. Sume's browser step is OAuth consent, a different mechanism.
Written by Sume