Problem
The MCP server exposes add_*_note and list_*_note for epics/issues/MRs, but no update_*_note or delete_*_note. When a note needs to be rewritten (wrong language, typo, outdated info) or removed, callers must drop back to raw glab api graphql with the updateNote / destroyNote mutations — breaking the MCP-first contract.
Concretely encountered during an internal cleanup session on 2026-04-20: 8 notes posted in French had to be rewritten in English (per project convention). Each correction required a manual GraphQL fallback.
A related limitation: list_*_note responses currently don't include the note's global ID. Even if update_*_note / delete_*_note shipped today, a caller couldn't identify which note to target from the list output (only author, body, createdAt are visible).
Proposal
Two coordinated changes:
1. Add the missing tools (thin wrappers over existing GraphQL mutations):
| Tool |
GraphQL mutation |
update_epic_note, update_issue_note, update_mr_note |
updateNote(input: { id, body }) |
delete_epic_note, delete_issue_note, delete_mr_note |
destroyNote(input: { id }) |
Input shape: the note global ID (e.g. gid://gitlab/Note/12345) + body for updates.
2. Expose the note global ID in list_*_note
Add the id field to the list output so callers can feed it straight into the new update/delete tools.
Why this matters
- MCP-first workflows break as soon as a note correction is needed — currently the only recourse is raw GraphQL with hand-built payloads.
- Note correction is a routine operation, not an edge case (language conventions, typos, updating status summaries as work progresses).
- Both mutations already exist server-side; this is purely wrapper surface area.
Effort
Low. Both mutations are thin wrappers; exposing id in the list output is a single additional field in the existing query.
Problem
The MCP server exposes
add_*_noteandlist_*_notefor epics/issues/MRs, but noupdate_*_noteordelete_*_note. When a note needs to be rewritten (wrong language, typo, outdated info) or removed, callers must drop back to rawglab api graphqlwith theupdateNote/destroyNotemutations — breaking the MCP-first contract.Concretely encountered during an internal cleanup session on 2026-04-20: 8 notes posted in French had to be rewritten in English (per project convention). Each correction required a manual GraphQL fallback.
A related limitation:
list_*_noteresponses currently don't include the note's global ID. Even ifupdate_*_note/delete_*_noteshipped today, a caller couldn't identify which note to target from the list output (onlyauthor,body,createdAtare visible).Proposal
Two coordinated changes:
1. Add the missing tools (thin wrappers over existing GraphQL mutations):
update_epic_note,update_issue_note,update_mr_noteupdateNote(input: { id, body })delete_epic_note,delete_issue_note,delete_mr_notedestroyNote(input: { id })Input shape: the note global ID (e.g.
gid://gitlab/Note/12345) +bodyfor updates.2. Expose the note global ID in
list_*_noteAdd the
idfield to the list output so callers can feed it straight into the new update/delete tools.Why this matters
Effort
Low. Both mutations are thin wrappers; exposing
idin the list output is a single additional field in the existing query.