feat: compact large write-tool payloads in tool-call logs

[maehwasoo]

Problem statement

When capture_note and other write tools receive large inline content fields such as body, chat clients can render the full request payload in the tool-call log.

In practice this makes sessions noisy because the entire note content appears in the conversation, and the effect is duplicated when a workflow does a dry-run first and then repeats the same call with apply=true.

The main pain point is log readability in the chat session, not the write behavior itself.

Proposed solution

Add a first-pass way to reduce oversized write-tool payload exposure in tool-call logs while keeping the actual tool behavior unchanged.

A good initial direction would be one of these:

• Keep the existing tool signature, but expose a compact representation for large string fields in client-visible logs when the client/server integration allows it.
• If log-layer compaction is not possible for a given client, add an alternative write-tool input flow that avoids sending the full content inline for repeated large writes.

The initial implementation goal should be:

• preserve current capture_note / write-tool semantics
• preserve apply=false and apply=true behavior
• reduce chat-session noise for large note bodies
• keep enough metadata visible for debugging, such as field name, truncated preview, size, and whether truncation happened

Constraints / context (optional)

• This request is about reducing client-visible log noise first, not changing note contents or write safety.
• The safest first pass is one that does not change server-side write behavior or the existing write-tool schema.
• If payload-size reduction is needed beyond display compaction, a follow-up design can evaluate a reference-based input mode separately.
• Component involved: mcp.
• Example symptom: capture_note with a long body causes the full note content to appear in the Called block of the chat session.