[Feature Request]: Allow rendering tool_use and tool_result inputs and outputs (incl. MCP) via a cli toggle

[petems]

Feature request: render tool_use inputs and tool_result outputs (incl. MCP) in markdown output

Summary

Currently cclog renders only type: "text" blocks from the JSONL content array. tool_use and tool_result blocks are reduced to terse placeholders (e.g. *[Tool used: Bash (no output)]*, *[Tool operation completed (no output)]*), and even those only appear when there is no accompanying text and --include-all is set. The actual tool input parameters and tool result bodies are dropped on the floor in internal/formatter/markdown.go (around lines 197-210 and 230-240).

This also means MCP server calls are entirely invisible in the rendered markdown, since they flow through the same tool_use / tool_result path.

Use case

It'd be ideal if I could use cclog to produce markdown-formatted versions of Claude Code sessions for:

• Debugging: Figuring out what a session did, which usually means looking at the tool calls (bash commands, file edits, MCP responses), rather than the prompting and responses
• Referencing in project-tracking platforms: Pasting session excerpts into Jira tickets, Confluence pages, GitHub issues, design docs, etc, as a record of what was tried, what an agent ran, and what came back.

Proposed behaviour

An opt-in flag (e.g. --include-tools or extending --include-all) that renders:

• tool_use blocks as a labelled fenced block with the tool name and input JSON.
• tool_result blocks (and/or the top-level toolUseResult metadata) as a fenced block with the result content.
• MCP tool calls handled the same way, ideally with the MCP server name surfaced if available.

So it'd look something like this in the output when in markdown format:

**Tool call: `Bash`**

```json
{"command": "ls -la", "description": "List files"}
```

**Tool result:**

```
total 24
drwxr-xr-x  5 user  staff   160 ...
```

Question for maintainers: Was this intentional?

Looking through the repo I couldn't find an explicit design note saying "we deliberately don't render tool I/O." The closest signal is commit 4b66e0f ("enhance --include-all with informative placeholders for empty content"), which deliberately chose summary placeholders over actual tool content, but it's framed in terms of producing "clean" markdown / reducing noise.

Risks

The reason I ask about the intent is, there there's a few risks I forsee with this feature:

• Secret Leakage: tool_result bodies routinely contain things like aws sts get-caller-identity output, environment variables, .env file contents read via the Read tool, API tokens echoed by curl/HTTP MCP servers, database rows, etc. A user pasting "the markdown of my session" into a Jira ticket could trivially leak credentials they never realised were in the transcript.
• MCP output is especially risky: Third-party MCP servers may return arbitrary content (Slack messages, Jira tickets, internal docs, customer data etc) that the user wouldn't expect to end up in a markdown export. Maybe we do seperate flags for MCP's vs regular tools, is that possible?
• Size: Some tool results (large file reads, long command outputs) would balloon the markdown dramatically.

Questions

1. Was excluding tool/MCP content from the rendered markdown an intentional design choice? If it was, was it specifically around improving the quality of the outputs and reduce noise?
2. If a PR added this behind an opt-in flag, would you be interested? Specifically: a flag that's off by default (so the current "safe to share" output is preserved), with clear documentation that enabling it may expose secrets and large blobs.
3. Any appetite for built-in redaction heuristics (e.g. masking obvious AWS/GitHub/Anthropic token patterns) when the flag is on, or would you prefer to keep that out of scope and leave redaction to the user?

Happy to put up a PR once there's directional agreement on (1)-(3), or gracefully back away if that's too much of a change for your vision for the project going forward 🫡