FastMCP

PASS consensus from 3 PASS.

The pages give one complete pip-to-HTTP path, including tool registration, server startup, endpoint, and client call. The quickstart gives one continuous path from uv add fastmcp through @mcp.tool, mcp.run(transport="http", port=8000), and a client at http://localhost:8000/mcp, with the CLI alternative and the __main__ caveat both stated explicitly. Quickstart provides an end-to-end path: install, create server with @mcp.tool, run with HTTP transport, connect via Client, call tool with call_tool(), all in a single page with working code.

PASS consensus from 3 PASS.

The page states the all-items default, positive page size, four covered operations, opaque cursors, and None termination. All four asked-for facts are exact on one page: the default is no pagination, list_page_size must be a positive integer with no documented ceiling, four list operations are named, and termination is next_cursor being None; the server reference page states the same default identically. Default behavior (no pagination), page-size constraint (list_page_size must be positive integer), covered operations (tools/list, resources/list, resources/templates/list, prompts/list), and cursor termination (next_cursor is None at end) are all clearly documented.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The page documents ToolError and is_error handling, but it gives no corrective retry rule or example. Both handling modes are documented side by side with runnable code, but no page shows a corrective retry after a ToolError; the only retry documented is server-side RetryMiddleware, which is scoped to transient exceptions such as ConnectionError and TimeoutError and lives on a different page. Both handling modes are documented with code examples: catch ToolError via try/except from fastmcp.exceptions, or disable automatic raising with raise_on_error=False and check result.is_error. Server-side documentation also covers ToolError and standard Python exception raising.

PASS consensus from 2 PASS, 1 PARTIAL.

The bearer route works, but token discovery is absent and the JWT-only definition contradicts the documented opaque static-token path. Both ends close: the server side gives a concrete verifier per scenario (JWTVerifier, IntrospectionTokenVerifier, StaticTokenVerifier) and the client side documents nine numbered OAuth flow steps plus bearer-string auth, and the token-verification page states plainly where discovery does not apply. Server authentication covers bearer token (JWTVerifier, IntrospectionTokenVerifier) and OAuth (OAuthProxy, RemoteAuthProvider, OAuthProvider). Client authentication covers OAuth with automatic discovery and token lifecycle, bearer token with simple string or BearerAuth helper, and custom headers for non-standard schemes.

PASS consensus from 2 PASS, 1 PARTIAL.

The quickstart gives a working greet call, but the client page calls example_tool without registering it on its in-memory server. One example covers connect, list_tools(), list_resources(), list_prompts(), and call_tool(), and the @mcp.tool server it pairs with matches the decorator form used throughout the server documentation. Quickstart provides a working client example that creates a Client, connects with async with, and calls a tool via call_tool(). Client page documents list_tools, list_resources, list_prompts, and call_tool in detail. The example matches the server created in the same guide.