Two notification-subscription tools omit destructiveHint, defaulting to destructive under MCP 2025-06-18

[MaazAhmed47]

Describe the bug

Under MCP schema 2025-06-18, an omitted destructiveHint defaults to true.

Two tools currently emit readOnlyHint: false but omit destructiveHint, so a spec-conformant client will render them as destructive even though they appear to operate only on the caller's own notification-subscription state:

1. manage_notification_subscription in pkg/github/notifications.go:413

   • Updates the caller's own thread subscription state (watch, ignore, or remove the subscription preference record at :460 and :465)
   • This does not modify thread or repository content

2. manage_repository_notification_subscription in pkg/github/notifications.go:509

   • Updates the caller's own repository subscription state (subscribed, ignored, or remove the subscription preference record at :564 and :569)
   • This does not modify repository content

If that reading is right, both tools are non-read-only but not destructive, and should set destructiveHint: false explicitly.

I'm filing this as a question rather than asserting a bug in case I'm misreading the intended risk model.

I scoped this deliberately to these two tools. I did not include other write tools because their current hints are more arguable from source review.

Affected version

GitHub MCP Server v1.5.0

Source reviewed at commit 40db5e3
Affected code:

• pkg/github/notifications.go:413
• pkg/github/notifications.go:509

Steps to reproduce

1. Open pkg/github/notifications.go
2. Inspect manage_notification_subscription and manage_repository_notification_subscription
3. Note that both emit readOnlyHint: false
4. Note that neither sets destructiveHint
5. Under MCP schema 2025-06-18, a conformant client therefore interprets both as destructiveHint: true

Expected behavior

These per-user subscription toggles should surface as non-destructive writes.

Actual behavior

They default to destructive under schema 2025-06-18, so consent UIs over-warn on operations that appear to affect only the caller's own subscription metadata.

Logs

N/A. Static annotation review only.

If this matches the intended semantics, I'm happy to open a small PR setting destructiveHint: false explicitly on both. From the repo comments, it looks like snapshots can be regenerated with:

UPDATE_TOOLSNAPS=true go test ./...

[juneja-varun]

This reading looks right to me — I'll send a small PR setting destructiveHint: false explicitly on both tools, plus regenerating the toolsnaps.

[MaazAhmed47]

Thanks for taking this forward. One point worth resolving before merge is the competing interpretation in #2936: both tools include a delete action, while the schema describes destructiveHint: false as performing only additive updates.

My original reasoning treated removal of the caller’s notification-subscription preference as non-destructive because it does not delete thread or repository content. However, because annotations apply to the entire tool, the literal “only additive updates” wording may support true.
I’d appreciate a maintainer ruling on which interpretation matches the intended annotation model.

[alirezainanlosalehi7-lgtm]

🙏🙏🙏

…

On Sat, Aug 15, 2026, 8:28 AM Syed Maaz Ahmed ***@***.***> wrote: *MaazAhmed47* left a comment (github/github-mcp-server#2841) <#2841 (comment)> Thanks for taking this forward. One point worth resolving before merge is the competing interpretation in #2936 <#2936>: both tools include a delete action, while the schema describes destructiveHint: false as performing only additive updates. My original reasoning treated removal of the caller’s notification-subscription preference as non-destructive because it does not delete thread or repository content. However, because annotations apply to the entire tool, the literal “only additive updates” wording may support true. I’d appreciate a maintainer ruling on which interpretation matches the intended annotation model. — Reply to this email directly, view it on GitHub <#2841?email_source=notifications&email_token=B5TQM2MPYRP4LPTTHBA37ED5J7UXNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZQGA3DENRYGI3KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5300626826>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5TQM2LCWBDGIZAMLUG6JJD5J7UXNAVCNFSNUABFKJSXA33TNF2G64TZHM4TIMRXG4YTEOBUHNEXG43VMU5TIOBTG44DQNBVGI22C5QC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[juneja-varun]

@MaazAhmed47 good catch, and on reflection I think #2936 has the right read of this, not my PR.

My reasoning for false was about real-world blast radius — removing your own subscription preference doesn't touch thread or repository content, so it felt low-risk. But that's not what the spec actually tests. Per the 2026-07-28 draft, destructiveHint: false means the tool performs only additive updates, and annotations apply to the whole tool, not per-action. manage_notification_subscription's delete action genuinely calls client.Activity.DeleteThreadSubscription — that's not additive by any literal reading, regardless of how narrow its effect is. Same applies to manage_repository_notification_subscription's delete action.

I'll close #3074 in favor of #2936 — no point carrying a duplicate with the less-defensible interpretation once a more careful reading is already up.