Dissolve capabilities.md into server.md and client.md#1532
Open
jonathanhefner wants to merge 2 commits intomodelcontextprotocol:mainfrom
Open
Dissolve capabilities.md into server.md and client.md#1532jonathanhefner wants to merge 2 commits intomodelcontextprotocol:mainfrom
capabilities.md into server.md and client.md#1532jonathanhefner wants to merge 2 commits intomodelcontextprotocol:mainfrom
Conversation
Sampling and elicitation are now inline sections in `docs/server.md`
under a new "Server-initiated requests" heading, with type-checked code
snippets (`registerTool_sampling`, `registerTool_elicitation` regions in
`serverGuide.examples.ts`). This fixes the asymmetry where logging got
full inline treatment but structurally identical features (sampling,
elicitation) were exiled to table rows pointing at a separate file.
Tasks get subsections in both guides that name the entry-point APIs
(`registerToolTask`, `callToolStream`, `getTask`, `getTaskResult`) and
link to runnable examples, with progressive disclosure through JSDoc.
JSDoc enhancements for task APIs:
- `ToolTaskHandler`: three-phase description moved to field-level docs,
`@see` linking to `registerToolTask`
- `ResponseMessage`, `TaskStatusMessage`, `TaskCreatedMessage`,
`ResultMessage`, `ErrorMessage`: lifecycle semantics and terminal
behaviour documented; `{@linkcode}` cross-references to streaming APIs
- `takeResult`, `toArrayAsync`: added JSDoc
- `InMemoryTaskStore`: `{@inheritdoc TaskStore.*}` on all public methods
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Move DNS rebinding protection and multi-node deployment patterns into a new `## Deployment` umbrella near the end — they were splitting the flow between Transports and core primitives. Promote Logging from a `####` under Tools to a `###` peer of Tools/Resources/Prompts, since `ctx.mcpReq.log()` is available in any handler, not just tools. Add a brief `#### Tool annotations` subsection under Tools (previously only in the catch-all table). Remove the Tool annotations row from the `More server features` table and drop the cross-link to client.md from the Completions section. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sampling and elicitation are now inline sections in
docs/server.mdunder a new "Server-initiated requests" heading, with type-checked code snippets (registerTool_sampling,registerTool_elicitationregions inserverGuide.examples.ts). This fixes the asymmetry where logging got full inline treatment but structurally identical features (sampling, elicitation) were exiled to table rows pointing at a separate file.Tasks get subsections in both guides that name the entry-point APIs (
registerToolTask,callToolStream,getTask,getTaskResult) and link to runnable examples, with progressive disclosure through JSDoc.JSDoc enhancements for task APIs:
ToolTaskHandler: three-phase description moved to field-level docs,@seelinking toregisterToolTaskResponseMessage,TaskStatusMessage,TaskCreatedMessage,ResultMessage,ErrorMessage: lifecycle semantics and terminal behaviour documented;{@linkcode}cross-references to streaming APIstakeResult,toArrayAsync: added JSDocInMemoryTaskStore:{@inheritdoc TaskStore.*}on all public methods