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 ./...