Skip to content

ElicitationCompleteNotification: intentional omission of NotificationParams? #2651

Description

@paulbalandan

In schema/draft/schema.ts, every notification except ElicitationCompleteNotification incorporates NotificationParams in its params type, in one of three forms:

Form Examples
*Params extends NotificationParams (named subtype) CancelledNotificationParams, ProgressNotificationParams, ResourceUpdatedNotificationParams, LoggingMessageNotificationParams
Type intersection TaskStatusNotificationParams = NotificationParams & Task
Direct use params?: NotificationParams on InitializedNotification, PromptListChangedNotification, ResourceListChangedNotification, ToolListChangedNotification, RootsListChangedNotification

ElicitationCompleteNotification is the only outlier:

export interface ElicitationCompleteNotification extends JSONRPCNotification {
  method: "notifications/elicitation/complete";
  params: {
    elicitationId: string;
  };
}

This shape:

  • Drops _meta support, which NotificationParams makes universally available (per General fields: _meta).
  • Has no named ElicitationCompleteNotificationParams def in schema.json, so SDKs that map spec defs 1:1 to types need a special case for this one notification. No other notification with params lacks a named params type.

Question: is the inline shape intentional (e.g., the SEP-1036 author wanted to forbid _meta here), or an oversight? If unintentional, the fix would be to extract a named ElicitationCompleteNotificationParams extends NotificationParams interface carrying the elicitationId field, matching the pattern used everywhere else.

Origin: PR #887 (SEP-1036).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions