Skip to content

Mcp 260 notifications progress#41

Open
Antolius wants to merge 8 commits into
mainfrom
MCP-260-notifications-progress
Open

Mcp 260 notifications progress#41
Antolius wants to merge 8 commits into
mainfrom
MCP-260-notifications-progress

Conversation

@Antolius
Copy link
Copy Markdown
Member

@Antolius Antolius commented May 13, 2026

Progress notifications spec: https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/progress

Example from mcp-inspector:

Screenshot 2026-05-14 at 11-25-22 MCP Inspector

Antolius and others added 8 commits May 11, 2026 17:17
…l property

Introduces `infobip.openapi.mcp.progress-notifications-enabled` (default true)
to let users opt out of progress notifications without touching the interval.
Renames `progress-notification-interval` to `progress-notifications-interval`
for naming consistency. When disabled, ToolHandler skips spawning the virtual
thread entirely.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The virtual thread for progress notifications is now only spawned when
the MCP client actually provided a progressToken in the request. Previously,
with progress-notifications-enabled=true, a thread was started for every
HTTP call, even when the callback was a no-op.

McpRequestContext.progressNotificationCallback is now nullable — null means
no client requested progress. supportsProgressNotifications() exposes this
as a clean boolean check for callers.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Introduces ProgressUpdateProvider, a replaceable Spring bean that controls
the progress, total, and message fields sent in each notifications/progress
message. The total is resolved once per tool call before the notification
loop starts, preventing it from drifting mid-stream.

Also introduces ProgressNotificationCallback to carry all three fields
through McpRequestContext, replacing the BiConsumer that only carried
(progress, message).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Summarises the [Unreleased] changelog bullet to keep it concise.
Adds a dedicated Progress Notifications section to README covering
restrictions, disable/interval config, and ProgressUpdateProvider
customisation with a code example and a link to the MCP spec.
Also adds ProgressUpdateProvider to the extension-points table and
a markdown-link style rule to CLAUDE.md.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Introduce NotificationTicker SPI to make notification timing deterministic in tests
- Handle total() failures gracefully: skip progress notifications but still complete the API call, consistent with how next() failures are handled
- Extract resolveProgressTotal and buildNotificationLoop for readability
- Consolidate ToolHandler construction in tests to a single setUp point using a shared Semaphore ticker

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…otifications

A null return from ProgressUpdateProvider.total() signals unknown duration and is
explicitly supported (DefaultProgressUpdateProvider always returns null). The previous
implementation conflated this valid return with an error, causing all notifications to
be silently skipped whenever the provider did not supply a total value.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…oolRequest directly

Replace the ProgressNotificationCallback functional interface and the separate
toolName/progressToken fields with McpSyncServerExchange and McpSchema.CallToolRequest
record components. ToolHandler now calls exchange.progressNotification() directly,
removing all logic from the context DTO.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant