Skip to content

feat(core): add parse/safeParse methods to specTypeSchemas entries #2241

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
felixweinberger wants to merge 7 commits into
base: main
Choose a base branch
from
+433 −41
Draft

feat(core): add parse/safeParse methods to specTypeSchemas entries #2241

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
5f4253e
Add parseSpecType and safeParseSpecType validation helpers
felixweinberger Jun 2, 2026
cc29d4b
Add wire-level integration tests for parseSpecType helpers
felixweinberger Jun 2, 2026
c0b5827
Move parse/safeParse onto the specTypeSchemas entries
felixweinberger Jun 2, 2026
b330712
Make SpecTypeValidationError an SdkError subclass; bump published pac…
felixweinberger Jun 2, 2026
5b68b05
Remove accidentally committed authoring artifact
felixweinberger Jun 2, 2026
76561bd
Document SdkErrorCode.InvalidSpecType and the codemod's current schem…
felixweinberger Jun 2, 2026
81335d9
Correct codemod diagnostics that claim parse/safeParse are unavailable
felixweinberger Jun 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions .changeset/spec-type-parse-helpers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
---
'@modelcontextprotocol/client': minor
'@modelcontextprotocol/server': minor
---

Add v1-style `parse`/`safeParse` methods to every `specTypeSchemas` entry, so v1 call sites migrate with a one-line rename: `CallToolResultSchema.parse(value)` becomes `specTypeSchemas.CallToolResult.parse(value)`. `parse` returns the parsed value or throws `SpecTypeValidationError` (an `SdkError` subclass with code `SdkErrorCode.InvalidSpecType`, carrying `.specType` and `.issues`); `safeParse` returns a `{ success, data | issues }` discriminated union so migrated call sites keep their control flow. Both are synchronous, and each entry remains a Standard Schema (`['~standard'].validate`).
20 changes: 12 additions & 8 deletions docs/migration-SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,6 +134,7 @@ New `SdkErrorCode` enum values:
- `SdkErrorCode.ConnectionClosed` = `'CONNECTION_CLOSED'`
- `SdkErrorCode.SendFailed` = `'SEND_FAILED'`
- `SdkErrorCode.InvalidResult` = `'INVALID_RESULT'`
- `SdkErrorCode.InvalidSpecType` = `'INVALID_SPEC_TYPE'`
- `SdkErrorCode.ClientHttpNotImplemented` = `'CLIENT_HTTP_NOT_IMPLEMENTED'`
- `SdkErrorCode.ClientHttpAuthentication` = `'CLIENT_HTTP_AUTHENTICATION'`
- `SdkErrorCode.ClientHttpForbidden` = `'CLIENT_HTTP_FORBIDDEN'`
Expand Down Expand Up @@ -471,16 +472,19 @@ For **custom (non-spec)** methods, keep the result-schema argument — see §9.

Remove unused schema imports: `CallToolResultSchema`, `CompatibilityCallToolResultSchema`, `ElicitResultSchema`, `CreateMessageResultSchema`, etc., when they were only used in `request()`/`send()`/`callTool()` calls.

If a `*Schema` constant was used for **runtime validation** (not just as a `request()` argument), replace with `isSpecType` / `specTypeSchemas`:
If a `*Schema` constant was used for **runtime validation** (not just as a `request()` argument), the `specTypeSchemas.<TypeName>` entries carry `parse`/`safeParse` methods — a mechanical rename:

| v1 pattern | v2 replacement |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| `CallToolResultSchema.safeParse(value).success` | `isSpecType.CallToolResult(value)` |
| `<TypeName>Schema.safeParse(value).success` | `isSpecType.<TypeName>(value)` |
| `<TypeName>Schema.parse(value)` | `specTypeSchemas.<TypeName>['~standard'].validate(value)` (returns a `Result` synchronously, not the value) |
| Passing `<TypeName>Schema` as a validator argument | `specTypeSchemas.<TypeName>` (a `StandardSchemaV1Sync<In, Out>`) |
| v1 pattern | v2 replacement |
| -------------------------------------------------- | -------------------------------------------------------------------------------------- |
| `<TypeName>Schema.parse(value)` | `specTypeSchemas.<TypeName>.parse(value)` (returns the parsed value; throws `SpecTypeValidationError`, an `SdkError` subclass with code `SdkErrorCode.InvalidSpecType`, with `.issues`) |
| `<TypeName>Schema.safeParse(value)` | `specTypeSchemas.<TypeName>.safeParse(value)` (`{ success: true, data }` \| `{ success: false, issues }`) |
| `CallToolResultSchema.safeParse(value).success` | `isSpecType.CallToolResult(value)` |
| `<TypeName>Schema.safeParse(value).success` | `isSpecType.<TypeName>(value)` |
| Passing `<TypeName>Schema` as a validator argument | `specTypeSchemas.<TypeName>` (a `StandardSchemaV1Sync<In, Out>` with `parse`/`safeParse`) |

Comment on lines +475 to 484
Copy link
Copy Markdown

@claude claude Bot Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 The v1→v2 codemod's spec-schema transform (packages/codemod/src/migrations/v1-to-v2/transforms/specSchemaAccess.ts, untouched by this PR) still emits user-facing diagnostics stating that .parse()/.safeParse() are "not available in v2" and that a "Manual rewrite required" — statements that become factually wrong once this PR lands, so the published @modelcontextprotocol/codemod will directly contradict the SDK and this migration table. Even if retargeting the codemod's rewrite output to emit .parse/.safeParse stays a follow-up, the "not available" diagnostic prose should be corrected in the same change so the migration tooling doesn't steer users away from the API this PR adds.

Extended reasoning...

What the bug is. This PR adds .parse()/.safeParse() methods to every specTypeSchemas entry and rewrites both migration guides to present them as the primary replacement for v1's <TypeName>Schema.parse()/.safeParse() call sites. But the v1→v2 codemod's spec-schema transform — packages/codemod/src/migrations/v1-to-v2/transforms/specSchemaAccess.ts, not touched by this PR — still emits user-facing diagnostics that flatly contradict the new API:

  • Lines 107–108: ${localName}.safeParse() not available in v2. Use isSpecType.${typeName}(value) for boolean validation, or specTypeSchemas.${typeName}['~standard'].validate(value) for full result.
  • Lines 120–121: ${localName}.parse() not available in v2. Use isSpecType... or ['~standard'].validate(value) and check for issues.
  • Lines 137, 162, 188: Replaced ${localName} with specTypeSchemas.${typeName}. Note: typed as StandardSchemaV1, not ZodType — Zod methods like .safeParse()/.parse() are not available. (line 137 adds "Manual rewrite required.")

In addition, rewriteCapturedSafeParse (lines ~249–331) still rewrites captured safeParse call sites into the verbose ['~standard'].validate remap (.success → .issues === undefined, .data → .value) — exactly the error-prone pattern this PR's description says it was written to eliminate.

The code path that triggers it. A user runs the published @modelcontextprotocol/codemod (the pkg-pr-new bot shows it is built and published from this same monorepo and this PR) on v1 code containing CallToolResultSchema.parse(value) or OAuthTokensSchema.safeParse(value). The transform replaces the identifier with specTypeSchemas.CallToolResult and then prints a warning telling the user that .parse()/.safeParse() "are not available" and that a manual rewrite to ['~standard'].validate is required.

Step-by-step proof. (1) This PR's register() in packages/core/src/types/specTypeSchema.ts attaches parse/safeParse to every specTypeSchemas entry, so specTypeSchemas.CallToolResult.parse(value) works. (2) The codemod's value-position rewrite already turns CallToolResultSchema into specTypeSchemas.CallToolResult, so the remaining trailing .parse(value) in the user's code now compiles and runs correctly with no further edits. (3) Yet the diagnostic emitted at lines 137/162/188 for that exact rewrite says the Zod-style methods "are not available" and (at 137) that a "Manual rewrite required" — directing the user to undo a working call site and replace it with the ['~standard'].validate remap that docs/migration.md and docs/migration-SKILL.md (updated in this PR) now demote to "the underlying mechanism". (4) The lines 107–108/120–121 diagnostics for the bare-constant case likewise recommend only isSpecType or the ['~standard'].validate remap, never mentioning the one-line rename this PR documents as the primary path.

Why nothing prevents it. Nothing in this PR touches the codemod package, and there is no test or lint coupling the codemod's diagnostic strings to the SDK's actual API surface, so the contradiction ships silently. The PR description's "Follow-up opportunity" only covers the enhancement of emitting .parse/.safeParse rewrites directly; it does not address that the existing diagnostic prose becomes affirmatively false the moment this merges.

Impact. The official migration tool will contradict the official migration docs and the SDK's behavior in the same release: users who trust the codemod output will hand-rewrite working call sites into the verbose, inversion-prone ['~standard'].validate pattern this PR exists to remove, and users who read the docs will see the codemod calling the documented API nonexistent. No runtime breakage, but published, user-facing guidance becomes incorrect.

How to fix. At minimum, in this same change update the diagnostic strings in specSchemaAccess.ts (lines 107–108, 120–121, 137, 162, 188) to say the entries now carry .parse()/.safeParse() (e.g. "the rewritten specTypeSchemas.X entry supports .parse()/.safeParse() directly; .parseAsync() is not needed — validation is synchronous"). The fuller follow-up — having the transform emit .parse/.safeParse rewrites and retiring rewriteCapturedSafeParse's ['~standard'].validate remap — can land separately as planned.

Copy link
Copy Markdown

@claude claude Bot Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the note in docs/migration-SKILL.md (commit b8deb0b) acknowledging that the codemod currently rewrites these call sites to the ['~standard'].validate form — that resolves the docs-side inconsistency for readers of the migration guide.

However, the core issue is still open: the codemod's own diagnostic strings in packages/codemod/src/migrations/v1-to-v2/transforms/specSchemaAccess.ts remain unchanged and become factually wrong once this PR lands:

  • Lines 107–108 and 120–121 still tell users .safeParse() / .parse() are "not available in v2" and point only to isSpecType or the ['~standard'].validate remap.
  • Lines 137, 162, 188 still say "Zod methods like .safeParse()/.parse() are not available" (line 137 adds "Manual rewrite required").

A user running the published @modelcontextprotocol/codemod (built from this same monorepo) sees those messages without ever reading the migration guide, so the official tooling will still steer them away from the API this PR adds — and away from the docs' recommended form. The doc note even calls the validate form merely "the lower-level" equivalent, while the codemod calls the recommended form nonexistent.

The retargeting of the codemod's rewrite output (emitting .parse/.safeParse directly, retiring rewriteCapturedSafeParse's remap) can certainly stay a follow-up as planned — but the diagnostic prose itself is a small string-only change that would keep the published codemod from contradicting the SDK in the same release. E.g. update those messages to say the rewritten specTypeSchemas.X entry now supports .parse()/.safeParse() directly (with .parseAsync() unnecessary since validation is synchronous).

`isCallToolResult(value)` still works, but `isSpecType` covers every spec type by name.
All validation is synchronous (`StandardSchemaV1Sync`) — never add `await`. `isCallToolResult(value)` still works, but `isSpecType` covers every spec type by name.

Note: the v1→v2 codemod currently rewrites these call sites to the lower-level `specTypeSchemas.<TypeName>['~standard'].validate(value)` form. That form is equivalent and stays supported, but `parse`/`safeParse` is the recommended form when writing or revising call sites by hand; a codemod update to emit the methods directly is planned.
Copy link
Copy Markdown

@claude claude Bot Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 The note at the end of section 11 says the v1→v2 codemod "currently rewrites these call sites to the lower-level specTypeSchemas.<TypeName>['~standard'].validate(value) form", but the codemod only rewrites the captured-variable safeParse pattern — bare <TypeName>Schema.parse(value) call sites (the first row of the table directly above) and non-captured safeParse calls only get a diagnostic warning and are left untouched. Consider narrowing the sentence (e.g. "rewrites captured safeParse call sites to … and emits warnings for parse() call sites") or updating the codemod in the same change.

Extended reasoning...

What the prose claims vs. what the codemod does. The new note added at docs/migration-SKILL.md:487 states that "the v1→v2 codemod currently rewrites these call sites to the lower-level specTypeSchemas.<TypeName>['~standard'].validate(value) form." The phrase "these call sites" refers to the table directly above (lines 477–483), whose first two rows are <TypeName>Schema.parse(value) and <TypeName>Schema.safeParse(value). Checking the codemod's actual transform in packages/codemod/src/migrations/v1-to-v2/transforms/specSchemaAccess.ts, that claim only holds for one of the patterns in the table.

What the codemod actually rewrites. The transform handles four shapes: (1) XSchema.safeParse(v).success is rewritten to isSpecType.X(v) (lines 83–92); (2) the captured-variable pattern const x = XSchema.safeParse(v) is rewritten to specTypeSchemas.X['~standard'].validate(v) via rewriteCapturedSafeParse (lines 95–100, ~249); (3) a non-captured XSchema.safeParse(v) gets only a diagnostic warning and return false — no rewrite (lines 103–112); and (4) XSchema.parse(v) is explicitly "diagnostic only" — the comment at line 114 says so — pushing a warning ("parse() not available in v2 …") and returning false, leaving the call site untouched (lines 114–125).

Step-by-step proof. Take v1 code containing const result = CallToolResultSchema.parse(value) — the exact pattern in the first row of the table. (1) The codemod's reference walk reaches isParsePattern(ref) at line 115. (2) It pushes the warning \"CallToolResultSchema.parse() not available in v2. Use isSpecType.CallToolResult(value) … or specTypeSchemas.CallToolResult['~standard'].validate(value) …\" and returns false. (3) The source line is not modified at all — it is neither rewritten to ['~standard'].validate(value) (as the new doc sentence claims) nor to .parse(value). The only pattern that genuinely ends up as ['~standard'].validate is the captured safeParse row, and the .success row becomes isSpecType.X(v), not validate.

Why this matters. The SKILL doc is explicitly written for mechanical application by an LLM or a migrating user. The note exists to set expectations about what codemod output will look like versus what to write by hand; as written it tells readers the codemod has already converted their parse() call sites into a working (if verbose) form, when in reality those call sites are left as broken v1 code accompanied only by a warning. A reader trusting the note may assume no manual follow-up is needed for parse() sites after running the codemod. Nothing in the PR or in CI couples this prose to the codemod's behavior, so the inaccuracy ships silently.

Relationship to the existing review comment. This is distinct from the earlier inline comment on this file about the codemod's own diagnostic strings becoming stale ("parse() not available in v2" wording, fixed in the codemod package). That comment asks for the codemod's diagnostics to be updated; this one is about the accuracy of the sentence this PR newly adds to the migration guide. Fixing one does not fix the other.

How to fix. Narrow the sentence to match reality, e.g.: "Note: the v1→v2 codemod currently rewrites captured safeParse call sites to the lower-level specTypeSchemas.<TypeName>['~standard'].validate(value) form and emits warnings for parse() (and non-captured safeParse) call sites; parse/safeParse is the recommended form when writing or revising call sites by hand, and a codemod update to emit the methods directly is planned." Alternatively, update the codemod in the same change so the original sentence becomes true.


## 12. Experimental tasks interception removed

Expand Down
23 changes: 13 additions & 10 deletions docs/migration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -506,29 +506,31 @@ The return type is now inferred from the method name via `ResultTypeMap`. For ex

For **custom (non-spec)** methods, keep the result-schema argument — see [Sending custom-method requests](#sending-custom-method-requests). Only drop the schema when calling a spec method.

If you were using `CallToolResultSchema` (or any `*Schema` constant) for **runtime validation** (not just in `request()`/`callTool()` calls), use `isSpecType` or `specTypeSchemas`:
If you were using `CallToolResultSchema` (or any `*Schema` constant) for **runtime validation** (not just in `request()`/`callTool()` calls), the `specTypeSchemas` entries carry `parse`/`safeParse` methods shaped like the v1 schemas, so the migration is a one-line rename — or use `isSpecType` for a boolean guard:

```typescript
// v1: runtime validation with Zod schema
import { CallToolResultSchema } from '@modelcontextprotocol/sdk/types.js';
if (CallToolResultSchema.safeParse(value).success) {
/* ... */
}
const result = CallToolResultSchema.parse(value); // throws ZodError on failure
const parsed = CallToolResultSchema.safeParse(value); // { success, data | error }

// v2: keyed type predicate
// v2: same call shapes on the spec type registry
import { specTypeSchemas } from '@modelcontextprotocol/client';
const result = specTypeSchemas.CallToolResult.parse(value); // throws SpecTypeValidationError (with .issues) on failure
const parsed = specTypeSchemas.CallToolResult.safeParse(value); // { success: true, data } | { success: false, issues }

// v2: boolean type predicate
import { isSpecType } from '@modelcontextprotocol/client';
if (isSpecType.CallToolResult(value)) {
/* ... */
}
const blocks = mixed.filter(isSpecType.ContentBlock);

// v2: or get the StandardSchemaV1Sync validator object directly
import { specTypeSchemas } from '@modelcontextprotocol/client';
const result = specTypeSchemas.CallToolResult['~standard'].validate(value);
// v2: each entry is also a Standard Schema, for Standard-Schema-aware libraries
const r = specTypeSchemas.CallToolResult['~standard'].validate(value);
```

`isSpecType` and `specTypeSchemas` are keyed by `SpecTypeName` — a literal union of every named type in the MCP spec — so you get autocomplete and a compile error on typos. `specTypeSchemas.X` is a `StandardSchemaV1Sync<In, Out>` — `validate()` returns the result synchronously,
so you can access `.issues` / `.value` without `await`. It composes with any Standard-Schema-aware library. The pre-existing `isCallToolResult(value)` guard still works.
All of these are keyed by `SpecTypeName` — a literal union of every named type in the MCP spec — so you get autocomplete and a compile error on typos. Validation is **synchronous** throughout: the backing schemas are `StandardSchemaV1Sync`, so `parse`/`safeParse`/`validate()` return results directly and no `await` is needed. On failure, `parse` throws `SpecTypeValidationError` — an `SdkError` subclass with code `SdkErrorCode.InvalidSpecType`, so generic `instanceof SdkError` handlers catch it — whose `.issues` plays the role v1's `ZodError.issues` did in catch blocks. The pre-existing `isCallToolResult(value)` guard still works.
Comment thread
claude[bot] marked this conversation as resolved.

### Client list methods return empty results for missing capabilities

Expand Down Expand Up @@ -732,6 +734,7 @@ The new `SdkErrorCode` enum contains string-valued codes for local SDK errors:
| `SdkErrorCode.ConnectionClosed` | Connection was closed |
| `SdkErrorCode.SendFailed` | Failed to send message |
| `SdkErrorCode.InvalidResult` | Response result failed local schema validation |
| `SdkErrorCode.InvalidSpecType` | Value failed spec type schema validation via `parse`/`safeParse` |
| `SdkErrorCode.ClientHttpNotImplemented` | HTTP POST request failed |
| `SdkErrorCode.ClientHttpAuthentication` | Server returned 401 after re-authentication |
| `SdkErrorCode.ClientHttpForbidden` | Server returned 403 after trying upscoping |
Expand Down
14 changes: 7 additions & 7 deletions packages/codemod/src/migrations/v1-to-v2/transforms/specSchemaAccess.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,8 +105,8 @@ function handleReference(
actionRequired(
sourceFile.getFilePath(),
ref,
`${localName}.safeParse() not available in v2. Use \`isSpecType.${typeName}(value)\` for boolean validation, ` +
`or \`specTypeSchemas.${typeName}['~standard'].validate(value)\` for full result.`
`${localName}.safeParse() was removed with the v1 schema exports. Rewrite as \`specTypeSchemas.${typeName}.safeParse(value)\` ` +
`(returns { success, data | issues }), or use \`isSpecType.${typeName}(value)\` for a boolean check.`
)
);
return false;
Expand All @@ -118,8 +118,8 @@ function handleReference(
actionRequired(
sourceFile.getFilePath(),
ref,
`${localName}.parse() not available in v2. Use \`isSpecType.${typeName}(value)\` for validation, ` +
`or \`specTypeSchemas.${typeName}['~standard'].validate(value)\` and check for issues.`
`${localName}.parse() was removed with the v1 schema exports. Rewrite as \`specTypeSchemas.${typeName}.parse(value)\` ` +
`(throws SpecTypeValidationError on failure), or use \`isSpecType.${typeName}(value)\` for a boolean check.`
)
);
return false;
Expand All @@ -135,7 +135,7 @@ function handleReference(
warning(
sourceFile.getFilePath(),
line,
`Replaced ${localName} with specTypeSchemas.${typeName}. Note: typed as StandardSchemaV1, not ZodType — Zod methods like .safeParse()/.parse()/.parseAsync() are not available. Manual rewrite required.`
`Replaced ${localName} with specTypeSchemas.${typeName}. Note: typed as StandardSchemaV1, not ZodType — .parse()/.safeParse() are provided, but Zod-specific APIs like .parseAsync() are not. Verify the accessed member.`
)
);
return true;
Expand All @@ -160,7 +160,7 @@ function handleReference(
warning(
sourceFile.getFilePath(),
line,
`Replaced ${localName} with specTypeSchemas.${typeName}. Note: typed as StandardSchemaV1, not ZodType — Zod methods like .safeParse()/.parse() are not available.`
`Replaced ${localName} with specTypeSchemas.${typeName}. Note: typed as StandardSchemaV1, not ZodType — .parse()/.safeParse() are provided, but Zod-specific APIs (e.g. .parseAsync(), .extend()) are not.`
)
);
return true;
Expand All @@ -178,7 +178,7 @@ function handleReference(
warning(
sourceFile.getFilePath(),
line,
`Replaced ${localName} with specTypeSchemas.${typeName}. Note: typed as StandardSchemaV1, not ZodType — Zod methods like .safeParse()/.parse() are not available.`
`Replaced ${localName} with specTypeSchemas.${typeName}. Note: typed as StandardSchemaV1, not ZodType — .parse()/.safeParse() are provided, but Zod-specific APIs (e.g. .parseAsync(), .extend()) are not.`
)
);
return true;
Expand Down
4 changes: 4 additions & 0 deletions packages/core/src/errors/sdkErrors.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,10 @@ export enum SdkErrorCode {
/** Response result failed local schema validation */
InvalidResult = 'INVALID_RESULT',

// Validation errors
/** Value failed spec type schema validation via `parse`/`safeParse` */
InvalidSpecType = 'INVALID_SPEC_TYPE',

// Transport errors
ClientHttpNotImplemented = 'CLIENT_HTTP_NOT_IMPLEMENTED',
ClientHttpAuthentication = 'CLIENT_HTTP_AUTHENTICATION',
Expand Down
5 changes: 3 additions & 2 deletions packages/core/src/exports/public/index.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,8 +106,9 @@ export {
} from '../../types/guards.js';

// Validator types and classes
export type { SpecTypeName, SpecTypes } from '../../types/specTypeSchema.js';
export { isSpecType, specTypeSchemas } from '../../types/specTypeSchema.js';
export type { SafeParseSpecTypeResult, SpecTypeName, SpecTypes, SpecTypeSchema } from '../../types/specTypeSchema.js';
export type { SpecTypeValidationErrorData } from '../../types/specTypeSchema.js';
export { isSpecType, specTypeSchemas, SpecTypeValidationError } from '../../types/specTypeSchema.js';
export type { StandardSchemaV1, StandardSchemaV1Sync, StandardSchemaWithJSON } from '../../util/standardSchema.js';
// Validator providers are type-only here — import the runtime classes from the explicit
// `@modelcontextprotocol/{client,server}/validators/{ajv,cf-worker}` subpaths to customise.
Expand Down
32 changes: 29 additions & 3 deletions packages/core/src/types/specTypeSchema.examples.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,14 +15,38 @@ declare const mixed: unknown[];

function specTypeSchemas_basicUsage() {
//#region specTypeSchemas_basicUsage
const result = specTypeSchemas.CallToolResult['~standard'].validate(untrusted);
if (result.issues === undefined) {
// result.value is CallToolResult
const result = specTypeSchemas.CallToolResult.parse(untrusted);
// result is CallToolResult; throws SpecTypeValidationError on invalid input

// Entries are Standard Schemas, so the underlying validator is also available:
const validated = specTypeSchemas.CallToolResult['~standard'].validate(untrusted);
if (validated.issues === undefined) {
// validated.value is CallToolResult
}
//#endregion specTypeSchemas_basicUsage
void result;
}

function specTypeSchemas_parse() {
//#region specTypeSchemas_parse
const result = specTypeSchemas.CallToolResult.parse(untrusted);
// result is CallToolResult; throws SpecTypeValidationError on invalid input
//#endregion specTypeSchemas_parse
void result;
}

function specTypeSchemas_safeParse() {
//#region specTypeSchemas_safeParse
const parsed = specTypeSchemas.Tool.safeParse(untrusted);
if (parsed.success) {
// parsed.data is Tool
} else {
// parsed.issues describes the failures
}
//#endregion specTypeSchemas_safeParse
void parsed;
}

function isSpecType_basicUsage() {
/* eslint-disable unicorn/no-array-callback-reference -- showcasing the guard-as-callback pattern */
//#region isSpecType_basicUsage
Expand All @@ -37,4 +61,6 @@ function isSpecType_basicUsage() {
}

void specTypeSchemas_basicUsage;
void specTypeSchemas_parse;
void specTypeSchemas_safeParse;
void isSpecType_basicUsage;
Loading
Loading