feat: implement notification thread management #12

New Issue

2026-06-02T06:57:01Z

a-limasov commented

2026-06-02 06:57:01 +00:00

Context

Currently the MCP server can list notifications and mark all as read, but cannot
interact with individual notification threads — marking a single one as read,
fetching its details, or checking whether there are any unread notifications at all.

Endpoints to implement

Method	Path	Tool name	Description
GET	`/notifications/new`	`check_notifications_new`	Check if there are unread notifications
GET	`/repos/{owner}/{repo}/notifications`	`list_repo_notifications`	List notifications for a specific repo
PUT	`/repos/{owner}/{repo}/notifications`	`mark_repo_notifications_read`	Mark all repo notifications as read
GET	`/notifications/threads/{id}`	`get_notification_thread`	Get single notification thread
PATCH	`/notifications/threads/{id}`	`mark_notification_thread_read`	Mark single thread as read

Acceptance Criteria

check_notifications_new returns {"has_new": true/false} (wraps the API's integer response)
list_repo_notifications(owner, repo, all, limit, page) mirrors list_notifications interface
mark_repo_notifications_read(owner, repo) returns {"success": true}
get_notification_thread(id) returns full thread object
mark_notification_thread_read(id) returns {"success": true} on 205

Technical Notes

GET /notifications/new returns {"new": 0} — a count, not a boolean; wrap it: {"has_new": result["new"] > 0, "count": result["new"]}
PATCH /notifications/threads/{id} returns 205 Reset Content (not 204) — handle in _req or inline
list_repo_notifications supports since and before datetime params (ISO 8601) — add them as optional args

## Context Currently the MCP server can list notifications and mark all as read, but cannot interact with individual notification threads — marking a single one as read, fetching its details, or checking whether there are any unread notifications at all. ## Endpoints to implement | Method | Path | Tool name | Description | |--------|------|-----------|-------------| | GET | `/notifications/new` | `check_notifications_new` | Check if there are unread notifications | | GET | `/repos/{owner}/{repo}/notifications` | `list_repo_notifications` | List notifications for a specific repo | | PUT | `/repos/{owner}/{repo}/notifications` | `mark_repo_notifications_read` | Mark all repo notifications as read | | GET | `/notifications/threads/{id}` | `get_notification_thread` | Get single notification thread | | PATCH | `/notifications/threads/{id}` | `mark_notification_thread_read` | Mark single thread as read | ## Acceptance Criteria - [ ] `check_notifications_new` returns `{"has_new": true/false}` (wraps the API's integer response) - [ ] `list_repo_notifications(owner, repo, all, limit, page)` mirrors `list_notifications` interface - [ ] `mark_repo_notifications_read(owner, repo)` returns `{"success": true}` - [ ] `get_notification_thread(id)` returns full thread object - [ ] `mark_notification_thread_read(id)` returns `{"success": true}` on 205 ## Technical Notes - `GET /notifications/new` returns `{"new": 0}` — a count, not a boolean; wrap it: `{"has_new": result["new"] > 0, "count": result["new"]}` - `PATCH /notifications/threads/{id}` returns 205 Reset Content (not 204) — handle in `_req` or inline - `list_repo_notifications` supports `since` and `before` datetime params (ISO 8601) — add them as optional args

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: a-limasov/gitea-platform-mcp#12