PrefectHQ/fastmcp · error · ValueError

The 'verify' parameter is only supported for HTTP transports

Error message

The 'verify' parameter is only supported for HTTP transports.

What it means

The verify parameter (TLS verification: bool, ssl.SSLContext, or CA bundle path) is applied by mutating the transport's TLS settings, which only StreamableHttpTransport and SSETransport support. Passing verify with any other transport (STDIO, in-memory, etc.) raises this ValueError in Client.__init__.

Source

Thrown at fastmcp_slim/fastmcp/client/client.py:483

        if verify is not None:
            from fastmcp.client.transports.http import StreamableHttpTransport
            from fastmcp.client.transports.sse import SSETransport

            if isinstance(self.transport, StreamableHttpTransport | SSETransport):
                self.transport.verify = verify
                # Re-sync existing OAuth auth with the new verify setting,
                # but only if the transport doesn't have a custom factory
                # (which takes precedence and was already applied to OAuth).
                if (
                    isinstance(self.transport.auth, OAuth)
                    and auth is None
                    and self.transport.httpx_client_factory is None
                ):
                    verify_factory = self.transport._make_verify_factory()
                    if verify_factory is not None:
                        self.transport.auth.httpx_client_factory = verify_factory
            else:
                raise ValueError(
                    "The 'verify' parameter is only supported for HTTP transports."
                )

        if auth is not None:
            self.transport._set_auth(auth)

        if log_handler is None:
            log_handler = default_log_handler

        if progress_handler is None:
            progress_handler = default_progress_handler

        self._progress_handler = progress_handler

        # Convert request timeout to float seconds (0 means disabled -> None)
        read_timeout_seconds = normalize_timeout_to_seconds(timeout)

        # handle init handshake timeout (0 means disabled)

View on GitHub (pinned to 1f02114297)

Solutions

Only pass verify when the transport is HTTP-based (streamable HTTP or SSE).
Make verify conditional: pass verify=None (omit it) for stdio/in-memory transports.
If TLS customization is needed for a non-HTTP transport, it does not apply — remove the parameter.
For config files, gate the verify key on the transport type.

Example fix

// before: verify passed for a stdio server
client = Client('python', args=['server.py'], verify='/etc/ssl/ca.pem')
// after: verify only for HTTP transports
kwargs = {'verify': '/etc/ssl/ca.pem'} if url.startswith('http') else {}
client = Client(url, **kwargs)

Defensive patterns

Strategy: validation

Validate before calling

def uses_http_transport(transport_or_url) -> bool:
    s = str(transport_or_url)
    return s.startswith(('http://', 'https://'))
verify_arg = ca_bundle if uses_http_transport(target) else None
client = Client(target, verify=verify_arg)

Type guard

from fastmcp.client.transports.http import StreamableHttpTransport
from fastmcp.client.transports.sse import SSETransport

def supports_verify(transport) -> bool:
    return isinstance(transport, StreamableHttpTransport | SSETransport)

Try / catch

try:
    client = Client(transport, verify=ca_bundle)
except ValueError as e:
    if 'only supported for HTTP transports' in str(e):
        client = Client(transport)  # drop verify for non-HTTP transports
    else:
        raise

Prevention

Only pass verify for http(s) URLs or explicit HTTP/SSE transports.
Conditionally build Client kwargs based on transport type in shared helpers.
Remember stdio and in-memory transports have no TLS surface.
Add a unit test asserting Client construction per transport type in your config loader.

When it happens

Trigger: Client(StdioTransport(...), verify='/path/to/ca.pem') or any Client construction where the inferred transport is not an HTTP/SSE transport and verify is not None.

Common situations: Reusing a shared Client-construction helper across local (stdio) and remote (HTTP) servers; forgetting that verify only makes sense for network transports; config-driven clients that always pass verify.

Related errors

AI-assisted analysis of PrefectHQ/fastmcp@1f02114297 (2026-08-29). Data as JSON: /api/errors/8b2ed37ed07b7d99. Report an issue: GitHub.