Bug: description_html/comment_html round-trip renders broken — empty nodes and inter-tag whitespace both produce phantom blank lines/bullets

Summary

Work items, comments, and other rich-text fields written via this MCP server's description_html/comment_html parameters (create_work_item, update_work_item, create_work_item_comment, create_page, etc.) are passed through to Plane's API as raw HTML with no normalization. Two distinct HTML patterns — both completely unremarkable, semantically-inert HTML that any browser or typical rich-text renderer treats as invisible — get rendered by Plane's own editor as visible broken artifacts: dead blank-line gaps and phantom empty bullets. Since LLM-authored HTML (the primary use case for an MCP server) very commonly contains exactly these patterns, this is a systemic footgun rather than an edge case.

Failure mode 1: literal empty block/list elements

Blank-line-as-visual-spacing (a natural habit carried over from markdown) becomes a literal empty element:

<p>Paragraph one.</p>
<p></p>
<p>Paragraph two.</p>

Plane's editor renders the middle <p></p> as a real, visible empty line — it is not discarded on import.

Same pattern inside a list:

<ul>
  <li><p></p></li>
  <li><p>Real item one</p></li>
  <li><p></p></li>
  <li><p>Real item two</p></li>
</ul>

renders as an empty bullet before every real one.

Failure mode 2: whitespace between tags (zero empty elements)

More surprising: even with no empty elements at all, pretty-printed HTML with a newline between sibling block tags produces the same visible artifact:

<p>Paragraph one.</p>

<p>Paragraph two.</p>

and

<ul>
<li>Real item one</li>
<li>Real item two</li>
</ul>

Every <p>/<li> here is individually non-empty — there is no empty element in the source — yet Plane's editor still renders a dead gap between the paragraphs and an empty bullet before each <li>. This is easy to miss: the HTML the API hands back (description_html/description_stripped) still contains the same inter-tag whitespace that was sent, so a program checking its own output for "emptiness" sees nothing wrong. The emptiness is a rendering artifact of raw whitespace sitting between tags, not a structural property visible in the HTML itself.

Why this matters specifically for an MCP server

LLM-generated HTML routinely uses blank lines between paragraphs and one-tag-per-line list formatting — completely standard, harmless HTML by any normal measure. Any agent using this MCP server to file well-formatted tickets/comments will hit one or both of these patterns by default, and there's no signal in the API response that anything is wrong. We only caught it by comparing a compact-HTML ticket against a pretty-printed one and noticing the pretty-printed one rendered broken, confirmed via a rendered screenshot.

We ended up writing a client-side HTML sanitizer (strip empty p/li/div/h1-h6, collapse whitespace-only text sitting between block-level siblings) plus a PreToolUse hook that runs every description_html/comment_html write through it before the MCP tool call executes, purely to work around this. That shouldn't be necessary for an MCP server whose whole purpose is letting an AI agent write this content directly.

Suggested fix

Normalize description_html/comment_html (and any other rich-text HTML parameter) server-side in the MCP tool implementations before forwarding to Plane's API: strip whitespace-only block-level text nodes and empty block/list elements. This might instead belong in Plane's own HTML-import path (the webapp itself), since the MCP server is just relaying whatever it's given — happy to file a companion issue against makeplane/plane if that's the more appropriate layer; pointers welcome.

Environment

• MCP server: https://mcp.plane.so/http/mcp (hosted)
• Observed via Claude Code using this server's create_work_item / update_work_item / create_work_item_comment tools

Start by reading the MCP tool implementations for create_work_item, update_work_item, create_work_item_comment, and create_page, tracing every description_html and comment_html parameter to the Plane API call. Determine whether normalization belongs in the server or Plane's import path, then verify that empty block elements and whitespace between block tags no longer produce the reported artifacts across all rich-text writes.