anthropics / anthropics/claude-ai-mcp
Read and Write Apple Notes: extension injects inline font-size and discards Apple Notes' native paragraph styles (body text lands at 9px)
- Dominant language
- No language data
- Stars
- 471
- Forks
- 76
- PR merge metrics
- No merged PRs in 30d
Description
### What happened?
**Extension:** Read and Write Apple Notes
**Affected tools:** `add_note`, `update_note_content`
**Platform:** macOS, Apple Notes
Notes written through `add_note` / `update_note_content` cannot use Apple Notes' built-in paragraph styles (Title, Heading, Subheading, Body). The extension rewrites every text run with an explicit inline `font-size`, and body text lands at **9px**. On a Mac this is merely small; on iPhone it is effectively unreadable. Exporting the same content as a Markdown file and importing it into Notes by hand produces a correctly styled, native-looking note, so the round trip through this extension is currently worse than not using it.
### 1. Plain-text newlines are collapsed
Content passed as plain text with `\n` line breaks is stored as a single run-on paragraph, losing every line break and list. Callers are forced to hand-author HTML, which is not mentioned in the tool descriptions.
### 2. Inline font-size is injected onto every text run
Regardless of input, every text node comes back wrapped in ``. A note authored by hand in Apple Notes has **no** `font-size` attributes at all, so this is not how Notes represents its own content.
Hand-authored note, read via `get_note_content`:
```html
Eye Drops
- Systane Balance - lipid drop
```
Same structure written through the extension, then read back:
```html
- Systane Balance - lipid drop
```
The `
` is gone, replaced by bold plus a hardcoded size. Notes no longer treats that line as a Title, so it does not scale with the user's Notes text-size setting or with Dynamic Type on iOS.
### 3. Semantic heading tags are flattened to fixed pixel sizes
Measured by writing each tag and reading the note back:
| Input | Stored as |
|---|---|
| `
` | `` |
| `` | `` |
| `` | `` |
| ``, `` | `` |
### 4. px font sizes are silently discarded, pt sizes are honored
An author trying to work around the 9px default finds that `px` values are dropped while `pt` values pass through, scaled by roughly 0.875:
| Input | Stored as |
|---|---|
| `font-size: 17px` | `9px` (discarded) |
| `font-size: 14pt` | `12px` |
| `font-size: 16pt` | `14px` |
| `font-size: 20pt` | `18px` |
| `font-size: 24pt` | `21px` |
| `font-size: 28pt` | `25px` |
Two units behaving differently, with the more common one silently dropped, is surprising on its own. It also means the only way to get readable output today is to hardcode `pt` sizes on every element, which is exactly the thing that breaks Dynamic Type.
### 5. HTML entities lose their trailing semicolon
`&` and `"` in the input are stored as the literal text `&` and `"`, visible to the user in the note body. Workaround is to avoid entities and pass literal characters.
### 6. Nested lists are flattened
An `
` nested inside an `- ` is re-emitted as a sibling of the enclosing `
` rather than as a nested list, losing the indentation level.
### 7. update_note_content silently renames the note
Because Notes derives the note name from its first line, calling `update_note_content` with a body that does not repeat the title renames the note; the tool's own success message reports the new name. This is easy to trip over, since `add_note` takes `name` as a separate parameter, implying the name is stored independently of the body.
### Impact
For any note longer than a few lines the output is worse than the manual Markdown-import workaround. The 9px body size in particular makes generated notes unusable on iPhone, which is where quick-reference notes such as recipes and checklists are most likely to be read.
Related prior report on formatting fidelity: #29 (native checkboxes).
### What did you expect to happen?
Content written through the extension should look like a note the user typed by hand: no inline `font-size` at all, with semantic HTML mapped onto Apple Notes' own paragraph styles (`
` to Title, `
` to Heading, `
` to Subheading, everything else to Body). Notes already renders a plain `
` correctly when content arrives via Markdown import, so the target representation is well established.
Suggested fixes, roughly in order of value:
1. Stop injecting `font-size` spans. Pass semantic tags through and let Notes apply its own stylesheet.
2. Accept Markdown for `content` / `new_content`, since Notes' Markdown import already produces correct native styling. This alone would resolve most of the above.
3. Document in the tool descriptions that content is interpreted as HTML and that plain-text newlines are not preserved.
4. Fix entity handling so `&` and `"` survive.
5. Preserve nested list structure.
6. Either preserve the note name across `update_note_content`, or document that the first line becomes the title.
Separately, a `delete_note` tool (or move-to-Recently-Deleted) would help. There is currently no way to clean up notes created during testing or created in error.
### Steps to reproduce
1. In Apple Notes, create a note by hand with a Title line, a body line, and a bulleted list. Read it with `get_note_content` and observe there are no `font-size` attributes anywhere.
2. Call `add_note` with multi-line plain text content. Read it back: all newlines are gone, the note is one paragraph.
3. Call `update_note_content` on that note with well-formed HTML, for example:
```html
Alpha Title
Bravo Heading
Charlie Subheading
Delta explicit span
Echo plain body
- Foxtrot list item
```
4. Read it back with `get_note_content`. Every run now carries an inline size: the headings became bold 16px / 12px / 9px, and all body and list text became 9px, including the run that explicitly asked for 17px.
5. Repeat step 3 using `pt` instead of `px` (for example `font-size: 16pt`) and read back: the value is honored, stored as 14px. Only `px` is discarded.
6. Open the note on an iPhone. The 9px body text is too small to read comfortably at default settings, and does not respond to the Notes text-size setting because the size is hardcoded.
Wrapping the input in a full `` document, or nesting `
` inside a `` the way a native note does, makes no difference.
### Area
Tool Discovery / Invocation
### MCP Server (if applicable)
Read and Write Apple Notes (Anthropic desktop extension)
### Error messages or logs
```shell
No errors are raised. Every call returns success; the formatting is silently rewritten.
```
### Additional context
Reproduced on macOS with the Claude desktop app in August 2026, reading and writing through the Read and Write Apple Notes extension. Real-world case: converting a two-page recipe PDF into a note. The result was legible on a Mac but too small to read on iPhone, and the workaround that produced a correct native-looking note was to export Markdown and import it into Notes by hand, bypassing the extension entirely.
| `
` | `` |
| ``, `` | `` |
### 4. px font sizes are silently discarded, pt sizes are honored
An author trying to work around the 9px default finds that `px` values are dropped while `pt` values pass through, scaled by roughly 0.875:
| Input | Stored as |
|---|---|
| `font-size: 17px` | `9px` (discarded) |
| `font-size: 14pt` | `12px` |
| `font-size: 16pt` | `14px` |
| `font-size: 20pt` | `18px` |
| `font-size: 24pt` | `21px` |
| `font-size: 28pt` | `25px` |
Two units behaving differently, with the more common one silently dropped, is surprising on its own. It also means the only way to get readable output today is to hardcode `pt` sizes on every element, which is exactly the thing that breaks Dynamic Type.
### 5. HTML entities lose their trailing semicolon
`&` and `"` in the input are stored as the literal text `&` and `"`, visible to the user in the note body. Workaround is to avoid entities and pass literal characters.
### 6. Nested lists are flattened
An `
` nested inside an `- ` is re-emitted as a sibling of the enclosing `
` rather than as a nested list, losing the indentation level.
### 7. update_note_content silently renames the note
Because Notes derives the note name from its first line, calling `update_note_content` with a body that does not repeat the title renames the note; the tool's own success message reports the new name. This is easy to trip over, since `add_note` takes `name` as a separate parameter, implying the name is stored independently of the body.
### Impact
For any note longer than a few lines the output is worse than the manual Markdown-import workaround. The 9px body size in particular makes generated notes unusable on iPhone, which is where quick-reference notes such as recipes and checklists are most likely to be read.
Related prior report on formatting fidelity: #29 (native checkboxes).
### What did you expect to happen?
Content written through the extension should look like a note the user typed by hand: no inline `font-size` at all, with semantic HTML mapped onto Apple Notes' own paragraph styles (`
` to Title, `
` to Heading, `
` to Subheading, everything else to Body). Notes already renders a plain `
` correctly when content arrives via Markdown import, so the target representation is well established.
Suggested fixes, roughly in order of value:
1. Stop injecting `font-size` spans. Pass semantic tags through and let Notes apply its own stylesheet.
2. Accept Markdown for `content` / `new_content`, since Notes' Markdown import already produces correct native styling. This alone would resolve most of the above.
3. Document in the tool descriptions that content is interpreted as HTML and that plain-text newlines are not preserved.
4. Fix entity handling so `&` and `"` survive.
5. Preserve nested list structure.
6. Either preserve the note name across `update_note_content`, or document that the first line becomes the title.
Separately, a `delete_note` tool (or move-to-Recently-Deleted) would help. There is currently no way to clean up notes created during testing or created in error.
### Steps to reproduce
1. In Apple Notes, create a note by hand with a Title line, a body line, and a bulleted list. Read it with `get_note_content` and observe there are no `font-size` attributes anywhere.
2. Call `add_note` with multi-line plain text content. Read it back: all newlines are gone, the note is one paragraph.
3. Call `update_note_content` on that note with well-formed HTML, for example:
```html
Alpha Title
Bravo Heading
Charlie Subheading
Delta explicit span
Echo plain body
- Foxtrot list item
```
4. Read it back with `get_note_content`. Every run now carries an inline size: the headings became bold 16px / 12px / 9px, and all body and list text became 9px, including the run that explicitly asked for 17px.
5. Repeat step 3 using `pt` instead of `px` (for example `font-size: 16pt`) and read back: the value is honored, stored as 14px. Only `px` is discarded.
6. Open the note on an iPhone. The 9px body text is too small to read comfortably at default settings, and does not respond to the Notes text-size setting because the size is hardcoded.
Wrapping the input in a full `` document, or nesting `
` inside a `` the way a native note does, makes no difference.
### Area
Tool Discovery / Invocation
### MCP Server (if applicable)
Read and Write Apple Notes (Anthropic desktop extension)
### Error messages or logs
```shell
No errors are raised. Every call returns success; the formatting is silently rewritten.
```
### Additional context
Reproduced on macOS with the Claude desktop app in August 2026, reading and writing through the Read and Write Apple Notes extension. Real-world case: converting a two-page recipe PDF into a note. The result was legible on a Mac but too small to read on iPhone, and the workaround that produced a correct native-looking note was to export Markdown and import it into Notes by hand, bypassing the extension entirely.
` | `` |
### 4. px font sizes are silently discarded, pt sizes are honored
An author trying to work around the 9px default finds that `px` values are dropped while `pt` values pass through, scaled by roughly 0.875:
| Input | Stored as |
|---|---|
| `font-size: 17px` | `9px` (discarded) |
| `font-size: 14pt` | `12px` |
| `font-size: 16pt` | `14px` |
| `font-size: 20pt` | `18px` |
| `font-size: 24pt` | `21px` |
| `font-size: 28pt` | `25px` |
Two units behaving differently, with the more common one silently dropped, is surprising on its own. It also means the only way to get readable output today is to hardcode `pt` sizes on every element, which is exactly the thing that breaks Dynamic Type.
### 5. HTML entities lose their trailing semicolon
`&` and `"` in the input are stored as the literal text `&` and `"`, visible to the user in the note body. Workaround is to avoid entities and pass literal characters.
### 6. Nested lists are flattened
An `
- ` nested inside an `
- ` is re-emitted as a sibling of the enclosing `
- ` rather than as a nested list, losing the indentation level.
- Foxtrot list item
### 7. update_note_content silently renames the note
Because Notes derives the note name from its first line, calling `update_note_content` with a body that does not repeat the title renames the note; the tool's own success message reports the new name. This is easy to trip over, since `add_note` takes `name` as a separate parameter, implying the name is stored independently of the body.
### Impact
For any note longer than a few lines the output is worse than the manual Markdown-import workaround. The 9px body size in particular makes generated notes unusable on iPhone, which is where quick-reference notes such as recipes and checklists are most likely to be read.
Related prior report on formatting fidelity: #29 (native checkboxes).
### What did you expect to happen?
Content written through the extension should look like a note the user typed by hand: no inline `font-size` at all, with semantic HTML mapped onto Apple Notes' own paragraph styles (`
` to Title, `
` to Heading, `
` to Subheading, everything else to Body). Notes already renders a plain `
` correctly when content arrives via Markdown import, so the target representation is well established.
Suggested fixes, roughly in order of value:
1. Stop injecting `font-size` spans. Pass semantic tags through and let Notes apply its own stylesheet.
2. Accept Markdown for `content` / `new_content`, since Notes' Markdown import already produces correct native styling. This alone would resolve most of the above.
3. Document in the tool descriptions that content is interpreted as HTML and that plain-text newlines are not preserved.
4. Fix entity handling so `&` and `"` survive.
5. Preserve nested list structure.
6. Either preserve the note name across `update_note_content`, or document that the first line becomes the title.Separately, a `delete_note` tool (or move-to-Recently-Deleted) would help. There is currently no way to clean up notes created during testing or created in error.
### Steps to reproduce
1. In Apple Notes, create a note by hand with a Title line, a body line, and a bulleted list. Read it with `get_note_content` and observe there are no `font-size` attributes anywhere.
2. Call `add_note` with multi-line plain text content. Read it back: all newlines are gone, the note is one paragraph.
3. Call `update_note_content` on that note with well-formed HTML, for example:```html
Alpha Title
Bravo Heading
Charlie Subheading
Delta explicit spanEcho plain body
```4. Read it back with `get_note_content`. Every run now carries an inline size: the headings became bold 16px / 12px / 9px, and all body and list text became 9px, including the run that explicitly asked for 17px.
5. Repeat step 3 using `pt` instead of `px` (for example `font-size: 16pt`) and read back: the value is honored, stored as 14px. Only `px` is discarded.
6. Open the note on an iPhone. The 9px body text is too small to read comfortably at default settings, and does not respond to the Notes text-size setting because the size is hardcoded.Wrapping the input in a full `` document, or nesting `
` inside a `
` the way a native note does, makes no difference.### Area
Tool Discovery / Invocation
### MCP Server (if applicable)
Read and Write Apple Notes (Anthropic desktop extension)
### Error messages or logs
```shell
No errors are raised. Every call returns success; the formatting is silently rewritten.
```### Additional context
Reproduced on macOS with the Claude desktop app in August 2026, reading and writing through the Read and Write Apple Notes extension. Real-world case: converting a two-page recipe PDF into a note. The result was legible on a Mac but too small to read on iPhone, and the workaround that produced a correct native-looking note was to export Markdown and import it into Notes by hand, bypassing the extension entirely.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.