Repository navigation
Releases: bradburch/mcp-auth-kit
Releases · bradburch/mcp-auth-kit
Release list
v0.3.0
Added
defineTool(...)— FastMCP-style typed tools:inputis inferred frominputSchemaand a
mutating tool'sexecute(data)is typed frompreview'sdata, so handlers need no casts.- Handlers and
executemay return a plain string (→ one text block) or any JSON-serializable
value (→ JSON text block); an MCP{ content: [...] }result still passes through unchanged. ToolError— throw it from a handler,preview, orexecuteto reject with a message the
client sees verbatim (e.g. "09:00 is already booked"). Any other error stays generic.onToolErrorhook, fired when a handler/preview/executethrows or returns an
unserializable value, or a storage call in the mutating flow fails (phase: "storage") —
the real error is no longer invisible to the operator. A storage failure before
executereleases the idempotency claim so a retry can run.onToolCallnow also fires for mutating-tool calls (the preview step).name/versionconfig options for the server identity reported oninitialize.
Changed
- Breaking:
createMcpServernow throws at construction on duplicate tool names, a tool
namedconfirm_request(reserved), a toolscopenot declared inscopes, or an
inputSchemathat isn't az.object. That includes object schemas wrapped in
.transform()/.pipe()/.default()/.readonly(), and — under zod 3 —.refine()/
.superRefine()/.brand(). Such tools previously started but were advertised with an
empty input schema and received unvalidated input; move that logic into the handler. - Behavior: the whole
z.object(not just its.shape) is passed to the SDK, so zod 4
.refine()checks on an input schema now actually run (they were silently skipped).
This also makes.strict()objects reject unknown keys (JSON-RPC-32602; previously
stripped) and.passthrough()objects forward them to the handler (previously stripped),
andtools/listnow reflects both viaadditionalPropertiesplus any object-level
.describe(). Plainz.objectschemas are advertised exactly as before. - Behavior:
onToolCallfires when a tool is invoked, concurrently with the handler
(previously after it returned). - Behavior: an error thrown by a mutating tool's
previeworexecuteno longer reaches
the client verbatim — throwToolErrorfor messages meant for the client. @modelcontextprotocol/sdkpeer range raised from^1to^1.25.0, the first release
shipping the web-standard transport this kit imports.- Untyped
ToolDefhandlerinputisunknownunder zod 3 too (wasany). - Dependencies updated (vitest 5, hono 4.13, zod 4.6, SDK 1.30.1, eslint 10.11);
npm run typechecknow also coverstest/andexamples/.
Fixed
- Replaying
confirm_requestwith the sameidempotencyKeyreturned the cached result
JSON-stringified inside a text block instead of the original result; a corrupt cached
entry now yields a generic error instead of a parser message. - A mutating tool whose side effect succeeded could be reported as failed — and its
idempotency claim released, so a retry executed it twice — if its result couldn't be
serialized oronMutationthrew. Both now keep the claim and return success. - An error thrown by a handler,
preview, orexecute, or a handler return value that
couldn't be serialized (BigInt, cycles), leaked its raw message to the client. - An object return value that merely has a
contentarray (e.g.{ id, content: [1, 2] })
was passed through as a malformed tool result; it's now JSON-serialized.