Skip to content

Conversation

@ccreighton-apptio
Copy link

@ccreighton-apptio ccreighton-apptio commented Nov 5, 2025

SEP-1319 breaks out params into individual types. Arbitrary parameters were fixed for several types in the process.

Motivation and Context

Tests are failing

How Has This Been Tested?

Tests are passing

Breaking Changes

From draft schema changes, yes

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

This is incomplete - modelcontextprotocol/modelcontextprotocol#1770 must be merged first and then the fetch:spec-types change must be reverted.

This does not implement SEP-1319 here, only:

  • Adjusts types for the breaking changes (removal of arbitrary params)
  • Ignores the new types

If there is a desire to implement SEP-1319 here, the params types would need separate definitions and test coverage. I do not intend to complete that refactor. These changes will unblock the current build failures pending a complete implementation.

@ccreighton-apptio ccreighton-apptio requested a review from a team as a code owner November 5, 2025 22:09
Copy link
Author

@ccreighton-apptio ccreighton-apptio left a comment

Choose a reason for hiding this comment

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

The 18 new types have been ignored in tests, rather than implementing SEP-1319 in this PR.

package.json Outdated
],
"scripts": {
"fetch:spec-types": "curl -o spec.types.ts https://raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/refs/heads/main/schema/draft/schema.ts",
"fetch:spec-types": "curl -o spec.types.ts https://raw.githubusercontent.com/ccreighton-apptio/modelcontextprotocol/refs/heads/fix/tool-call-arguments-regression/schema/draft/schema.ts",
Copy link
Author

Choose a reason for hiding this comment

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

This is a temporary change until modelcontextprotocol/modelcontextprotocol#1770 is merged to fix a regression.

expect(specTypes).toContain('JSONRPCNotification');
expect(specTypes).toContain('ElicitResult');
expect(specTypes).toHaveLength(94);
expect(specTypes).toHaveLength(112);
Copy link
Author

Choose a reason for hiding this comment

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

New tests and types are still needed... tests currently fail without them.

Comment on lines -30 to +32
const BaseRequestParamsSchema = z
.object({
_meta: z.optional(RequestMetaSchema)
})
.passthrough();
const BaseRequestParamsSchema = z.object({
_meta: z.optional(RequestMetaSchema)
});
Copy link
Author

Choose a reason for hiding this comment

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

passthrough() behavior on base params has been removed from the spec.

Comment on lines 34 to 37
export const RequestSchema = z.object({
method: z.string(),
params: z.optional(BaseRequestParamsSchema)
params: z.optional(z.record(z.any()))
});
Copy link
Author

Choose a reason for hiding this comment

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

base classes in the spec enable new extensions of RequestSchema by NOT using the broken-out types in their param definitions

_meta: z.optional(z.object({}).passthrough())
})
.passthrough();
const NotificationsMetaSchema = z.object({}).passthrough();
Copy link
Author

Choose a reason for hiding this comment

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

Not sure if splitting this out will be necessary in the end, but was following the style set by having RequestMetaSchema defined separately from BaseRequestParamsSchema

Comment on lines 49 to 52
export const NotificationSchema = z.object({
method: z.string(),
params: z.optional(BaseNotificationParamsSchema)
params: z.optional(z.record(z.any()))
});
Copy link
Author

Choose a reason for hiding this comment

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

base classes in the spec enable new extensions of NotificationSchema by NOT using the broken-out types in their param definitions

Comment on lines 395 to 398
export const InitializedNotificationSchema = NotificationSchema.extend({
method: z.literal('notifications/initialized')
method: z.literal('notifications/initialized'),
params: z.optional(BaseNotificationParamsSchema)
});
Copy link
Author

Choose a reason for hiding this comment

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

Individual types are now where Base params are applied, where previously they were included from extending

Comment on lines -413 to +426
export const ProgressSchema = z
.object({
/**
* The progress thus far. This should increase every time progress is made, even if the total is unknown.
*/
progress: z.number(),
/**
* Total number of items to process (or total progress required), if known.
*/
total: z.optional(z.number()),
/**
* An optional message describing the current progress.
*/
message: z.optional(z.string())
})
.passthrough();
export const ProgressSchema = z.object({
/**
* The progress thus far. This should increase every time progress is made, even if the total is unknown.
*/
progress: z.number(),
/**
* Total number of items to process (or total progress required), if known.
*/
total: z.optional(z.number()),
/**
* An optional message describing the current progress.
*/
message: z.optional(z.string())
});
Copy link
Author

@ccreighton-apptio ccreighton-apptio Nov 5, 2025

Choose a reason for hiding this comment

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

this is from lint:fix

E: Actually, looks like I removed a passthrough() here (resulting in the lint change) because it causes ServerNotification not to be spec-compliant.

Comment on lines +454 to +473
// Params types are not exported as standalone types in the SDK (they're inferred from Zod schemas):
'RequestParams',
'NotificationParams',
'CancelledNotificationParams',
'InitializeRequestParams',
'ProgressNotificationParams',
'PaginatedRequestParams',
'ResourceRequestParams',
'ReadResourceRequestParams',
'SubscribeRequestParams',
'UnsubscribeRequestParams',
'SetLevelRequestParams',
'GetPromptRequestParams',
'CompleteRequestParams',
'CallToolRequestParams',
'CreateMessageRequestParams',
'LoggingMessageNotificationParams',
'ResourceUpdatedNotificationParams',
'ElicitRequestParams',

Copy link
Author

Choose a reason for hiding this comment

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

Alternatively, if the path @ksinder was taking is acceptable, then the only pending change here is getting modelcontextprotocol/modelcontextprotocol#1770 merged so that the fetch:spec-types change can be reverted.

@ccreighton-apptio ccreighton-apptio changed the title Partial fixes for SEP-1319 changes Test Fixes for draft SEP-1319 changes - modelcontextprotocol/modelcontextprotocol#1770 needed first Nov 6, 2025
@KKonstantinov
Copy link
Contributor

Hi, FYI have opened #1086, which resolves the spec issues (apart from modelcontextprotocol/modelcontextprotocol#1770). However, it contains removal of .passthrough() as well and needs review/acceptance. Depending on decisions, could open it without the passthrough removals.

@ccreighton-apptio
Copy link
Author

Cool! At a glance, that looks like a much more complete implementation of the SEP. I can't speak to the desires of the typescript-sdk maintainers, but note that in this PR I've only removed passthrough behavior from the specific places it needed to be to comply with the removal of passthrough behavior in the draft spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants