Moves relay_elicitation() into elicitation.py so it can reuse
handle_task_input() for the Redis push instead of duplicating that logic.
notifications.py just detects the trigger and calls it.
Also fixes the related-task metadata key from modelcontextprotocol.io/ to
io.modelcontextprotocol/ to match the current spec:
https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
When a background task calls ctx.elicit(), the notification subscriber now
detects the input_required notification and sends a standard elicitation/create
request to the client via session.elicit(). The client's elicitation_handler
fires, and the relay pushes the response to Redis for the blocked worker.
This means clients can respond to background task elicitation using the same
elicitation_handler they'd use for any other elicitation — no need to interact
with Redis or call handle_task_input() directly.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace 1300+ lines of mock-heavy unit tests with 391 lines of integration
tests using real Client(mcp) connections and memory:// Docket backend.
- test_context_background_task.py: 17 tests covering report_progress delta
tracking, elicitation flow, edge cases, and fail-fast on push failure
- test_notifications.py: 2 E2E tests for notification queue lifecycle
Fixes#3097
When using FastMCP.from_openapi() with APIs that require specific
Content-Type headers (e.g., application/vnd.api+json), the transport
connection's content-type: application/json was being injected into
downstream API requests, causing HTTP 415 (Unsupported Media Type) errors.
This change adds content-type to the exclude_headers set in get_http_headers(),
similar to how accept is already excluded. The MCP transport's content type
has no relevance to downstream API calls and should not be forwarded.
Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: Jeremiah Lowin <jlowin@users.noreply.github.com>
* fix: enforce redirect URI validation when patterns are explicitly configured
Security fix: When allowed_redirect_uri_patterns is explicitly set, reject redirect URIs that don't match the patterns instead of falling back to parent validation. This prevents unauthorized OAuth clients from bypassing the allowlist and accessing protected resources.
* Update models.py
no need to return twice
* fix redirect uri access issue
* update style
* feat: add unit test to enforce fallback not applied when redirect uri's supplied
* fix: improve test case
* apply linter
* refactor: simplify logic and do not exposed allowed redirect patterns
---------
Co-authored-by: Nathan <2381793w@student.gla.ac.uk>
Updated all OAuthProxy test instantiations to use MemoryStore instead of defaulting to DiskStore, avoiding SQLite timeout issues on Windows and improving test performance.
Co-authored-by: Bill Easton <strawgate@users.noreply.github.com>
Change version parameter from str to VersionSpec in enable()/disable()
to support range-based version filtering.
- Add match_none parameter to VersionSpec.matches() for controlling
whether unversioned components match (defaults to True for backward
compatibility, False for enable/disable filtering)
- Update Enabled transform to use VersionSpec and call matches() with
match_none=False so unversioned components don't match version specs
- Update enable()/disable() signatures to accept VersionSpec
- Add comprehensive tests for version range matching
Examples:
- disable(version=VersionSpec(eq="v2")) - disable only v2
- disable(version=VersionSpec(gte="v2")) - disable v2 and later
- disable(version=VersionSpec(gte="v1", lt="v3")) - disable v1, v2