Reported issues for Nelson MCP — LibreOffice Desktop Extension

Pod holds 19 of 30 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to Nelson MCP — LibreOffice Desktop Extension.

Most discussed

MCP edits are recorded as tracked changes even when Record Changes is off — please consider an opt-out

Summary

With Edit → Track Changes → Record Changes switched off in the LibreOffice UI, edits performed through Nelson MCP tools are still written into xl/revisions/ on save. Manual edits typed in the UI are correctly not recorded.

Steps to reproduce

Open a .xlsx in LibreOffice Calc.
Make sure Edit → Track Changes → Record Changes is off.
Via MCP: write_cell_range -> Price!A60 = "TEST2"
By hand in the UI: type Price!A61 = "manual test" 5.…

Read the thread · 2026-07-21 · closed · external user · 10 comments

/health reports a stale active document after doc_open, while doc_info and doc_list_open are correct

The document block that /health returns does not reflect a document opened through doc_open. It either reports no document at all, or reports one with doc_type: null and a doc_id that belongs to no open document. The tools themselves are fine throughout: doc_info and doc_list_open always return the correct, stable id.

Measured on 0.14.0 against a freshly started GUI instance, six opens in total, each one a separate MCP session, .xlsx in Calc:

| after doc_open, /health…

Read the thread · 2026-09-19 · closed · external user · 9 comments

doc_open on an already open document creates a second view, both reported active, and closing one drops the file lock

Version 0.14.0 (.oxt), LibreOffice Calc, Linux, HTTP MCP transport.

Calling doc_open with the path of a document that is already open does not return the existing document. It opens a second view of the same file, and the state that follows is hard for a caller to reason about.

Reproduction:

open a spreadsheet from outside Nelson: soffice /tmp/doc_01.xlsx
doc_open({file_path: "/tmp/doc_01.xlsx"})
doc_list_open

What you get:

two entries with different doc_ids for the…

Read the thread · 2026-09-19 · closed · external user · 8 comments

doc_close ignores _document, closes the active document instead, and reports success when it closed nothing

Version 0.12.1 (.oxt), LibreOffice Calc, Linux, HTTP MCP transport.

doc_close has three separate faults that compound each other.

1. _document is ignored. doc_close({_document: "id:<B>"}) does not close B — it closes the active document. The response echoes "active_document": "<B>", so from the outside it looks like the right thing happened.

2. It returns ok even when it closed nothing. In a batch of 13 calls I got "Document closed." 13 times; exactly one document…

Read the thread · 2026-08-20 · open · external user · 8 comments

MCP session dies on LibreOffice restart — could the server accept re-initialization on the same endpoint?

Nelson runs inside LibreOffice, so every restart of the application invalidates the MCP session. The next tool call then returns:

-32000: Session expired (server restarted). Please re-initialize the MCP connection.

The message is clear and the server behaves correctly. The friction is on the client side: the MCP client still lists the server as connected, so a dead session and a live one look identical until a call fails. Recovering requires the user to disconnect and reconnect the server…

Read the thread · 2026-08-21 · closed · external user · 6 comments

Deadlock on cold start when LibreOffice is launched with a document: no window ever appears

When LibreOffice is started cold with a document on the command line, it sometimes never shows a window. The process stays alive, port 8766 is bound, and the desktop taskbar keeps a dead "starting" entry that does nothing when clicked. Killing the process and opening the same file again works, so this is a startup race rather than a permanent failure.

This is easy to hit in daily use: opening a spreadsheet attachment from a mail client launches soffice --calc <file> while no LibreOffice…

Read the thread · 2026-08-14 · open · external user · 6 comments

save_document_as does not rebind the document — a later save_document overwrites the original file

Summary

save_document_as writes the target file and returns status: ok with the new file_url, but the open document stays bound to its original location. A subsequent save_document therefore writes back to the original file, while the file created by save_document_as stays frozen at the moment of the call.

The tool description says: "The document adopts the new file as its location (like File > Save As, not an export)." The observed behaviour is the opposite — it acts like…

Read the thread · 2026-07-21 · closed · external user · 6 comments

Add fit_image tool to auto-fit an image within its frame

Context

After manually rotating an image in LibreOffice (portrait → landscape), the AI assistant needs to resize the image to fit inside its existing frame. Currently this requires:

Reading the frame dimensions
Knowing the image's actual pixel ratio (which may have changed after rotation)
Manually calculating the correct width/height
Calling set_image_properties with both dimensions (risk of breaking the ratio)
Optionally resizing the frame if the image doesn't fit

This…

Read the thread · 2026-04-08 · closed · 6 comments

Most recent

/health and doc_info treat the Start Center as a document after the first tools/list

On a fresh LibreOffice started without a file, with the Start Center current, /health is correct (available: false) until the first tools/list. After it, /health reports available: true with doc_type: null and a doc_id that is new on every start. doc_info without _document resolves to that same id and fails with execution_error, message getURL, while doc_list_open returns 0 documents. The state stays until a document is opened; after a doc_open and doc_close, a…

Read the thread · 2026-09-27 · open · external user · 1 comment

OnStartApp bootstrap deadlocks LibreOffice startup when RecoveryInfo/Crashed=true (Solar Mutex × Recovery SynchronousDispatch)

OnStartApp bootstrap deadlocks LibreOffice startup when `RecoveryInfo/Crashed=true` — Solar Mutex × Recovery `SynchronousDispatch`

Environment

Nelson: 0.12.1 (nelson-0.12.1.oxt)
LibreOffice: 26.2.5.2 (openSUSE Tumbleweed distro build; upstream TDF 26.2.5)
VCL plugin: Qt6 on KDE Plasma 6 Wayland
Python: 3.13
OS: openSUSE Tumbleweed, Linux 7.1.8

Symptom

After any LibreOffice crash that leaves RecoveryInfo/Crashed=true in the user's…

Read the thread · 2026-08-20 · open · external user · 5 comments

doc_open returns ok before the document is resolvable as active — the next tool call fails with no_document (retryable: false)

The first tool call that targets the active document immediately after doc_open fails, even though doc_open returned ok and doc_list_open lists the document:

{"status":"error","code":"no_document","message":"No document open in LibreOffice.",
 "retryable":false,"hint":"Use doc_create or doc_open first."}

doc_open apparently returns before the newly opened document becomes resolvable as the current/active component. Measured on 0.12.1 in a single MCP session (one…

Read the thread · 2026-07-26 · closed · external user · 5 comments

A prefix that disagrees with sheet_name is accepted silently on the write paths, not refused

Two loose ends from #30, both small, found while verifying that fix on 0.12.1.

Your comment said a prefix wins over sheet_name and that disagreeing between the two is an error rather than a silent choice. The guard is there in CalcBridge.resolve(), but the write paths don't go through it:

calc_write_range  start_cell="Summary.B4"  values=[["CONFLICT"]]  sheet_name="Sources"
  → ok, "Wrote 1 rows, 1 cols starting at B4."
     Summary.B4 = 'CONFLICT'      Sources.B4 = None

calc_comment…

[Read the thread](https://github.com/quazardous/nelson-mcp/issues/33) · 2026-07-25 · closed · external user · 5 comments

### Generated chart names collide across sheets, and the failure surfaces as an empty error message

Found while verifying #30 on 0.12.1. This one only became reachable because of that fix — until charts could land on more than one sheet, the counter always matched.

`create_chart` names a new chart `Chart_{len(charts)}`, counting the charts on the target sheet. The name has to be unique across the whole document though, so the second chart on a different sheet asks for `Chart_0` again and `addNewByName` throws:

chart on Capex from A1:B4 → ok (Chart_0) another chart…

Read the thread · 2026-07-25 · closed · external user · 5 comments

A chart built from a sheet-qualified data_range lands on the data sheet, not the active one

Follow-up from #30, found while verifying that fix on 0.12.1.

A sheet-qualified data_range is accepted now and the chart does get built — but it is added to the sheet the data lives on, rather than the active one. Your comment on #30 described the opposite, and it was the case you asked me to confirm, so here is what I see.

Workbook has four sheets, Capex active:

calc_chart create  data_range="'Data Sheet'.A1:B5"  chart_type="bar"
                   title="cross-sheet"  position="D1"…

[Read the thread](https://github.com/quazardous/nelson-mcp/issues/31) · 2026-07-25 · closed · external user · 5 comments

### Sheet-qualified ranges (Sheet1.A1:C5) are always rejected, though the tool description advertises them

The `read_cell_range` description advertises sheet-qualified ranges:

> `range_name`: Cell range(s) (e.g. **A1:D10, Sheet1.A1:C5**) or list of ranges/cells…

The parser never accepts one. It isn't about spaces in the name — a single-word sheet fails just as reliably:

read_cell_range {"range_name": "Summary.D4:D6"} → Invalid cell range format: 'SUMMARY.D4:D6' read_cell_range {"range_name": "Sources.A1:A3"} → Invalid cell range format: 'SOURCES.A1:A3' read_cell_range {"range_name":…

Read the thread · 2026-07-25 · closed · external user · 4 comments

Per-module enable/disable, so users can turn off what they do not use

Spun off from #15, which asked for launchers and text-to-image to be separate plugins. The underlying goal — do not run what I do not use — is right; splitting into separate .oxt files is an expensive way to get it (rationale in #15). This is the cheap way.

Current state

Exactly one module can be turned off: mcp, via its enabled config key. Every other module loads unconditionally. There is no generic mechanism — nothing in ModuleBase or the bootstrap consults an enable flag.

So…

Read the thread · 2026-07-25 · closed · 2 comments

text_search_fulltext silently misses text frames that text_search finds

Spun off from #7 as the one concrete, reproducible defect left in it.

Nelson has two search backends over the same document and they disagree. The index-backed one returns nothing rather than saying it does not cover the content — a silent wrong answer, which is the worst failure mode for an agent, since it will conclude the text is not there.

Reproduction

A Writer document with an image inserted via image_insert, which wraps it in a captioned text frame (caption: logo):


[Read the thread](https://github.com/quazardous/nelson-mcp/issues/28) · 2026-07-25 · closed · 3 comments

### Guide tool selection: the instructions field, misleading affordances, and the unbuilt tool broker

Spun off from #2. That issue reported an LLM **creating a new document instead of opening the one the user named**, and ignoring the headings it was asked to use. Everything done since (custom endpoints, document-type filtering, the #11 rename and merges) reduced *how many* tools the model sees — none of it addressed *how it chooses*. Three concrete gaps, cheapest first.

## 1. The `instructions` field is wasted

`initialize` returns an `instructions` string that MCP clients inject straight…

[Read the thread](https://github.com/quazardous/nelson-mcp/issues/27) · 2026-07-25 · closed · 4 comments

### Declare tools.listChanged: true and emit list_changed when the active document type changes

## Summary

Nelson filters its tool list by the type of the currently open document — a great design for keeping context small (~27 generic tools with no document, 61 with a Calc document, ~96 with a Writer document; measured on v0.8.2, `minimal` preset). However, `initialize` declares:

```json
"capabilities": {"tools": {"listChanged": false}}

With listChanged: false, MCP clients cache the tool list once at connect time and never re-fetch it. The two features interact badly:

A…

Read the thread · 2026-07-23 · closed · external user · 3 comments

The remaining reports are on the project's issue tracker.

Reported issues for Nelson MCP — LibreOffice Desktop Extension

Most discussed

MCP edits are recorded as tracked changes even when Record Changes is off — please consider an opt-out

Summary

Steps to reproduce

/health reports a stale active document after doc_open, while doc_info and doc_list_open are correct

doc_open on an already open document creates a second view, both reported active, and closing one drops the file lock

doc_close ignores _document, closes the active document instead, and reports success when it closed nothing

MCP session dies on LibreOffice restart — could the server accept re-initialization on the same endpoint?

Deadlock on cold start when LibreOffice is launched with a document: no window ever appears

save_document_as does not rebind the document — a later save_document overwrites the original file

Summary

Add fit_image tool to auto-fit an image within its frame

Context

Most recent

/health and doc_info treat the Start Center as a document after the first tools/list

OnStartApp bootstrap deadlocks LibreOffice startup when RecoveryInfo/Crashed=true (Solar Mutex × Recovery SynchronousDispatch)

OnStartApp bootstrap deadlocks LibreOffice startup when RecoveryInfo/Crashed=true — Solar Mutex × Recovery SynchronousDispatch

Environment

Symptom

doc_open returns ok before the document is resolvable as active — the next tool call fails with no_document (retryable: false)

A prefix that disagrees with sheet_name is accepted silently on the write paths, not refused

A chart built from a sheet-qualified data_range lands on the data sheet, not the active one

Per-module enable/disable, so users can turn off what they do not use

Current state

text_search_fulltext silently misses text frames that text_search finds

Reproduction

OnStartApp bootstrap deadlocks LibreOffice startup when `RecoveryInfo/Crashed=true` — Solar Mutex × Recovery `SynchronousDispatch`