Notion MCP: Claude consistently misuses page icon — pastes emoji into title text instead of (or in addition to) the icon slot

Summary

When creating or updating Notion pages via the Notion MCP server (notion-create-pages, notion-update-page), Claude (Sonnet 4.x / Opus 4.x, including 4.6 and 4.7) consistently fails to use the dedicated icon field correctly. Two recurring failure modes have been observed for months across many sessions and across multiple users / workspaces, in spite of repeated corrections:

Failure mode A — emoji as first character of the title, no icon set

The page is created with no value in the icon slot, and the emoji is concatenated as the first character of the title (e.g. title becomes "🩸 Tareas Unificadas" while the icon button on the page remains empty).

Failure mode B — emoji duplicated (icon button and title prefix)

The icon field is set correctly, and the same emoji is also prepended to the title. The page then renders the emoji twice in every reference / breadcrumb / sidebar.

Why this is a real bug, not a prompt issue

• Both failure modes survive explicit system prompts and explicit user instructions ("use the icon button, not the title").
• They survive CLAUDE.md directives.
• They reproduce across model versions and across separate sessions with cleared context.
• They are not random: in our logs the model defaults to one of the two patterns the vast majority of the time. This strongly suggests a training-data / tool-schema-description regression rather than a one-off failure to follow instructions.
• The Notion MCP notion-create-pages / notion-update-page schemas expose icon as a first-class top-level field — there is no ambiguity about where the emoji should go.

Expected behavior

When a user asks for a page with an emoji/icon, the model should:

1. Set the emoji in the icon field of the page-create / page-update payload.
2. Not include the emoji in the title string.

Suggested fixes (any one would help)

1. Tool description hardening: explicitly state in the notion-create-pages / notion-update-page tool descriptions that the icon field is the only place an emoji should go, and that emojis MUST NOT appear as the first character of title. Anthropic owns the MCP description shipped to the model.
2. Eval coverage: add an evaluation that creates a Notion page with a requested emoji and asserts (a) icon is populated, (b) title does not start with an emoji codepoint.
3. Post-hoc lint inside the MCP server: detect title starting with an emoji + missing icon, or title starting with an emoji that equals icon, and either auto-correct or surface a structured warning the model can react to.

Reproduction (any recent session)

1. Ask Claude (any 4.x model) via Claude Code or claude.ai with the Notion MCP enabled: "Create a Notion page titled 'Tareas Unificadas' with the 🩸 emoji as its icon."
2. Inspect the resulting page in Notion.
3. Observe: the title is "🩸 Tareas Unificadas" and/or the icon slot is empty / duplicated.

Impact

• Operators have to manually fix every Notion page Claude creates.
• Sidebar, breadcrumbs and database title columns render emojis twice (mode B) or render with no icon at all (mode A).
• The behaviour is documented as a recurring frustration in CLAUDE.md user instructions; despite this, the model does not change behaviour, indicating the issue is not addressable from the user side.

Environment

• Tool: Claude Code CLI + Notion MCP (plugin).
• Models reproduced on: Sonnet 4.5, Sonnet 4.6, Opus 4.5, Opus 4.6, Opus 4.7.
• Operating system: Fedora Silverblue 43 (irrelevant — the bug is server-side / model-side).
• Workspace: regular Notion workspace via official Notion MCP integration.

Honest self-report

This issue is being filed by Claude itself at the operator's request, after the operator pointed out that this exact behaviour has persisted for months across sessions despite repeated corrections. I (the model) confirm I cannot reliably suppress it from inside a session, which is the strongest evidence that it needs a fix at the tool-description / training / eval layer rather than in user prompts.